takos.dev

Appearance

On this page

🛠

もしも今新しいサービスを作るならどういう技術を採用するか

2023年08月12日 23時頃 投稿

もしも今、なにかサービスを作るとしたらどういう技術を採用するか、という覚書。

どうせ数年たったら全然違う技術セットになる気がするので、今のメンタルをメモっておきたかった感じ。

条件 ​

自分の趣向としてB向けの業務システムが好きなので、そういう何かを作るとしたら。

クライアントサイド ​

たぶん、Webがベースになってくると思う。
ネイティブアプリで作るってことはあんまなさそう。
業務用だとまだ想定ユーザーの端末がPCなことが多いだろうし。

で、基本的にはSEOなりFCPなりが重要視されるということも無いはず。

となるとSSRやRSCといったサーバーレンダリングの必要性が薄いので、シンプルにSPAで構築することになるはず。

そうなると候補としては

  • React
  • Vue
  • Svelte
  • SolidJS

あたりから選ぶことになるけど、安牌ならVue、やってみたいのはSvelteって感じ。
Reactはいいや。むずいし。潔癖さが求められすぎて辛たん。

API ​

SPAなので、何らかの方法でサーバーとコミュニケーションしなきゃいけない。

  • REST API
  • GraphQL
  • gRPC web

だいたいこの3種類かなぁ。
とはいえgRPC-webはトガりすぎだから、実質RESTかGraphQLじゃないかなとは思うんだけど、他になにかあったっけ。
(gRPCでない）RPCの何かいけてるプロトコルあったかしら。

GraphQLは1年くらいしか使ったことないけど、そこまでいいもんじゃなかった印象。
サーバーサイドもクライアントサイドも自分で書くから、そうなると「GraphQLでリソース用意しておけばクライアントサイドの開発者だけで自由にリソースを取得できる」という点のメリットは特にメリットにならない。
なので、使うとしたら、「複数のリソースを1リクエストで取得できる」っていうHTTPリクエスト数を絞る効率化が目的になってくる気はしてる。
で、そのトレードオフとして「ある程度自由に取得できちゃう」ってのが発生するわけだけど、サーバーサイド作るときの考慮ポイントが増えてあんま嬉しくなかった、というのが自分のGraphQLに対する感想。
ハマるシーンが世の中にあるのは非常に理解できるとこだけど、なんだかね。

となるとRESTかぁという気もする。
RESTも結局「正しいREST」で作れたことなんてなくて、REST+RPC的何かをRESTっぽい雰囲気で表現することで、チーム内でなんとなく意図が伝わるくらいのことしか過去やってきてない。

やっぱもう何かいい感じのRPC APIを作るほうが、変にリソース名に悩んだりしなくていいんじゃねという気持ちは最近強い。

ああそういえば JSON-RPC ってのがあったか。
うん、 JSON-RPC がいい気がする。なんか楽そう。

サーバーサイド ​

VueなりSvelte と JSON-RPC でコミュニケーションするサーバーは何がいいか問題。

業務システムを作るにあたって大体必要になるのは

  • なんかExcelなりCSVなりを読んだり書いたりするやつ
  • いい感じにPDFを生成して出力するやつ
  • 10分以上かかるようなバッチ処理を実行するやつ
  • 変更履歴や操作ログ系の情報をいい感じに保持できるやつ

この辺はだいたい必要になってくる印象。

どの言語でもできるよね、はその通りで、いかに楽にこれを作るかってあたりが焦点。
とはいえPythonやらRubyは好きくないので、

  • PHP
  • Golang
  • JS/TS

あたりが自分の今のスキルセットだと候補になってくるところ。
やってみたい系としてはRustとかKotlinあたり。

JS/TSが候補にあがったとて、NextやNuxtのSSR/RSC/AppRouterあたりのレイヤーでゴニョゴニョする気はあんまない。
確信があるわけじゃないけど、バックエンドの処理はそのレイヤーとは分けておいて、そこはBFFくらいの気持ちで扱うのが幸せそうな直感がある。

PHPでやるならLaravel ​

普通に慣れてるし、ここ5-6年はずっとLaravel触ってるから、全部わかってるし、「早く・確実に」みたいな温度が強いならLaravelでやっちゃう。

なんの不足も心配もなく、ただただ作れると思う。

Golangでやるなら ​

Golangで何採用すべきかは正直ようわかってない。

Beegoが良さそうなのかな、たぶん。あんまわかってない。

JS/TSでやるなら ​

そもそもランタイムは今何がいいんだろ。

Node / Deno / Bun

Deno/Bunに手を出したい気持ちはありつつ、たぶんNodeで始める気がする。安牌そう。

頭がExpressとかKoaの時代で止まってるから、フレームワークもわかってねぇ。
NestJSかな？

結局どうするのか ​

結局どれがいいのかわからんけど、安牌ならLaravel、チャレンジ系なら最初にNestJSやってみてからのダメそならBeegoやってみる、って感じかなぁ。

データベース ​

慣れてるからって理由だけでRDBMSはMySQL、KVSはRedisを採用。

インフラ ​

悩ましい。たぶん初期は安く抑えたいからいろいろゴニョゴニョしそう。
最終的にはAWSに落ち着くんでは。

まとめ ​

安牌かチャレンジかで変わってくる感じ。

共通 ​

  • JSON-RPC
  • MySQL
  • Redis
  • AWS

安牌コース ​

  • Vue
  • PHP / Laravel

チャレンジコース:A ​

  • Svelte
  • NodeJS / NestJS

チャレンジコース:B ​

  • Svelte
  • Golang / Beego
home