Diary of a Perpetual Student

2023-01-04

ent + gqlgen で怠惰に GraphQL API を作る

テクノロジー Go GraphQL

この記事ははてなエンジニア Advent Calendar 2022 の 2023年1月4日の記事です。

Go 言語の ORM である ent をご存知でしょうか？ ent はコード生成を用いて型安全に RDB のクエリを記述できる ORM です。エンティティ間の関係を Edge として定義するのが特色となっており、その結果、簡単にグラフ構造データのスキーマモデリングができます。

entgo.io

そんな ent には GraphQL インテグレーションという機能があります。これを使うと、ent のスキーマ定義を用いて簡単に RDB をデータストアとした GraphQL API サーバを作れるのでご紹介します。

ent GraphQL インテグレーションの仕組み

Go 言語で GraphQL API を開発するとき、最初に名前が上がるのが gqlgen というライブラリでしょう。GraphQL のスキーマファイルを食わせてやると、あとは resolver を手で書くだけの状態になった GraphQL API のコードが生成される、というものです。

gqlgen.com

ent によるコード生成時に SchemaGenerator というものを用いると、同時に GraphQL のスキーマファイル（データやクエリの型情報が入っている）を書き出すことができます。このファイルを gqlgen に食わせてやると、 resolver の雛形が生成されます。この未実装部分に ent で生成した CRUD API を利用して実装を埋め込んでいきます。すると、あっという間に GraphQL API の出来上がりです。

// Decks is the resolver for the decks field.
func (r *queryResolver) Decks(ctx context.Context) ([]*ent.Deck, error) {
    panic(fmt.Errorf("not implemented: Decks - decks"))
    // ここの panic を消して、代わりに ent で生成される ORM Client を使った実装を書く
    // return r.Client.Deck.Query().All(ctx)
}

雑多な説明になってしまいましたが、簡単にいうと以下のコーディングだけで GraphQL API が作れます。便利

ent のスキーマ定義ファイル
ent が吐き出した CRUD API を利用した Resolver の実装（関数を呼び出して return するだけ）

以下のように generate.go を用意すると、この一連のコード生成を go generate . 一発で行えます。

//go:generate go run -mod=mod ./ent/entc.go
//go:generate go run -mod=mod github.com/99designs/gqlgen

参考

詳しい説明は今回はしません。気が向いたら手順をエントリにまとめていこうと思います。

自分が参考にしたのは以下のドキュメントです。

entgo.io

感想

id:arthur-1 の個人開発プロジェクトに活用してみたので、使ってみた感想を述べていきます。

よかったこと

レールに従っているだけで、DB のスキーマ、ORM のクライアント、そして GraphQL API が簡単に作れるのはとてもよかったです。

GraphQL API が手軽にできてしまうと、フロントエンドの実装に集中することができます。もともとこのアーキテクチャが「面倒な実装は全部サーバサイドにやらせよう」という雰囲気のものですが、その面倒な部分を ent に丸投げできてしまいます。

さらに、できた GraphQL API がオモチャではないのも良いです。Cursor 形式のページネーションにも対応していたり、dataloader を自前で実装しなくても n+1 問題を自然と回避できたりするので、production として使う上で気になるパフォーマンス上の懸念もあまりなさそうです。

0 からサービスを作り上げたいときに GraphQL を活用したいと考えている場合、手早くスタートする方法としてピッタリではないかと思います。

よくなかったこと

これは ent の GraphQL インテグデーションというより ent 本体の問題なのですが、生成されるデータベースのテーブル定義が「マジかよ」という感じでした。

同じ型のエンティティ間の多対多の関係を定義した時に、その関係を保持する中間テーブルのカラム名が、本来想定されたものと入れ替わってしまうという不具合があります。

ent が生成する CRUD API を通してやりとりする場合には問題ありませんが、データベースに初期データを入れてテストしたいときなどに、カラム名が入れ替わっていることに気をつけなければなりません。

この問題は既知ですが、今だに解決されていません。

migration に atlas を使うと直るかも？

まとめ

GraphQL のエコシステムに乗っかっていくと、リクエストの数やサイズを減らしたり、決まった型がついた状態でデータを fetch できたりと、嬉しいことが多いと思います。一方で、自由に投げられるクエリを処理しなければならないため、サーバの実装はかなり難解なものになっています。

ent の GraphQL インテグレーションを利用すると、すでに定義したエンティティとその間の関係の情報を生かし、自然な形で GraphQL の API サーバを作ることができます。

ささっと GraphQL API を作り、その嬉しさを手早く体感しませんか？というお話でした。

prev: 2023年1月3日分は id:ikesyo さんの『Production Ready GraphQL』の「Anemic GraphQL」 - いけだや技術ノートでした

next: 2023年1月5日分は id:hogashi さんの aタグで#topにリンクするとページ先頭にスクロールするのは仕様 - hogashi.* です

2023-01-01

はてなブログおみくじ2014

日記

はてなブログおみくじ2014

2022-12-29

GitHub Actions の workflow の lint を Github Actions で動かす

テクノロジー GitHub Actions

GitHub Actions で色々なコードの test や lint を動かしていると思います。

その際に workflow を yml で定義するのですが、この workflow ファイルはちゃんとチェックしてますか？

「見よう見まねで yml を書いて push したけど、キー名が間違っていて動かなかった」
「::set-output などの deprecated な機能を今更使ってしまった」

こんな経験はありませんか？

Github Actions に関するその問題、Github Actions を使えば解決できます！

解決策

actionlint という Github Actions の workflow ファイルをチェックしてくれる lint ツールがあります。

こいつを Github Actions 上で動かすだけです。

動作させてみた例を以下に載せておきます。

やり方

以下のように 2 つのファイルを用意して push しましょう。

.github/workflows/ci-actions.yml

on:
  push:
    paths:
      - .github/workflows/*.yml
      - .github/actionlint.yml
      - .github/actionlint-matcher.json

name: actionlint
jobs:
  actionlint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install actionlint
        shell: bash
        run: bash <(curl https://raw.githubusercontent.com/rhysd/actionlint/main/scripts/download-actionlint.bash)
      - name: Add problem matcher
        run: echo "::add-matcher::.github/actionlint-matcher.json"
      - name: run actionlint
        run: ./actionlint
        shell: bash

.github/actionlint-matcher.json

以下からコピーして配置してください。

cf.) actionlint/config.md at main · rhysd/actionlint · GitHub

{
  "problemMatcher": [
    {
      "owner": "actionlint",
      "pattern": [
        {
          "regexp": "^(?:\\x1b\\[\\d+m)?(.+?)(?:\\x1b\\[\\d+m)*:(?:\\x1b\\[\\d+m)*(\\d+)(?:\\x1b\\[\\d+m)*:(?:\\x1b\\[\\d+m)*(\\d+)(?:\\x1b\\[\\d+m)*: (?:\\x1b\\[\\d+m)*(.+?)(?:\\x1b\\[\\d+m)* \\[(.+?)\\]$",
          "file": 1,
          "line": 2,
          "column": 3,
          "message": 4,
          "code": 5
        }
      ]
    }
  ]
}

解説

この workflow は以下のような流れで実行されます。

github から actionlint を install するコマンドを実行
actionlint の出力から annotation （この行がエラーだよという表示）を作るためのテンプレートを設定する
actionlint を実行する

上級 Tips

手元では検出されないエラーが GHA 上で動かすと検出される

actionlint は手元でもインストール実行できるコマンドで、VSCode の拡張として使っている人たちもいるでしょう。このとき、手元環境だとエラーが検出されないのに、Github Actions 上で動かすとエラーが表示されることがあります。

この原因は、shellcheck というコマンドがインストールされているかどうかの差異にあります。

actionlint は、shellcheck がインストールされているなら、run: などで yml 上に書いているシェルスクリプトに対して shellcheck を適用した結果を教えてくれます。

shellcheck は Github Actions の ubuntu-latest runner にデフォルトでインストールされているのに対し、手元環境ではインストールしてない人もいるでしょう。

If you want to enable shellcheck integration, install shellcheck command. Note that shellcheck is pre-installed on Ubuntu worker.

（actionlint/usage.md at main · rhysd/actionlint · GitHub より引用）

custom runner や self-hosted runner の名前がエラー扱いになる

基本 runs-on: ubuntu-latest として用意された runner を用いて動かすことが多いですが、大規模なプロジェクトでは custom runner や self-hosted runner を利用している場合もあるでしょう。

このとき、runs-on: hoge のように、デフォルトで用意されていない runner を指定すると、以下のように怒られます。

label "hoge" is unknown. available labels are "windows-latest", "windows-2022", ...

これをエラーとして検出しないようにするには、actionlint の設定ファイルを以下のように設置する必要があります。

.github/actionlint.yml

self-hosted-runner:
  labels:
    - hoge

まとめ

GitHub Actions のチェックが GitHub Actions でできました！！

余談

このエントリは社内でやっている技術勉強会「忘年LT大会」向けのものですが、せっかくなので public な場で書き留めておきました。

id:arthur-1 はウロボロス的なものが好きで、はてなエンジニア Advent Calendar に「Advent Calendar の監視をする」というネタで投稿したのですが全くウケませんでした。今回もまた懲りずに同じ過ちを繰り返したわけであります。

2022-12-28

Mackerel Advent Calendar 2022 完走したので全部読む

テクノロジー日記 Mackerel

Mackerel Advent Calendar 2022 の運営をしておりました、 id:arthur-1 です。この度は、Advent Calendar にご参加いただき、もしくは閲覧していただき、ありがとうございました。

qiita.com

25日分の記事が集まり、最後まで完走することができました。自分が設定したエントリ数の監視もちゃんと動いていました。

総括というには素朴なのですが、書いていただいたエントリを読み、個人の感想としてコメントさせていただきます。

※社内・外関係なく統一して敬称をつけさせていただいております

全部読む

Day 1

isekatsukun.hatenablog.com

自分のエントリです。単位追加は細かい改修を除けば新卒初仕事だったのですが、自分が想像していた以上に社内外で反響があってよかったです。

Day 2

blog.stenyan.jp

id:stefafafan さんのエントリです。Mackerel はドッグフーディングを売りにしている割には、はてな社内での使い方を最近あまり発信できていないように思うので、ありがたい記事でした。

Day 3

yseto.github.io

yseto さんのエントリです。自分も snmp を喋れるルータを持っているので試してみました。システムメトリックとして投稿されている様子が確認できます。connectivity 監視応用は面白いアイデアですね。

Day 4

tech.buty4649.net

id:buty4649 さんのエントリです。こちらも手元に常時稼働している Raspberry Pi 4 があったので試してみました。残念ながら Mackerel には ℃ 単位がないのですが、メトリックはバッチリ見えてます。

Day 5

k1low.hatenablog.com

id:k1LoW さんのエントリです。コードメトリクス収集ツールのデータストアに Mackerel を追加していただきました。テスト実行時間は徐々に伸びていきがち。それが妥当か判断できるように自分の個人開発でも可視化してみようかなと Todo に加えました。

Day 6

qiita.com

tomotomobooks さんのエントリです。Meraki は持ってないので試せませんでした。書き出しが大変良い話だと Mackerel チームで話題になっていました。メトリックを集めやすい・とっつき易いという面は引き続き伸ばしていきたい！

Day 7

techblog.kayac.com

id:ikeda-masashi さんのエントリです。アラートの重要度は固定されずエラーバジェットによって変動する、確かに！と思いました。アラートのメモを API から編集できる機能は最近のリリースですのでぜひご活用ください。

Day 8

hktngch.hatenablog.com

Mackerel 開発チームのディレクター id:HKtngch さんのエントリです。Mackerel チームの現状の暮らし方が、アジャイル・スクラムと違う路線を歩みつつあるのは自分も感じていて、色々な機会で啓蒙していただいています。

Day 9

ryuichi1208.hateblo.jp

id:ryuichi1208 さんのエントリです。自分の個人開発も MySQL を自前で立てて運用しているものがあるので、 MySQLで使用しているメモリが徐々に増え続けているので調べたメモ - 地方エンジニアの学習日記と合わせて読ませていただきました。バグ修正の contribute もありがとうございました（私がやりとりさせていただきました）。

Day 10

blog.3qe.us

id:Windymelt さんのエントリです。Page Speed Insights 満点取りたい人間としてはぜひ監視したいメトリックです。Scala Native よくわからなくて手元の Apple Silicon Mac で build できなかったので宿題に……

Day 11

c4se.hatenablog.com

id:Kureduki_Maari さんのエントリです。mackerel-agent の plugin を作るための最低要件はこれだけですよという紹介と、例として「生命、宇宙、そして万物についての究極の疑問の答え」をメトリックとして投稿するシェルスクリプト製プラグインの作り方を掲載していただきました。

Day 12

techblog.forgevision.com

id:matsuo1017 さんのエントリです。Mackerel の機能のうち、Web コンソールからできることに絞って最新のスクリーンショット付きで紹介していただきました。organization の分け方が色々あるよというのは Mackerel を始める上でとても大切なポイントですね。

Day 13

inommm.hatenablog.com

id:inommm さんのエントリです。画面の解像度が上がるに従ってリニアに負荷が大きくなると思っていたので、面白い情報でした。オーガニゼーションに対して標準でついてくるサービスメトリック数の範囲であれば料金を気にせず色々なものを手軽に可視化できるので、ちょっとした実験にもぜひご活用ください。

Day 14

Mackerel セールスチームのディレクター id:isekatsun さんのエントリです。MSP セールスをやっていた時代の経験から、オンプレ→クラウドへの移行が進み始めた時代に、構築や監視運用のあり方が大きく変わってきた話を語っています。変化を恐れないために Mackerel を選んでもらえるようになりたいし、そのためには Mackerel が変化に対してフィットするプロダクトでなければならないですね。

Day 15

wafuwafu13.hatenadiary.com

id:wafuwafu13 さんのエントリです。mackerel-agent の configtest を機能拡張し、「もしかして、このキーと間違って typo してませんか？」という情報を出すようにしていただきました。その実装の解説をしてくださっています。レーベンシュタイン距離を用いた suggestion では Terraform でも同様にやっているんですね。

Day 16

ヤマハ YAMAHA スタジオ音質ヘッドセット YH-G01 ブラック

再び自分のエントリです。Telemetry API でログも取得できるので、Lambda 関数で定型のログを出して extension 側で取得することで、実行環境ごとに分かれたカスタムメトリック集計・投稿機能を作れたな〜と今更思っています。

Day 17

dev.classmethod.jp

kidapan さんのエントリです。インターン生に取り組んでもらったホスト一括退役機能をはじめとする Mackerel の 2022 年の主なアップデートを紹介していただきました。来年は、あれもこれも紹介したくなって困ってしまうぐらいにアップデートしていきたいですね。

Day 18

zenn.dev

sogaoh さんのエントリです。CIOps 的な内容で、デプロイと、それに伴って Mackerel による監視にダウンタイムを設定するのを CircleCI 上で同時にやってしまおう、というものでした。デプロイフロー改善に取り組んでいる我々にとって参考になりました。

Day 19

dev.classmethod.jp

cm-watanabeseigo さんのエントリです。カヤックさんが公開している OSS ツール shimesaba を使って、外形監視を SLO モニタリングする、という内容でした。Mackerel 単体で SLO 運用しにくいのも個人的には結構気になりポイントで、まずは我々の運用をアップデートさせないとな、と思っています。

Day 20

blog.stenyan.jp

id:stefafafan さんのエントリです。Github Actions から Mackerel を利用したい時のメジャーなケースがサービスメトリック投稿だと思うので、それだけの機能を持つシンプルな action は使いやすくて良いですね。action のメンテがされず朽ちていくのはあるあるなので、mackerelio の organization でこういったものも維持できると良いのかもしれない。

Day 21

tech.buty4649.net

id:buty4649 さんのエントリです。年末といえば大掃除・棚卸し、ということで、Mackerel に蓄積した情報を用いてインベントリ管理するというネタは 12月にピッタリですね。mackerel-agent を mipsel で動かすのも面白かったです。変わった OS やプロセッサ向けにも簡単に build できるのは Go 製の大きな強みです。

Day 22

genkiroid.github.io

genkiroid さんのエントリです。自分も TOML あんまり知らなくてヘルプ読みながら見よう見まねで書いていたので、なるほどと思いました。実装を知っていると TOML の Parser に渡してるだけなので等価なら大丈夫、となるのですが、それをユーザ全員が知るのは無茶な話ですし……

Day 23

kmuto.hatenablog.com

id:kmuto さんのエントリです。Mackerel CRE として入社して1ヶ月の様子をまとめていただきました。特に、Mackerel の開発合宿に飛び入り参加して作っていただいたデモは発表会で大好評でした。今後ともよろしくお願いします。

Day 24

tukaelu.hatenablog.jp

id:tukaelu さんのエントリです。カスタムダッシュボードにアラート一覧のウィジェットを力技で出すやり方を紹介していただきました。ダッシュボードが「この画面 1ページみたら良い」という存在になるために、公式として提供が必要な機能なのかもしれませんね。

Day 25

mackerel.io

id:wtatsuru さんのエントリです。見られるメトリックはたくさんありますが、パフォーマンスに影響しない下位レイヤーのメトリックに過度に敏感になったり、年々とシステムの利用状況が変化するにも関わらず監視ルールをそのままにしたり、といった悪い例を避け、監視の原則を守っていきたいものです。この思想は RDS だけでなく一般に役立つはずです。

最後に

改めて、Mackerel Advent Calendar 2022 にご参加いただきありがとうございました。

来年もより一層価値提供できるよう頑張りますので、id:arthur-1 と Mackerel をどうぞよろしくお願いします。

2022-12-27

買って良かったものランキング 2022

日記ガジェットテクノロジー

ランキングと銘打っていますが特に順位はつけていません。悪しからず。

ガジェット編

YAMAHA のヘッドセット

ヤマハ(YAMAHA)

【Amazon.co.jp限定】Dell U2723QX 27インチ 4K ハブモニター(3年間無輝点交換保証/IPS Black・非光沢/USB Type-C・DP・HDMI/フレームレス/縦横回転・高さ調整/VESA DisplayHDR 400/Rec.709 100%)

軽い！聴こえる音が良い！マイクの音質も良好！ということでおすすめです。長時間つけていてもあまり苦ではないのでリモートワークにピッタリ。廃盤になると嫌なので予備も買っておきたいです。

Dell の KVM 機能つき 4K モニタ

Dell

【Amazon Alexa認定】アレクサ対応エジソンバルブLEDスマートスポットライトダクトレール用 (ホワイト) 5個セット LED一体型調光調色スマート電球 DST-SL01WH

私物の Windows と業務用の Macbook で USB 機器をいちいち繋ぎかえる必要がなく、入力切り替えに連動して繋ぎ変わるのは最高に便利です。

あと 4K に目が慣れきっていて、フル HD の PC モニタだと文字が読めなくなってしまっています。

家電編

スマートスポットライト

エジソンバルブLEDスマート

ダクトレールにつけるタイプのやつ。見た目がシンプルで部屋をスタイリッシュに照らせるだけでなく、スマートスピーカーで制御できるので良かったです。

ただし、買うならこれではなく上位機種を選ぶことをおすすめします。上位機種であれば別売りのリモコンからの制御にも対応しています。

アパレル編

PlayStation のパーカー

www.gu-global.com

急遽お泊まりすることになって近くの GU で買ったパーカー。会社の人にめちゃくちゃウケが良かったです。素材が軽めなので春秋におすすめ。

シューズ

www.nike.com

お店で見た瞬間にこれめっちゃカッコ良い！となって買いました。ポップとクールの狭間でありたい。

技術書編

実用 Go言語 ―システム開発の現場で知っておきたいアドバイス