中身を書く

前回、GraphQLのスキーマ設計を行って、それに伴うGo言語のコード生成まで行った。

その後引っ越しやらなんやらで、時間が空いたけど今日から改めて続きを作る。

新居きた pic.twitter.com/ouEQQew5jF
— よこやま (@hiroyky) 2020年6月2日

今回はやったことは以下の通り。

複数取得できる項目を定義

実装の前に、もう一度GraphQLのスキーマ定義を改修。前回はプライマリキーで1件取得するだけの定義だったけど、せっかくなので複数取得できる項目も設ける。ページネーションや絞り込みをつけるべきなんだけど今回はいったん無し。まずは実装するというところまで持って行きたいから。

あと、一般の読者がリクエストするためのエンドポイントと管理人(筆者)がリクエストためのエンドポイントが別々で必要になりそう。そのため2つスキーマ定義が必要になるような。。（絶対なる）だから今回はホントに仮。（←やる意味あるか？）

ちなみに、ページネーションはGraphQLでよく使われるカーソル式の方法ではなく一般的なlimit, offsetで指定する形式にする。バックエンドのデータベースがMySQLということもありlimit, offsetの方が相性が良いとも思うんだよね。カーソル式はツイッターやfacebookのタイムラインのように常にデータが挿入され流れ続けているような案件には相性良さそうだけど、MySQLのように整形されたデータで全件数も簡単に取得できたり、ソートもできたりするデータベースではせっかくのデータベースのメリットを殺しちゃう気がするんだよね。

あくまでも僕の持論だし、将来的に変わるかもしれないし、意見あったら教えてほしけど。

いわゆるNoSQL: カーソル式なスキーマ設計
リレーショナルデータベース: limit, offsetなスキーマ設計

ってかんじかな。

MySQLへの接続口

Go言語のアプリケーションからMySQLへ接続する部分とかを作る。以前導入したMySQLのORマッパーはMySQLの接続機能を持っているのでそれを利用する。

SQLBoilってやつなんだけどね。設定でadd-global-variants=trueとしたから最後に”G”がつく関数も生成されてる。コレを使うとどこからでもMySQLにアクセスできるようになる。シングルトン的な実装になるのかな。賛否はあるだろうけど毎回データベースのインスタンス変数を持ち歩くのは面倒なのでコレを使う。

接続上を管理するために.envも導入。