バックエンドなしではモバイルアプリケーションが実行できないことはほとんど知られています。
あなたがモバイル開発者であるなら、あなたはそのようなあごひげを生やしたおじさんに出会ったに違いありません。 または、母乳でphpを吸う、長い髪のかがんだアニメシュニクだったのかもしれません。
いずれにせよ、彼らのほとんどはモバイル開発に遭遇したことがなく、自分自身を第一人者と見なす人もいます。
特にそのような場合のために、アプリケーションのバックエンドを台無しにする方法に関する有害なヒントのリストを用意しました。
良い読書をしてください。
サーバー開発者の場合：
- アプリケーションの構造に注意を払ってはいけません 。製品がユーザーにどのように見えるかは絶対に気にしないでください。 結局のところ、あなたはそのようなことを考えるヒップスターではありません。 10の異なるリクエストを通じて1つの画面のデータを受信する必要がある場合、これらは、APIと調整せずにインターフェイスを描いたデザイナーの問題です。 次回は、ユーザーの利便性について考えないようにしますが、プロジェクトにはもっと重要なことがあります。
- いかなる場合でも、ドキュメントを書かないでください 。 ドロップボックスにある単純なWordboxファイルで十分です。 最終的に、あなたの仕事はエレガントで高性能なデータストリームを流しています。 無力なモバイル開発者に、説明を求める機会をもっと多くさせましょう。 わずかな例と説明のないクエリの単純なリストで十分でしょう。 結局のところ、いつでもコードを調べて、すべてのパラメーターと引数を見ることができます。
- フィールド名を気にしないでください 。 オブジェクトの数を示すフィールドが1つの場所でカウントされ、koli4estvo_kekが別の場所でカウントされる場合でも、異なる場所の同じエンティティが異なる方法で呼び出されるのは正常です。 それで、彼らが本当にそれを盗まないことは明らかですか？
そして、異なるデータ型の意味で？ ええ、はい、ある場合には数字、別の場合には文字列です。 何が悪いの？ - 警告なしでロジックを変更します 。 それはあなたに夜明けした場合、thenしないでください-緊急にそれを紹介します。 互換性について考えないで、急いで議論しないでください。 そして、必ずリリースを公開してください。そうすれば、彼らは自分でそれを理解します。 ドキュメントは更新する必要もありません、それはすべて代理です。
- どのような場合でも、テストを書いたり、独自のAPIをテストしたりすることはありません 。 間違いを犯すことはありません。常に画面に表示されており、アプリケーションが常にクラッシュします。 そして、見つかった問題がまだバックエンドにあることを理解するために、ほんの数分です。
- エラーの説明を送信しないでください 。 まず、彼らは非常にまれです。 すべてが完璧に進むはずです。 第二に、誰もが何かがうまくいかなかった理由をすでに理解しています。 単純なhttp 400または500（ケーキの上のチェリー）で十分です。
- さまざまな形式で回答してください 。 それをどこかjsonにし、どこかxmlにします。 結局のところ、自然は多様性を愛しています。
素晴らしい人々からの引用：「そして、ここでも、jsonで、答えが必要ですか？」 - 承認にはcookieのみを使用します 。 最初のオンラインストアを作ったとき、あなたは研究所でそのように教えられました。 結局のところ、AndroidとiOSは単なる別のブラウザーであり、複雑さを誇張する必要はありません。
- 覚えておいてください：テストデータはありません 。開発者はすべてのコンテンツを自分の手で生成できます。 そして、毎日ベースを掃除することを忘れないでください。これは仕事に興奮を加えるだけです。
- これは同じGETであり、異なるだけであるため、URLを介してPOSTでパラメーターを受け入れます。 あなたの想像力を解き放ちます。 そして、すべてを標準的な形にするための同僚の嘆願を無視してください。彼らは単純に枠を超えて考えることはできません。
- クライアントごとにロジックの最大量を取り出します 。 サーバーは可能な限り軽量でなければなりません。 郵送をスケジュールする必要がありますか？ クライアントに、タイマーをオンにしてもらいます。 3つの異なるソースからのデータの集約？ そこも。 通常、免責でロードできるバックグラウンドスレッドはありません。
この記事を同僚に見せたとき、多くのバックエンド開発者もいくつかの痛い点を共有することにしました。
- ドキュメントを読まないでください、同僚に尋ねるのは常に簡単で速いです。 あなたが15人であっても、彼は再びみんなに説明させていただきます。
（たぶん彼らは孤独で、誰とも話せないでしょうか？）
- APIで何かを作り直すように同僚に依頼しても、その理由を説明しないでください 。 これが彼にとって明らかでない場合、説明する意味がありません、彼はまだ理解しません。
役に立つヒント
身近な状況で一緒に笑うことは素晴らしいことですが、それとは別に、私たちが自宅で使用するより効果的な実践をいくつか共有したいと思います。 外部のモバイル開発者と協力する必要がある場合でも、非常に便利なAPIとプロフェッショナリズムに常に感謝しています。
それ以降のヒントはすべてバックエンドに関連していますが、モバイル開発者であれば、これを読むことも興味深く有用です。 結局のところ、まず第一に、変更に興味を持っているのはあなたです。
ドキュメント
これは、モバイル開発者向けのインターフェースです。 有益であるだけでなく、読みやすく、目を楽しませてください。 奇妙に聞こえますが、ドキュメントが認識されやすくなればなるほど、ドキュメントをすばやく簡単に操作でき、プロセスでの質問が少なくなります。
最も簡単で便利なオプションは、Swaggerを使用することです。 最初の外観には、多くの要望がありますが：
ただし、 フォーマッタを使用すると問題なく改善できます。
それは素敵で快適なことが判明しました。 代替として、 Apiaryを使用できますが、コードとドキュメントを分離する必要がありますが、これは望ましくないか、レンダリングに煩わされます。
均一性
モバイル開発には困難があります-多くのソリューションとフレームワークは非常に遅いです。 特定のリクエストの形式だけを受け取って変更することはできません。または、非常に困難です。 特定の場合にのみ特定のフィールドの名前を変更することは不可能であるため、貧しい開発者は声を叫び、その下に松葉杖を刺そうとします。
すべてが全体的である必要があります。どこでも同じ名前、1つの対話形式（できればJSON）などです。
要求と応答のパラメーター名がモバイルアプリケーションの対応するクラスのフィールドと完全に一致する場合は特に便利です。 奇妙に聞こえますが、デベロッパーの生活が楽になるので、ストアからチョコレートを運ぶことになります。
いくつかの場所では、単純化がばかげたことになります。たとえば、Realm（モバイルデータベース）への保存は、jsonからほとんどすぐに実行できます。 興味深い場合は、モバイルアプリケーションでミドルウェアを削除する方法について個別に説明します。
iOSに着信オブジェクトを保存するサンプルコード：
サーバーからデータベースへの任意のエントリに対する1つの汎用メソッド。 いいですね
画像についても同じことが言えます。 「終了」する必要のない写真にすぐにリンクが来たら最高です。 そして同じルールで-リンクの名前はどこでも同じでなければなりません。
モバイルアプリケーションの特定の情報ブロックについて、Googleで画像を検索する必要がある場合がありました。 その結果、アプリケーションが参照する画像への擬似リンクを作成し、サーバー内でGoogleで適切な画像を探してリダイレクトします。 そして、このアプリケーションの場合、これは最も普通のpicchaのように見えますが、これはもう少し長く考えるだけです。
充足
サーバーで作業している場合、通常はすべてがリクエストの同じスコープ内にあり、データを書き込むためにトランザクションを開いて順番にプッシュするだけで十分です。 すべてが分離され、予測可能で線形です。
モバイルアプリケーションにはそのようなものはありません。 すべてが非同期に回転しているため、異なるリクエストからのデータの整合性を維持したい場合、これはマルチスレッド、強烈なクリティカルセクション、優先度の割り当てを伴う最も複雑な操作に変換されるため、ブレーキのヒントはありません。 モバイル開発者のインタビューでスレッドの同期に関する質問が最初の質問の1つになっているのも不思議ではありません。
これで、モバイル開発者がすべてが単一のリクエストで送信されるようにしようとしている理由を理解できましたか？ 彼らが今日家を出るかどうかによります）
そしてもちろん、一部のデータを非同期にロードする必要がある場合、それらを共通のヒープに押し込む必要はありません。これを理解する必要があります。
結局のところ、アプリケーション設計を開いて、APIを作成している画面が何で構成されているかを確認するのが面倒ではありません。 モバイルの同僚と相談し、データを提供する最善の方法と、その後のリクエストがモバイルに依存するかどうかを判断します。 たぶん、この特定のリクエストでは、十分と思われるよりも少し多くの情報を提供する必要があります。 しかし、それはその後の仕事をクライアントでより便利で楽しいものにします。 そのような些細なことを手伝うと、あなたは長い間思い出されるでしょう。 そして、彼らは温かく彼らの職業生活全体を覚えています。
同じ段落に、デバッグ情報を含めたいと思います。 コメントのリストをリクエストした場合は、これらのコメントがあることを確認してください。 同じ種類のデータを保存するのに1分かかります。モバイル部門のパートナーにとっては、これは安心です。
安定性
私が別に注意を払いたいアーカイブポイントです。 常にAPIを確認するか、さらに良いことに、テストでそれを実行してください。 バックエンドの各バグは、クライアントの10に相当します。 結局のところ、サーバーとユーザーの間には、サーバーを非難する前に除外しなければならない多くのレベルの抽象化があります。
各バグは、ユーザー、テスター、モバイル開発者の時間を費やします。 あなたには最大の責任があり、あなたの間違いは会社に最も大きな損害を与えます。
おまけとして、少なくとも開発の時点で、きれいな活字があれば素晴らしいことです。 ドキュメントを見なくても、サーバーから送られてきたものを把握する必要がある場合があります。
読みやすいのは次のとおりです。
またはこれ：
違いは、私には思えますが、顔にあります。
最も重要なことは、バトルサーバー上でプリティプリントをオフにすることを忘れないでください。
おわりに
ルールは実際には1つであり、非常に単純であると全員に伝えたいだけです。同僚にあなたの仕事から歯を削るように強制しないでください。
次回はGoに移行し、クライアント上のビジネスロジックの巨大な塊を取り除き、アプリケーションバイナリを3分の1以上削減する方法について話します。