shinofara.dev

個人でサービスを作るとしたら今ならこうかな(2022年版)

2022年時点で個人サービスを0から作るとしたら、Next.js・GraphQL・Prisma・PlanetScale・Vercelを組み合わせたフルTypeScriptスタックが最適解ではないかと考察した記事。

shinofara3分で読める
目次+

最近仕事で、ソフトウェアアーキテクチャとか、逆コンウェイの法則とか、なんか色々考えてる流れで、個人もしくは0からなにの制約も無くサービスを作るとしたらどうするかなーって考えてみた。なお考えただけなので、それ半年後後悔するよって結果かもしれない

もしスタートアップ初期からJOINするとしたら(2022版) 以前↑を書いてから1年が経過しました。1年もあると業界の状態やはやり、そして考えは変わりますねって事で、誰が読むかわからないけど、とりあえず2022年の僕に向けて書いていきます。

https://shinofara.dev/private/join2022

これのサービス版みたいなイメージですね。

こんな構成で書いてみます。

登場人物

  1. MySQL or PostgreSQL
    1. https://planetscale.com/ でもいいし、https://supabase.com/ を使ってもいいかもですね。
  2. Backend
    1. BFF感は強いけど、FrontendとBackendの間ではなくDBとFrontendの間なのでBackend
    2. しかしマイクロサービスではないので、FrontendのためのBackendでしかない
  3. Frontend
  4. クラウドサービス
    1. Vercel
    2. PlanetScale

別で考えること

  1. WEBだけじゃなくてAPIつくるとしたら?
  2. WEBだけじゃなくてバッチ処理とかFrontned以外をトリガーとする処理は?

思考を放棄

  • SPA/SSR/SSG/ISR/SWR

とりあえず図

!["アーキテクチャ図"](./Untitled 10.png)

flowchart LR
	UA--HTTPS-->Frontend
	UA-->React.js-->GraphQL
 
	subgraph Vercel
		subgraph Frontend
			Next.js
		end
		Next.js-->GraphQL
		subgraph Backend
			direction TB
 
			GraphQL["Next.js API Route Endpoint"]-->Apollo
			Apollo-->Resolver
			Resolver--Query-->PrismaORM
			Resolver--Command-->DomainLayer["DomainLayer"]-->PrismaORM
		end
	end
 
	subgraph PlanetScale
		PrismaORM-->MySQL
		MySQL
	end

マイクロサービス的に様々な用途に使われるAPIだとしたら、GraphQLのQueryがほぼそのままMySQLのクエリをWrapしてるみたいな開発は避けたほうが腐敗防止的にもいいと思うんだけど、まぁFrontendのためにしか使わないGraphQL Endpointという前提を置くとこれでいいんじゃないかな。

けどCommandはDB更新するだけならまだいいけど、トランザクション処理したり、他のAPI巻き込んだり、なんかまぁ色々複雑になると思うので、そこはDomain Layerにお仕事させるなど

Schedule Jobどうすうる?

Cron Jobs Cron Jobs allow you to schedule tasks at specific intervals.

https://vercel.com/docs/concepts/solutions/cron-jobs

一昔前のCloud Runとか、Serverless系(FunctionsやLambdaなど)はHTTPトリガーしかなかった(厳密にはpubsub eventとかあるけど、一旦置いとく)時代とおなじかな。HTTPで書いて叩こうね。ただ同じRuntimeに乗る以上リソースを専有されたくないので、Serverlessの良さを使ってスケールさせたり、HTTP Timeoutを拡張する考えじゃなくて、冪等に処理できるようにしてやっていくとかそういう戦略は必要かな。

まとめ

一昔前ならRailsとかLaravelとかまぁそういうフルスタックフレームワークがカバーしていた事を、全てNode.js(TypeScript)で書くほうが、Rails + jsで書くよりフロントが書きやすくなるし、FrontendとBackendを書く際に言語をスイッチするコストも掛からないってのは、一つの形としてありだよね。

個人的にはGoの硬さが好きなので、好きを見て自分の中での2022年版のGoかくなら〜を書いてみたい。

github.com

この2021も妄想で書いただけなので、まぁそれはそれ。

とりあえず、深く考えてないで書いてるので、もう少し調べたり色々見聞きしたりしたら確実にかわるとおもう。でもとりあえず昔はJavascriptがこんなに活躍する世界はおもってなかったよね。

Google MapがAjaxだ!って言って地図をぐりぐり動かせるようになったあの時は感動したけど!

追記

書いてみた

github.com

shinofaraソフトウェアエンジニア。AI と人間の協働による開発に関心を持つ。

Written by human記事一覧に戻る