🎃

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

に公開
Python
TypeScript
Go
backend
tech

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

python or go or typescript で考えたい

  • AI との親和性なら python

  • 静的型付けなら go や typescript

    • python でもやれなくはない

  • python は framework 単位でもみないとか

    • 一旦 fastapi 決め打ちで

ポイント

型

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

結論

  • △ python
  • ◎ go
  • ◯ typescript

Dependency Injection

API docs/コードの自動生成

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

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

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

  • どちらも目指してる先は同じ。仕様と一致するスキーマを生成する。yaml で書くのか、コードで書くのかの違い。yaml 書くのはつらい

    • 個人的にはあまりにスキーマ定義が便利に書けるので、たとえスキーマファーストであっても、スキーマ定義を書くエディタとして FastAPI を使ってもいいと思うほどです。

  • fastapi のコード=実装ではない(mock 実装できる)。
  • スキーマファーストだと細かいロジックの反映とかしにくいのでは？

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

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