Web APIを手作りする時代は終わった？

::: message info これは[フィヨルドブートキャンプ Advent Calendar 2022 Part.1](https://adventar.org/calendars/7760)の25日目の記事です。 昨日の記事は:@shujiwatanabe:shujiwatanabeさんの[質問しながら出来るようにしていく](https://shu91327.hatenablog.com/entry/2022/12/24/091025)と:@saeyama:saeyamaさんの[Rails/Vue 編集時に画像をD&Dで入れ替えした時のActive Storageの保存方法](https://saeyama.hatenablog.com/entry/2022/12/24/000123)でした。 ::: ↓こういうのを職人が丹精込めて一つ一つ手作りする時代は終わりました。 ```sh

[fog-og-frog2]

DBスキーマをWebAPIとしてそのまま公開したら、仕様変更でスキーマを変えたいなどの要望が入ったときに調整しなくちゃいけないアクターの数が増えて死ぬことが多い。なんだかんだでワンクッション入れるのが良いと思う

[cloverstudioceo]

えーこんなんプロジェクトの序盤でしか役に立たないじゃん。

[peller]

これで9割まかなえるプロダクトの設計って一体…

[takuya_1st]

SQLの劣化版みたいやAPI専用のクエリ言語が再発明されて、みんなが苦労する未来が見える。

[tivrsky]

手作りしなくてよくなったけど、PostgreSQLのviewとかfunctionを目一杯使って複雑なSQLを書くように必要な技術が変わる

[Eiichiro]

2層システム時代に戻ってきた感がある。

[otchy210]

GET の API では JOIN した結果が欲しいことも多いと思うんだけど、その辺どうなってるのかな？VIEW 作れば解決しそうだけど、1:n をいい感じに配列で返す GET は出来るのだろうか。

[az1za]

9割どころか超シンプルな開発じゃないと使えないと思うけどな。継続的に機能追加が求められるレベルのプロダクトでは逆に足枷になってスケールしにくそう

[koda3]

これも良さそうだけど、Hasuraのほうが良いかも

[houyhnhm]

トランザクション気にしなくていい場合？結構DB負荷高そう。

[kzbe]

Web APIを機械で作る時代が始まっている。

[kitone]

“PostgREST”

[shun9167]

これすごいな。。MySQLでも使えるのかな・・？

[bellonieta]

SupabaseでPostgREST触ったけど、RLSが面倒すぎて結局普通にAPI手作りした。

[iga_k]

PostgREST便利〜

[greencoffeemaker]

低レベルなOR Mapperとしては良さそう。他の人が言及していたようにDB変更で影響受けるからこれを吸収するために一段間にモデル層を設けた方が良いのではと思う。

[helldeath]

たしかに手作りはしたくないのでGoogleのスプレッドシートとAppScriptでWebAPIにしている。だがAppScriptを書いているので手作りになってしまった。

[n314]

使わないだろうけど面白そう。と思ってソース見に行ったら、一番面白そうなポイントはHaskellで書かれていることだった。

[komi1230]

仕様変更に対応するの大変だから俺たちはバックエンドを書かなきゃいけないんだよなぁ....(プロジェクト初期では役に立つのかもしれんけど)

[tettekete37564]

ブコメは大体私と同じ感想で良かった。負荷分散とかどうすんのって話。

[tinsep19]

前面をGraphQLにしてバックエンドがこれならありな気がする

[remonoil]

モック用かな？

[tofu-kun]

RLS 使ってるのか、なるほどねー

[dekasasaki]

あまりにもプリミティブなAPIだ…

[NOV1975]

システム要件とかいらない世界の人は気楽でいいなーってコメントで埋めとけ

[Rynk_m]

read-modify-writeパターンはどう実現するんだろう？get系は任せられそうだけど、post系もRMWパターンをストアドプロシージャとかで実現できるなら、かなりあり。

[dozo]

APIモックを作る話かと思ってた

[odakaho]

マスタ管理画面を自動生成して「管理画面は9割完成！」って言ってそう

[circled]

文句を言ってコメント多いけど、バックエンドでお使いのフレームワークがORMでやってるのは、APIリクエストからSQL発行してJSON返すみたいな同じことだっての忘れてない？マネージドDBが増えた昨今、スケールも余裕だろ？

[masatomo-m]

中小企業のB2Bや社内エンタープライズアプリだと権限管理もデータ量も知れてるからそういうのに使うならまあ。ただ一般的に言うWeb APIってB2Cやpublic APIとかを連想するのでこれで終了宣言されるとうーん・・・とはなる

[KoshianX]

へー、これおもしろいな。ひとまずDB設計だけしておけばそのまんま Web API になるのか。そのまんま本番環境まで開発可能なのかわからんけど、OpenAPI 出力してくれるならそこからバックエンドの雛形生成もできるな

[ed_v3]

スケールしない前提の個人開発用ならいんじゃね。

[nicht-sein]

単純なCRUDのラッパをWebAPIだというのなら、もうとっくの昔に終わってる

[j1nsuke]

単純にDBからデータ出すだけってそんなにあるかな。ドメイン固有の処理とか挟む必要バリバリあると思うというか、むしろそこが本質だから手書きしてるんじゃなかろうかという気もする。

[mayumayu_nimolove]

あなたの中で終わってるだけだよ

[razokulover]

Supabase使えになりそう

[onesplat]

いずれ要件が満たせなくなって全部書き直す未来が容易に想像できる。お遊びプロジェクトならこれでよいかもしれんが

[facpatrysis]

アプリケーションサーバはあった方がいいよ。CRUD的なのをすぐ生成できる仕組みを作る|探したほうが後が楽。手書きするのは無駄だからやめた方がいい