【2024年版】API構築の個人的な技術選定ベストプラクティス(パターン別)

APIの技術選定 技術選定

この記事では、WebサービスでAPIを新規構築するときの
技術選定について、個人的なベストプラクティスを紹介する。

前提:筆者の各プログラミング言語に対する解像度

最初に、筆者の各プログラミング言語に対する解像度を共有しておく。

今回の記事は網羅性・客観性を欠くため、
これを読んだ人に前提条件を伝え、判断材料にしてもらうという意図である。

  • Java
    • API新規構築〜保守まで経験あり
    • 一番長く使っている言語
    • フレームワークはSpringBootを使用
  • Python
    • 個人開発で結構書いている
    • Flask、FastAPIはチュートリアルのみやったことあり
  • TypeScript
    • フロントエンドの開発でよく利用していた
    • ExpressやNestJSは少し触ったことがある
  • Ruby
    • 既存コードの改修経験はある
  • PHP
    • 既存コードの改修経験あるが、そこまで解像度は高くない
  • Go
    • Hello Worldしかやったことない

パターン別技術選定

①個人開発

結論

自分の好きなもので良い。

理由

  • 個人開発は新しい言語に触れるチャンスである
  • 共同開発しないので、誰にも迷惑がかからない

②サッと作って、すぐに壊す予定があるもの

結論

Ruby on Rails(Ruby)

理由

  • 作り始めが速い
  • ほぼDBを意識することなく構築が可能
  • かなりルールが多いフレームワークなので、設計とかに悩むことが少なくなる
  • 日本語ドキュメントも多いため、困ったときに調べやすい

③MVP開発を行う

とりあえずサクッと作ってみて検証し、市場の反応が良ければ規模拡大していくもの。

結論

NestJS(TypeScript)

理由

  • 最近はフロントエンドをほぼTSで書くことが多いため、同じ言語が使えてコスパが良い
  • ライブラリ開発も活発なため、実装に困ることはほとんどない
  • 中でもNestJSは標準でDIの仕組みがあるため、大規模に成長しても十分力を発揮する

④複雑なデータ構造を扱う中規模〜大規模開発

具体的にはECサイト、ヘルスケア、金融、プロジェクト管理など
扱うデータの多様性や関係性が高度である場合。

結論

SpringBoot(Java)

理由

  • 言語レベルで型定義を強制でき、複雑なデータ構造を取り扱うのに優れている
  • 安定性が高いフレームワークで、破壊的変更が比較的少ない(互換性重視のアップデート)
  • プログラミング初学者の場合は学習コストがやや高いのがデメリットではあるが、それでも旨味がある

⑤AI系の技術を取り入れたAPI開発

結論

  • FastAPI(Python)

理由

  • AI分野に関するライブラリの豊富さではPythonが優勢である
  • 取り扱うデータ構造が複雑になりがちなので、型ヒントは必須で入れる
  • Pythonのライブラリの中でも、FastAPIは非同期(async/await)が使えるところが良い
  • FastAPIは自動的にAPI仕様書(swagger等)を生成してくれるところが嬉しい
  • API全部をPythonで構築するというよりは、レコメンドAPIなどAI特化の機能群を抜き出し、マイクロサービス的に設計する可能性が高い

⑥とにかくパフォーマンスが求められるもの

結論

Go(筆者はフレームワークについて詳しくない)

理由

  • 静的型付け言語である
  • 言語レベルで並行処理性能が高い

⑦社内ツール

結論

以下どちらかで考える

  • 社外に向けたWebサービスと同じ技術スタックを使う
  • 社外に向けたWebサービスよりも新しい技術の検証という側面を兼ねてチャレンジする

理由

  • 社外のサービスで事故が起こるより、社内サービスでの事故のほうがリスクが低い
  • 保守の頻度が低くなりやすいため、新しい技術を使う場合はアップデートの頻度についていけなくなるリスクがあることに注意が必要

まとめ

Webサービスというものは成長し続け
最初に作ったときよりも複雑で大きなシステムになるのは必然。

プログラム内部の書き方は後からでも変更しやすいが、
技術選定やアーキテクチャの設計は後から手を入れるのは困難である。

そのため、技術選定とアーキテクチャの設計は
手を抜くと後で痛い目を見るだろう。

タイトルとURLをコピーしました