ここ3日ほどAmplify（+Next.js）と取っ組み合って得た知見を残しておく。

Amplify SSRでNext.jsのAPI Routesを動かすのは（この記事書いている時点では）無理っぽい

  • next exportはAPI Routesを除外するため
  • SSRでAPI動かしたかったら結局Serverless使わないといけないみたい

そもそもなんでAPI Routesを使いたかったかというと、 GraphQLのエンドポイントをNextアプリの中に組み込みたかったから。

ローカルで立ち上げるときにいくつもサーバプロセス上げたくなかったので、 シンプルなGraphQLサーバだったらNextのサーバにミドルウェアとして組み込んでしまえばいいと思ったのだ。

サーバが複数になるとリクエストを振り分けるためのリバースプロキシを建てなくちゃいけなくなったりして面倒くさい。

まあでもあんまりうまく行かなさそうなので、config rewritesでエンドポイントを振り分けるようにして、ゲートウェイはNext.jsのサーバに集約しようと思った。

自分の発想として、まずローカル環境でどう立ち上げるかを考えて、その後本番環境でも同じように動かす仕組みを考える。逆でもいいがとにかくローカルと本番で違った構成で動かす環境は信用できないという感覚がある。 モックとかエミュでもいいけれど、アプリケーションコードから見た違いはなるべく最小限に抑えたいと思っている。 例えば自分がコンテナ技術が好きなのはガワは別としてコンテナの中身は同じ環境に揃えられるからだったりする。

APIとして既存のAppSyncを追加するのは難しい

  • CloudFormationを直接弄るといけるっぽいがそこまでしてやりたくない
  • 結局DynamoDBバックエンドをテンプレ構築するくらいしか用途がないのでかなり狭いユースケースだと思った
    • 新規でアプリ作ってローコストで動かしたいみたいなケースではさくっと作れていいのかな
    • そもそもDynamoみたいな分散KVSを従量制のドキュメントDBとして使うみたいな使い方が好みではない
    • RDBでいいじゃん、Aurora Serverless使おう
  • lambda実行するだけならAPI Gateway+Apollo server lambdaとかで作ったほうが楽なので、実質DynamoDBのフロントみたいになってる
    • 一応謳い文句では色々バックエンドに繋げますよと言ってるけれど、Dynamo意外のユースケースははっきり言って辛いと思った

まあ結局汎用GraphQLサーバとしてはまだこなれてないという印象。 自分の期待していた役割は汎用のAPI Aggregatiorだったんだけど、その用途だとまだちょっと使いにくいなと思う。 もうちょい使いやすくなればまた使ってみたい。

小さめの規模感のアプリやプロトタイプで使うにはいいのかもしれないけれど、 単にAPIサーバのインターフェースをGraphQLに集約したいだけなら、 GraphQLサーバを自分で書いて、lambdaあたりで出したほうが早くていいと思った。

Amplifyについて雑感

Vercelとの比較だとやっぱVercelが楽だと感じた。ただAWSの中で使う分にはAmplifyも楽だし、機能的に足りないところもどうせAmazonだからそのうちなんとかしてくれるでしょという期待感もあってもうちょい使ってみようかなとは思っている。

というかNext.jsはやっぱりフロントエンドのためのフレームワークで、バックエンドとの共存はある程度こっちで考えてあげないといけないので辛みがある。

多分API群はLambdaなどで別途用意して叩くだけみたいな設計ならうまく回るんだろうけど、 自分は古い人間なので画面テストはローカル環境で完結させたいからサーバレスのAPIもローカルで建てたくなってしまう。 そうすると色々準備しないといけなくなって環境作るのが大変だなと思った。

バックエンドとフロントエンド切り離して開発する分にはNext.jsは楽だしAmplifyみたいなエコシステムに乗っかっていれば効率的なんだろうとは思う。

逆に今の複雑化したフロントエンドとバックエンドで統合して開発するのはもう無理なのかもしれない。Railsの時代にはもう戻れないように思う（Rails自体はまだまだ現役だし、ある程度フロントエンドのことをオミットしてバックエンドもモノリシックにやるなら今でもフレームワークとして最強だとは思う）。