ガチじゃないけどいい感じのインフラでPrismaを運用したいときの設計で悩んだので覚え書きしておきたい

July 13th, 2019

個人プロジェクトでGraphQLを使いたいとなったときに、リッチじゃないけどそれなりに管理しやすい安定したインフラを作ろうとすると結構困ったのでメモしておく。

動くものまで作れたわけじゃないので後日更新するかも。

やろうとしていること

  • BFFを挟んだSSRのSPAを作りたい
  • APIはGraphQLでなんとかしたい

使おうとしているもの

  • フロントはnowでnext.jsを載せようとしている
  • バックエンドは何でもいいけどPrismaでマイグレーション & GraphQLのラップをさせようと思っている

選択肢として考えたもの

  • AWS AppSync

    • Prismaじゃなくなるけど、AWSのバックエンドに対してGraphQLでラップしてくれるっぽい
    • 個人プロジェクトでいきなりAWSか〜という感じはしたけど、結構信用できそうだし確度は高く考えてた
    • ただ、IaCまでちゃんとやろうとするとコストがかかりそうで、スピード感が落ちるのを懸念した、僕はインフラエンジニアではないし、今回身につけたいのはそこではないので
  • Cloud | Prisma

    • Prismaのマネジドサービス
    • そのままデプロイして使ったり、Herokuをバックエンドにして使ったりもできる
    • あとで書くけど、IaaSとしてプロダクションでは使うのは無理
    • 今回はHerokuバックエンドを使ってこのPrisma Cloudを使ってみることにした

インフラの構成

最終的にはこう。

SPA(now) -> BFF(Prisma Client on Heroku) -> Backend(Prisma Server on Heroku with Prisma Cloud)

BFF

ちょっとBFFとBackendがわかりづらいんだけど、BFF自体はリゾルバを持ったGraphQLエントリポイントで、フロントからもらったリクエストを元にBackendに通信をする。

雑に言うとBackendのPrismaをapollo-serverもしくはgraphql-yogaでラップしたもの。なのでこいつが外部公開される。

認証やデータの加工などの処理もここでやる。

Backend

BackendはただのPrismaサーバ。データベースサーバみたいなもので、外部公開はされず、BFFのみがクライアントになる感じ。

ここには処理もなんにもなくて、PrismaがDBの前にたっているただのサーバ。なので一度立ち上げれば基本的に変更は入らない。

Prisma Cloudでもそれはできるんだけど、アクセス数の制限等があるのでできれば自分で持ちたかった。

あとPrisma Cloudは以下にあるように、

Demo Servers (Prisma Cloud) - Prisma Docs

次を目的として使う想定の模様。

  • Prototyping
  • Learning
  • Personal projects without a notable user base

そしてスロットリングもかかっているので無理したとしてもプロダクションでの利用は無理だと思う。

Prisma Demo servers are rate limited to 10 requests per 10 seconds (on average).

余談

始めはBFFにバックエンドも混ぜようかなと思ってた考えてたけどそれはやめた。

以下の記事を読んで、BFFが完全にサーバサイドみたいな存在になるとそれってBFFではないよなと。

Some thoughts on GraphQL vs. BFF

Prisma、あとで捨てるのはほぼ無理なツールになると思うのでちょっとそこが懸念かな・・・。GraphQLはまだ成熟期ではないと思うので、そういう心配事は無視して進もうかと思う。

AUTHOR

Daisuke Tsuji
Daisuke Tsuji@dim0627

フリーのWeb Developer。

RubyとかRailsを触ってる時間が多い。コーディングもマークアップもライティングもデザインもSEOもやるタイプ。

だいたいどれもだめ。