Shinonome Tech Blog

株式会社Shinonomeの技術ブログ
3 min read

Dawnを構成する技術

ShinonomeのサービスDawnの開発に際して使用した技術、サービスについての記事になります。

ShinonomeのサービスDawnの開発に際して使用した技術、サービスについての記事になります。

Atomic Design

Atomic Designそのものについてはこの記事を書いている人が詳しくないので詳細については他の記事に任せますが、実装側の視点から良かった点と反省点をまとめます。

良かった点

コンポーネントの責任をできるだけ小さくすることに対して意識的になれる

不完全性定理と同じくらい誤解されがちなSRP(単一責任の原則)についてその重要性を少なくとも垣間見れたのではないかなと思います。Atomsには最小限のプロパティを渡し、余計なことをさせないという点でSRPは守れていたのでしょうか。

反省点

MoleculesとOrganismsの境界が曖昧になりがち

Moleculesにするにはデカい気もするし、Organismsにするほどか?といったことが発生し、それに付随してMoleculesがMoleculesを参照するAtomic Designとは?となるようなコンポーネントが存在しました。

上位コンポーネントで解決できないから下位を書き換えると他の上位コンポーネントに影響が出る

これはAtomicDesign関係なく実装に対して起こった問題ではあるのですが、どう頑張っても上位(Organismsなど)のコンポーネントでは解決できず、仕方なく下位(Molecules,Atomsなど)側を修正したのですが、把握していなかった別のコンポーネントが参照しており、影響が及んでしまうということがありました。

GraphQL

GraphQLは端的に言えば定義されているクエリの範囲で必要なデータだけをやり取りすることができる技術で、ミドルウェアとしてApolloを使用しました。

良かった点

クエリに引数などの定義があるので、エンドポイントでそこまで気にしなくても良い

例えば他のフレームワークだとapi/<userId>/profileといったエンドポイントを作成し、api/<userId>/だと…のようなことを気にする必要があるのですが、GraphQLではエンドポイントが1つなので必然的に引数がクエリ側で定義されます。それによってエンドポイントの構成を気にしなくて良くなったのは個人的には良いポイントでした。

反省点

繋ぎ込みに際してバックエンドの側の実装待ちになってしまった

GraphQLそのものというより開発メンバーが未熟だったゆえに起きてしまった問題ですが、Mock serverを使うなどやりようはあったのにも関わらず、コンポーネントの実装をStoryBookで確認し、実際の画面への実装はデータの繋ぎ込みと共に行うといった非効率な開発になっていました。

ただこの問題は不幸中の幸いと言うべきか、開発のスピードに助けられて深刻化までは行かなかったように思います。

セキュリティに対してやや不安が残った

GraphQLはエンドポイントは同一クエリさえ知っていれば叩き放題のため、誰がそのクエリを叩いたのかとか、余計な情報を渡すような実装をしていないかに対して敏感になる必要がありました。そのせいで本来渡されるべき情報が渡されない不整合が発生したことがありました。

GitHub Discussions

GitHub Discussionsは公式のドキュメント曰く

オープンソースプロジェクトに関するコミュニティ向けの共同コミュニケーションフォーラム

ではあるのですが、
開発時期にちょうど正式導入されたのとなんか面白そうだったので、Issueにするほどでもない(する自信がない)けど、議論したいことを書きつらねる場所として使ってみました。

良かった点

解決したのかしてないのかが明確になる

チームメンバーはSlackを主にコミュニケーションツールとして使っており、この議論前にもしなかったかな?ということがこの開発に関わらずありました。遡るにしてもこれ以外の会話も多くあるので(チャンネルを分けろという話ではあるのですが…)開発についての議論というトピックで切り出せたのは良かったです。この話題はこういう議論を経て解決したとか、こういうツールを将来的に使うことで解決したとか、解決済みといってもより納得しやすい方向に持っていけたのではないかなと思います。チーム内で合意が取れた時にIssueとして扱うことができたのも大きかったです。
ただし、後の反省点につながるのですが運用面において週次に時間を取って全員で確認するという方針が一番大きな影響を与えていたのだと思います。

反省点

使われなくなったらただの負債になる

確認するという行為が断たれてしまうと不思議なことに見なくなってしまいます。
後の開発メンバーにこういう議論があってこういう実装になったとか、こういうツールを使うべきだという物を残せるとはいえ、議論からあまりにも年月が経ってしまうと事情も変わってくるので結局参考程度にしかならなくなってしまいます。総合的にはどっちでもよかったかなと思います。

Dawnについてのお問合せはコチラより。