fullStackChatApp
1.0.0
警告：アプリケーションを完了するための残りはほとんどありません。ユーザー登録画面、バックグラウンドでの通知、友人のリクエストのデータ更新、ソケットを介して新しい友人を追加する必要があります。
今のところ、アプリケーションは1か月間開発されており、各基本要件を実装する期間を経て1か月間です。
基本的な要件が完了すると、検出された新しい要件と残りのより複雑な要件が引き続き実装されます。
アプリケーションの作成は、グラフィカルインターフェイスの単純なスケッチから始まりました。これらのスケッチは、私がここに置くことができないために失われました。プロジェクトの写真が表示される最後のセクションをご覧ください。
グラフィカルインターフェイスは、静的テストデータの使用中に実装されました。
これは、私がやった古いプロジェクトとはるかに大きな違いをもたらす最初のプロジェクトです。設計パターンを使用してクリーンなコードを使用し、ビジネスロジックを保護するために、最も論理的で最適な方法で試みました。
時間制限では、デザインが実装され、ハイブの制限のために少し変更する必要がありました（メッセージに関連するクラスのみ）。
高速で最適なアプリケーションを提供するために、デバイスメモリにメッセージを保存することにしました。これを行うには、ローカルNOSQLデータベースとして機能するHiveツールを使用しました。
最適なソリューションとして、新しいメッセージが来るたびに、それらをデバイスとRAMに保存し、チャット画面でユーザーを待つ必要がないようにします。デバイスの既存の変換の最後のメッセージのみがRAMに保存されます。
また、ここでは、ユーザーのプロフィール画像がユーザーのデバイスに保存され、ローカル画像のアドレスがRAMに保存されることに注意する必要があります。
サーバーロジックを示すには、以下の画像を参照してください。
別のユーザーに友達リクエストを送信するユーザーのセッションをシミュレートする画像を見てください。
この例は、WebSocketの使用がいつ必要になるか、いつREST APIを使用するかを確認するために与えられました。
メッセージや友達リクエストの送信などのリアルタイム操作は、セッションを開設したり、ユーザーのデータを更新したりするなどの操作がREST APIを使用しながら、WebSocketsを使用します。
これは、磨かれていないセクションです。主に欠けているのは、REST APIコードを最適化し（より正しい方法で）、チャンネルパーツに新しいメソッドを追加して新しい通知を追加し、REST APIにメソッドを追加し、ユーザーが登録できるチャネルを追加することです。
（速度の意味で）より良いユーザーエクスペリエンスを提供するには、NOSQLデータベースを使用する必要がありました。このようにして、ユーザーのデータにより迅速にアクセスできるからです。
明らかに、この考えは正しいとは言えません。なぜなら、アイデンティティの間に関係があるため、メインユーザーに関連する他のユーザーからのデータを更新する必要があるからです。
すぐにこのセクションを変更して改造できます。今のところ、モデルのロジックは非常に基本的です。各ユーザーには、まだ読み取られていないメッセージ、友人であるユーザー名、友人のリクエスト、ユーザー名、画像（暗号化）などのデータを送信したユーザー名が含まれます。
また、Djangoにはまだ正式にNOSQLデータベース統合がないことに注意する必要があります。このため、 Djongoツールを使用しました。これは非常に好奇心が強く、非常に便利で、SQLモデルをMongoDBに適用してビジネスロジックを保護します。
