結婚に伴う引越しや、結婚式の準備などに思っていたより時間が取られ、以前に比べて最近はインプットもアウトプットもかなり減っています。
アウトプットする感覚を少しでも取り戻す為に、Yelp の GraphQL Schema Design を読んだ感想をまとめます。
題の通り、Yelp の GraphQL Schema 設計方針がまとまっている記事です。
Yelp での Schema の在り方が説かれている点、方針の具体例がかなり明確で非常に理解しやすい内容でした。
Shopify のチュートリアルを読んだ時にも感じましたが、ビジネス的な目線でのモデル化に重きを置いている点が印象的でした。
自分は最近までは、UIをベースに設計するべきでフロントエンドエンジニアがUIに合わせてガンガン手を入れていって、データストアとのギャップをバックエンドが吸収するくらいの認識でいました。
ですが、今回題材とした記事や先に紹介した記事を読んだり、業務での体験を通して、スキーマ(GraphQL に限ったものではなく、データにアクセスするインターフェースくらいの意味)がコロコロ変わるのは、サービスとしての安定性を失っており、破壊的変更によるデグレが発生する可能性も高く、変更に強い作りとは程遠いものになってしまう為、頻繁な変更がある前提のものではないよなあと思うようになってきました。
設計方針の具体的なところでも読んでいて、なるほどなと感じる部分が多かったです。
typeをCore typesとDomain specific typesに分けて考えて重要度に差を付けることで、Schema の中でより安定した部分ができれば拡張時の考え方がかなり変わるなあと思いました。
抽象的なtypeを中心に、より具体的なtypeを柔軟に定義できる気がします。
また、命名、フィールド、最上位のクエリに関しては、定義する対象の抽象度を意識することが肝要と感じました。
とにかく安定した(変更に強い、そもそも頻度、内容ともに過度な変更が考えにくい)スキーマにすることを目指すべきですよね。
唯一、首を横に傾げたのはフィールドのグルーピングについてです。
コアなtypeのフィールドをグループ化した新しいtypeを作るまでは賛成なのですが、そのフィールドにグルーピングしたtypeをコアなtypeをextendしたtypeのフィールドに持たせるよりも、グルーピングしたtypeにコアなフィールドを委譲する形の方が扱いやすく感じました。ただ、これは自分がほとんど Go しか書いたことがなくて継承が無く委譲するしかない世界で生きているのもあるかもしれません。
しかし、フィールドをまとめること自体には賛成なので本質からズレた疑問であるとも言えます。(ネストに違和感があると言えば本質に対する思いとも言えますが)
意見を持ちながらこのあたりの設計ガイドを読めるようになったことにかなり成長を感じたアウトプットの機会でした。
