2024-01-05

frontendがめまぐるしくかわるうちにbackendは技術スタックがクラスタ化した

WEB frontend開発が日進月歩でどんどん進化してたのってReact Hooksが出たくらいまでで、それ以降はビルド環境も安定し2024年現在frontend開発における迷いは少なくなった。React系のライブラリ、フレームワーク選べばビルド環境もついてくるしデプロイ先もたくさんある。そんな感じでここ10年くらいはfrontendメインで業界を見てきたんだけど、しばらくbackendに疎くなっていたらいつのまにか多極化したように見える。

php, ruby, python, javascript等を使ったfrontend含む伝統的でモノリシックなシステム
OpenAPI or JSON Schemaを使ったREST API
Laravel等フレームワークを使ったりhasura等で構築したGraphQL
golang等で作ったgRPCの固いアーキテクチャ
Firestore, Cloud FunctionsなどほぼBaaSでまかなう開発スピード全振りのシステム

上記は単独で使う以外にも合わせて使ったり、マイクロサービスにしたり、BFFおいたり、そもそもインフラまで含めれば膨大な選択肢がある。もうbackend＋インフラのアーキテクトって個人で行うの不可能なのでは？とも思う。さらにRemixなんかはfrontendからbackend界に逆進出してるし、今後もしばらくbackendは百花繚乱なのだろう。

これらはそれぞれ学習コストがかかるので、backend知識、経験として共通する部分はあるにせよ、経験した以外の選択肢は選ぶのが難しく組織や案件ごとに利用アーキテクチャがクラスタ化していく。これまで（というか自分の知ってる昔のbackend）はクラスタ化と言ってもMySQLかPostgresQLかのような今からすると屁みたいな差だったのでこれからbackend開発していく人は大変だなと思う（他人事）

とはいえ関わることもあるので自分的なキーポイントを考えてみた。

1、データをどう持つか。

今も昔も変わらない問題。無難なのはRDBMSで正規化されたスキーマでデータを保持すること。NoSQLには未だにメリットを見いだせていない。Firestoreはsecurity rulesが特殊過ぎてonSnapshotが必要なデータのみに留めたほうがその後の運用が楽。使い捨てのサービスをサクッと作るのは便利とは思うけど。RDBのマスタサーバ書き込み問題はスケールアップで結構持たせられるし、バックアップもうまくサポートしてくれるし特にいうことが無い。SQL互換DB以外を選択する強い意志も無い

2、frontendとのドメイン知識の共有をどう行うか。

OpenAPIでもJSON SchemaでもGraphQLでもgRPCでもtRPCでも何でも良い。一番汎用性があって楽なのはGraphQL、ついでOpenAPI。個人開発レベルなら最大工数払うとしてもGraphQLなんじゃないかな〜と思う。それよりもRemixとか使って楽する方が良い場合も多そう。対応しない選択肢はない。仕事ならありえないし個人でも型なしでやるのはきつい。

3、自分が楽しいか、耳目を集めているか

つらい選択肢は選びたくない。マイナーで問題解決が基本コントリビュートなものとか。サクッと簡単に作れて使ってる人多いやつがいい。サクッと簡単に作れるなら多少マイナーでも良い。作るステップが多くてもメジャーなら良い。あと人集めるときに集めやすいのが良い。Server-side Swiftとかチャレンジングで面白いけど採用難易度高すぎる。でも金あるならこういうピーキーな方が優秀な人材集まるのだろうか。

つまりまとめると、 - 最速（少コスト）でやるなら、　　- 超小規模アプリ（Web/Native）ならFirebase 　　- 小規模以上のアプリ（Web）ならRemix 　　- 小規模以上のアプリ（Native）ならhasura + FaaS - 仕事でかっちりやるなら、　　- チームの習熟度に応じたフレームワーク・ライブラリでGraphQL APIサーバ　　- 規模が小さければOpenAPIでRESTも選択肢

2023-12-15

小さな教祖

インターネットを振り返ると新しい宗教の教祖を作る試みのように見える。

集合知、インフルエンサー、ライバー。

信じる者たちだけで集まるのがコミュニティ

2023-08-15

PHPで作られたサービスが一昔前のCOBOLのように保守運用できる人が減ってきて単価上がりつつあるのかも

エンジニア系

LaravelですらないCakePHPやFuelPHPや果てはVanila PHPで作られたようなサービス。なんかうまくいってそのまま増築運用されたけどさすがに経年劣化とメンバーの入れ替えが進み対応できる人を新しく探さなくてはならなくなったプロジェクト。EC2でnginxとphp-fpmホスティングして管理用のphpMyAdminがt2-microで動いてるようなシステム。

あの頃のPHP人材は単価上げるためにreactとかvuejsとかまたはネイティブアプリ開発にスライドしていったりして、そして今求められているのはピュアなPHPerではなく、phpやfwのバージョンアップだったりコンテナ化やCloud Functions移行なんかをしてくれるマッチョペチパアだったりして。逆にreactを始めとするフロントエンド界隈は単価が落ちつつあるのかもしれない。

今はまだそうでないとしても10年後はどうだろう。2033年に例えば上述のようなギリギリphp7みたいな構成が残って売上てたとしたらその人材は超貴重そう

2023-05-18

なぜFlutterか

エンジニア系

otihateten.hatenablog.com

記事の感想。というかそこから思考したとりとめのない内容。正直SwiftUI触ったことないしAndroidの記憶もおぼろげになってきたしなんならFlutterも半年近く業務で関わってない上で書く。

現在のサービス開発はミニマムスタートならPWAで十分で、それじゃ叶えられない機能を持たせるためにネイティブアプリを検討する。その場合そういった難易度の高い機能を開発するなら最終的にswift/kotlinで書いたコードをブリッジして呼び出すことになりやすい。つまり技術的な理由からネイティブアプリによる開発を決めた場合は最初からswift/kotlinで開発するほう効率良いかもしれない。

ただしそれはios/android開発でそれぞれ2名以上（同じ人がios/android両方見るのでも可）の開発者を用意できるプロジェクトの場合で、それよりも小規模な場合はFlutterによって開発を共通化した方がリスクヘッジしやすい。小規模でios/androidを別々に開発しようとするとそれぞれ1名ずつアサインする場合が多くその開発者がやめて開発停滞したりPRレビューしづらかったり弊害が大きい。swift/kotlinの箇所を極力減らすことでチームに分断が起きにくくなる。

これらは新規プロダクト開発についてで、元記事にある通り既存のアプリをリプレースする程のメリットはFlutterには現状ない。また意思決定者がなんとなくネイティブアプリが良いという理由でアプリ開発する場合もある。この場合はまずガワネイティブを、続いてFlutterによる開発を検討する。

人材面も元記事に同意でios/android未経験のFlutter開発者は正直厳しい。ネックになるのは2点でOS固有の事情を知らないことと、宣言的UI・状態管理の知見。もしFlutter実務未経験者を入れる場合は前者はもうどうにもならないので後者の経験を重視する。Flutterを独学で触ってるかどうかよりもReactやVue.jsなど最近のJSフレームワーク・ライブラリでの宣言的UI・状態管理経験の方が重要。

ここまではFlutterに限らずreact-nativeにも共通する話。Flutterに限った話だと開発体験はかなり優れてる。自分はvscodeメインだったがsetupや普段の開発でつまずくことがほとんどなくこれまでのネイティブ共通フレームワークの中では一番開発体験が良かった。Xcode/Android Studioによるネイティブ開発に近い不便のなさで開発できた。dartが微妙と言われればそうだしFlutter独特の書き味もなんとも言えないんだがまあphpの$みたいなもんで慣れかなと思う。

Flutterだとアプリのクオリティが落ちるというのは良くわからない。あまり気にしたことなかったけど自分が突き詰められてないから知らないだけかもしれない。コンポーネントのアニメーション等細かい点のこなれてなさみたいなのは感じたことあるが、一般ユーザが気にするレベルの差は感じられなかった。 Flutterのデメリットって上記の機能面や人材に関する部分のみで開発や性能にそこまでデメリット無いと思っている。iosでもandroidでも。一番の問題はやっぱり人材。

今後も新規案件でのFlutter採用は増加していくし部分的にFlutterを導入するユースケースも増えていくと思う。swift/kotlinは次のパラダイムシフトが起こってスマートフォンがレガシーになったときに生き残れるかはわからない。もちろんそれはFlutterについてもそうなんだけど、Flutter for Webだったりfusciaだったり可能性の種が多そう。kotlin/swiftもサーバサイドあるけど現実的にはなかなか業務で使う機会がなさそうなイメージ。

Flutterをおすすめするとしたらios/android開発経験者かredux,recoil,vuexとかその辺の状態管理の実務経験者。それ以外の人にはFlutterはおすすめしないかな。それより鉄板のreact系 & TypeScriptをすすめる。

でもキャリアを考えた場合Flutter覚えるのはアプリエンジニアへの最短ルートにはなり得そう。ios/androidエンジニア未経験で実務できるチャンスほぼないけど、プログラマー実務＋Flutterの独学ポートフォリオあれば潜り込めるのでは？と思ったり。まあキャリアアップとか狭苦しく考えずにやりたいことやるのが一番。