t_wの輪郭

DynamoDB+AppSync、初動のみ爆速で、その後の開発速度の失速も早かった。
AmplifyのDataStoreも同様。半年以内で負の遺産だった。

> これまで、開発者は AppSync のビジネスロジックを実装するためには Velocity Template Language (VTL) しか使えませんでした 。VTL は強力ですが、テンプレート言語に精通していない多くの開発者にとって困難なものでした。
ホントだよな！ 中の人に相談したときにも「わけわからん」って言われたもんなっ！

VTLチラチラ見ながら「絶対VTL無理でしょ。よしんばなんとかできても引き継げないでしょ。」と思ってたけどやっぱ地獄なんだ。

Amplify Gen2、私はPreviewではなくなるまでは触らんぞ。

あと、VTLはAppSyncのほうが「VTLやめてくぜ」って書いてたから、Amplifyどうするんだろうと思ってた。

ブログのお引越し作業中

実質システムの作り直しなのでまだまだ時間がかかる

うぐー！！！！純朴なPostgresqlで作ったブログシステムに、読み込み速度で勝てない！！DynamoDB使ってるのに！！！

Postgresql先生、DynamoDBで2秒かかってるものを、300msで返してくるのは止めていただきたく。

DynamoDBつーか、AppSyncのAPIを叩きまくってるアレのせいな気はする。

Next.jsのcacheを有効化したら、ページの取得に2秒とか要していたのが、100msになった。良き。

むむ、localhostで動いてたのをAWSに移すと遅くなるな。そりゃそうか。

AWSに移したら遅くなったのが気に入らなかったので、CloudFrontに乗っけた。
運が良くCloudFrontのキャッシュにHitすると10ms程度でページが取得されるようになった。
https://main.d21776nrisgiy.amplifyapp.com/

https://speakerdeck.com/okaharuna/next-dot-js-x-aws-app-runner-x-aws-appsyncdejin-merukuraiantohuasutonowebkai-fa

https://stackoverflow.com/questions/52694693/calling-appsync-mutation-from-lambda-with-golang