# プロジェクト概要
質問に対し、専門家のコメントを見られるようにする機能です。
プロジェクトの立ち上げから関わることができ、技術選定などもできました。
アプリケーションとしてはCRUDの中のRのみをやるものになります。
データの投入はContentfulを使っています。
* フロントエンド: AngularDart
* BFF: Node.js + TypeScript + Apollo GraphQL Server
* API: Kotlin + Spring
* DB: PostgreSQL
フロントエンドとAPIは他のプロジェクトでも使っているため、同じ構成とし、BFFはWillがあった私がセットアップしました。
## BFFの技術選定
テストフレームワークとしてはJestを採用しました。他のメンバーはほぼJS, TSを知らなかったので、全部入りのものを選びました。TDDで開発しているため、テストしにくいものは設計に問題があるという考え方でやっていて、Jestの機能とDIコンテナだけで十分でした。
設計はクリーンアーキテクチャとしています。
DIは[自作のDIコンテナ](https://github.com/naoki-tomita/automated-omusubi)を利用しています。
RESTではなくGraphQLを使いたかったので、ApolloServerを使っています。
## フロントエンドにアトミックデザインを採用した
コンポーネントの設計方針として、アトミックデザインを採用しましたが、自身も初の試みで、フロントエンドの知見が少ないメンバーと一緒に進めていく中で、コンポーネントをAtomと分類するのかMoleculesと分類するのかどう分類すればいいのか試行錯誤が続き、大変でした。
まだ、ここは悩みながら進めています。
# 主にやったこと
* 実装
* BFFのセットアップと実装のサンプル作成
* ビジネスサイドとの連携
# 次に活かせる学び
* GraphQLはバイナリ情報などを取ってくるのには向いてない
* Apollo ServerにはExpressのパスを設定することができるので、画像やファイルダウンロード部分はRESTで作っています。
* Contentfulはデータ構造の設計や、データそのものの特性をよく理解した上で利用するかどうかを検討すべき
* Contentfulは複雑なデータ構造を定義でき、複数のエントリをリンクさせることができますが、課金をしてもエントリ数が50,000件くらいしか保存できない(それ以上はエンタープライズ)ことがあり、小さなエントリを組み合わせて一つの大きな文書を作成するようなアプリケーションには向いていないと感じました。複数のエントリで情報を保存するのではなく、ひとつのエントリのデータ構造をある程度割り切った上で設計することが、コストや入力者への負担の軽減になると思います。