サンプル

https://github.com/inadati/sample01-AttendManager.services

コンテナ構成

DB

  • PostgreSQL

cron処理

  • busybox

cronで叩く用graphql api(非公開api)

  • gqlgen
  • gorm

公開用graphql api

  • gqlgen
  • Prisma(Liftのみ使用)
  • gorm

クライアントアプリ

  • nuxt
  • Apollo Client

その他

本番公開にhttps-portalを使用(別コンテナ)

graphQLサーバーを立てる上での躓きポイントをまとめる

※下記は今後、別記事にしてリンクを貼るようにします。

Hasuraによって作れるapiはいかなる場合もweb公開するしかないという話

PrismaはORMを使い、内部的にSQLを叩くことでDBを読み書きしているので
Prismaが自動生成するapiを直接、web公開する以外にも
prismaのORMを使い、別途公開用のgraphqlサーバーを立てることが可能です。
ですが、hasuraはORMではないので、hasuraが提供するgraphql apiは、http通信を通して叩くしか
DBの読み書きをする方法がありません。
つまり、hasuraではPrismaのように別途、公開用のgraphqlサーバーを立てるという事はできないという事です。

これについては、僕にもう少し
ネットワークの仕組みについて理解があれば躓く事はなかったのですが
こちらの記事の

Prismaと違ってHasura GraphQL Engineはクライアントから直接呼ばれることも可能だが、凝った実装しようとするとやはりClient専用のGraphQL Serverは必要

という情報からhasuraでもPrismaのように別途、公開用のgraphqlサーバーを立てられるのだと
誤解してしまっていました。

その結果、hasuraに対してapolloクライアントを使ってgraphql apiを叩いてやる為の
graphQLサーバーフレームワークを作るという試みを一度やってみたのですが
完全に思惑はハズレました。

なにぶん、僕自身まだまだフロントエンドの方が長く
サーバー側の常識が十分に分かっていなかった為に起こった躓きです。

前の記事では、
2019年末時点でgraphqlサーバーを立てる上でのオススメのプログラミング言語は
goよりもnode.jsが良いと言う旨の記事を書きましたが
前言撤回
gqlgen + Prisma(Lift) + gormがかなりイイ感じで開発が楽そうです。
特に、prismaのORMは非常に使いづらかったのですが
gormでresolverを書くのは、かなり楽でした。

今回のその他の躓き

大したことでは無いのですが
postgresのコンテナがDBの内容を出力する
今回のサンプルでいうところの「postgres/data」ディレクトリ内の一部のディレクトリが空の場合
git pushすると消えてしまって本番環境でpostgresコンテナが起動しないという事態が発生しました。
gitは空のディレクトリはcommitしてくれないので空のディレクトリで必要なディレクトリは
.gitkeepを入れときましょう。
とただそれだけの話なんですが
割と小一時間頭を抱えたので書いておきます。

まとめ

今回のサンプル、まだ若干必要な修正があるものの
ようやく、graphqlを活用したサンプルアプリを公開することができました。
次は、画像アップロードなど研究しようと思います。

しかし、
gqlgenにしろ
prismaのliftにしろ
gormにしろ最高です。