技術日記

今週はgraphql APIの設計してた
githubのgraphql APIを大いに参考にさせてもらった
スキーマの定義は主にqueryとmutationがあって
queryはRESTでいうGET系のリクエスト
mutationは登録、更新、削除系のリクエストを扱うスキーマ
mutation内のフィールドは基本動詞で始まる
graphqlの定義ファイルはそれ自体がドキュメントにもなるのでその辺結構嬉しい

現在開発中のシステムでAWS Lambdaを使おうとしているが、Kubernetesベースのサーバーレスが実装できる Knativeというものがあるのを知った
これがうまく使えればアプリケーションはすべてKubernetesで管理できるから嬉しい
ググってるとSQSをトリガにしてKnativeの処理を走らせることもできそうなような出来なさそうなような
もう少し調査が必要そう

kubernetes使用時のローカル開発をskaffoldでやる感じで進めていたが、ローカルPCのリソースが不安だった
しかしローカルPCのskaffoldからEKSのクラスタにデプロイすることが可能なのでそのへんの問題は特になさそう
terepresenceみたいに特定のpodだけローカルで動かすとか出来るのかはまだわからない

リポジトリは結局マルチリポジトリだったものをモノリポジトリに直した
やはりチームの規模もまだ大きくないので、マルチリポジトリにする理由がわからなくなってきた
開発のしやすさもモノリポジトリの方が便利そう（便利らしい）
サービスの切り出す単位も割と機能単位になりそうなので、そうなるとリポジトリが増えすぎて煩雑になりそう
グーグルなどもモノリポジトリでやってるらしい
そのへんの理由でモノリポに直した

jibで静的ファイルにアクセスできない問題が前から発生していたのだが
extraDirectoryを指定すれば解決した
また日本語含むのgraphqlsファイルを読み込むときに MalformedInputException が発生したが、これはjibのjvmFlagsで -Dfile.encoding=UTF-8 を指定すれば解決した

graphiqlでDocsが出てこなかった問題も解決
graphqlが返すレスポンスjsonの形がおかしかった
jsonの第一階層目はdataじゃないとダメだった

デザイナーさんのデザインが徐々に出来始めたから、一回具体的な実装方法のチェックもしておいた
いくつか開発コストが高そうな部分があったからそのへんは共有しておいた
こういうのはなる早で潰していったほうが良い

graphql使用時にN+1 SQL問題というのがよくあるらしい
N+1問題とは
ArticleとUserというオブジェクトがあったとして

Article {
  User
}

という関係性だった場合 graphqlで[Article]を取ってくるときに

articles = getArticles()

articles.forEach {
  getUser(it.userId)
}

といった感じでUserを取得するときに複数のSQLがバラバラに叩かれてしまう問題のこと

graphqlの場合articleとuserを取ってくるdatafetcherが分かれるためコードが分割されてしまい、このN+1 SQL問題が起きやすい
GraphQL と N+1 SQL 問題と dataloader - Qiita
この辺はdataloader使うのを検討してみよう

最近通勤時間をなくして（会社の近くに住んで）その時間を副業とかにあてられないかと思い始めてきた