🎃

2023年のwebアプリのbackend言語選定

2023/08/21に公開

2023年、server sideの言語選定はなにがいいのだろう？

python or go or typescriptで考えたい

AIとの親和性ならpython
静的型付けならgoやtypescript
- pythonでもやれなくはない
pythonはframework単位でもみないとか
- 一旦fastapi決め打ちで

ポイント

型

fastapi
- Pydranticがある(機能 - FastAPI)
go
- compile時に厳密にチェックされる
typescript
- compile時にチェックされるが、間違っていても通ることもある
- 一度通ってしまうとjsでは型がないので、runtimeでエラーがでることがある

結論

△ python
◎ go
◯ typescript

Dependency Injection

fastapi
- 強力なDIがあるらしい(機能 - FastAPI)

API docs/コードの自動生成

fastapi
- コードファースト
- mockコードからでも自動生成される(FastAPI)
go
- スキーマファースト
- スキーマからコードを自動生成するpackageは色々とある
- OpenAPIからGo言語のコードを自動生成してくれるツールを試してみた
typescript
- goに同じっぽいけど、こっちはクライアントなのかな？
- server side typescriptのことがあまりわかってないので要調査
- Hello from OpenAPI Generator | OpenAPI Generator
- Protocol Buffers から TypeScript の型定義を作る

コードファースト or スキーマファースト

そういう考え方があるらしい

コードファーストのほうが楽では？

どちらも目指してる先は同じ。仕様と一致するスキーマを生成する。yamlで書くのか、コードで書くのかの違い。yaml書くのはつらい
- 個人的にはあまりにスキーマ定義が便利に書けるので、たとえスキーマファーストであっても、スキーマ定義を書くエディタとしてFastAPIを使ってもいいと思うほどです。
fastapiのコード=実装ではない(mock実装できる)。
スキーマファーストだと細かいロジックの反映とかしにくいのでは？

Protobuf使うのもコードファーストでは？

PRC・gRPC・Protocol Buffers
今さらProtocol Buffersと、手に馴染む道具の話 - Qiita
OpenAPI や Protocol Buffers のおかげで開発がかなり捗っている話 | MEDLEY Developer Portal
そもそもソフトウェアエンジニアがメンテしにくい言語でスキーマファイルを触るのがNG(openapiならyamlを生で触るとか)

GraphQLもスキーマファーストか

結論: スキーマはメンテしやすい言語でメンテすれば良さそう

openapi: fastapi
非openapi: protobuf, GraphQL

友人のコメントメモ: go + protobuf一択

パフォーマンスのボトルネックを考慮したほうがいい

機械学習と相性がいいからといってAPIまでpythonにしなくていい
一緒にすると計算リソースが密結合してしまう。スケールしにくくなる。
- 機械学習はGPUやメモリがボトルネックになることが多い
- APIはCPU、ネットワーク
- これはなるほど
つまり
- 機械学習projectなら、機械学習モデルはpythonで簡易なREST APIを組み、メインはgoで作る

goは静的型付けが厳密, typescriptは緩い

なんでゆるいのかはよくわからなかった
typescriptの型の付け方の仕様まわりに何か問題がありそうだという話だった

typescriptは簡単なこともあり、人材のチェックが難しいらしい

未経験の人材が大量にいるため
実績の文字面だとスキルがわかりにくいらしい

スキーマ言語はprotobufがいい。go使うなら特に

goもprotobufもgoogle製で相性良くメンテされているとのこと

GraphQLは仕様が複雑化するに従い、つらくなる

これもなんでだったかな。protobufほど表現力がないから、とかだったかな

Discussion