RailsからフルスタックTSに乗り換えるにあたって考慮したいこと
#Rails #Next.js #フルスタック(言語統一開発) #Web_API #設計 #アーキテクチャ #技術の審美眼 #opinionated
from Vercel Ship started May 1st — Live Keynote May 4th
@yukihiro_matz: 使ってる言語や技術が違うから、フロントエンド部隊とバックエンド部隊に分けることが多いけど、いざ機能を開発する時には、両方にまたがった開発になるので、コンウェイの法則に反している。ひとつのチームにフロントエンド要員、バックエンド要員を配置すべき(場合が多い)。
@__syumai: いよいよBackendのAPIと言うものは消え去り、全てがNext.jsに集約されて、本当の次世代のRuby on Rails的フルスタックWebアプリケーションフレームワークの誕生に繋がっていくのか…
koushisa.iconも同じことを考えだしたので思考実験しておく
---
フルスタック(言語統一開発)をしたいモチベーションを言語化する
うまみ
フルスタックによって越境しやすく、意思決定も早く軌道修正も容易になり、人材流動性も高くなる
痛み
Railsをやめてもやめなくても、フルスタックフレームワークでは大規模アプリケーションは実装しづらい
フルスタックエンジニアは幻想
Stream alignedやアジャイルの適用条件に「全員がプロフェッショナルで越境できる」や「能動的に学べる」そして最後に「人事権」の壁がある
---
スタートアップの実情を理解する
スタートアップの存在意義は未来の不確実性そのもの
正しく開発したスタートアッププロダクトの初期設計は、正しく成長した未来からは壊れた設計にみえてしまう
---
ドメインの全体像を捉える
モデリングとパッケージングについて
ドメインの全体像を捉えてから初めて適した構成を練るべき
プログラム以外にもあらゆる観点でメンタルモデルと一致した状態を目指す
設計やデザインはトレードオフの関係にあり、意図への適合度合いで評価せねばならない
早すぎる最適化を防ぐ
ここらでRailsから乗り換えたい理由をChatGPTにでも問いかける
チームメンバーがいる場合は発信してフィードバックしてもらう
---
改めてRailsや既存フレームワーク全方向から見直す
Ruby / Rails はオワコンなのか?
「Railsを主戦場としている自分が今後学ぶべき技術について」のメモ
Railsをやめても解決しない問題
Hotwireの良かった点、辛かった点、向いているケース、向いていないケース
Railsの難しいところ
マイクロサービスを (Ruby on Rails 以外の任意の言語) で書くことについての意見
RubyとRailsの何が強いのか
バックエンドはフレームワーク>言語
流行った技術の代替が登場するきっかけと今後のトレンドの考察
再度Railsから乗り換えたい理由をChatGPTにでも問いかける
---
MVC、ActiveRecord、ORMの概念をアンラーニングする
フロントエンドでMV*フレームワークを使わない理由
データ構造と振る舞いを切り離す = CQS, CQRSの概念と比較する
メリットとデメリットの軸だけでは判断できない
TypeScript による GraphQL バックエンド開発
PofEAAではActive Recordは過渡期の捨て駒で本命はData Mapperだった
PrismaはORMなのか?
Prisma を綺麗に使いたければ MVC という発想を忘れるのが良いのでは
GraphQLを前提にした場合、ORMはメリットが少ない
modelという抽象ではなく参照か更新かで分けたい
React Server Componentsをアーキテクチャとしてどう捉えるか
再度Railsから乗り換えたい理由をChatGPTにでも問いかける
---
Railsが提供していたエコシステムの代替手段を検討する
NodeでRailsっぽいConsoleやREPL
---
興味本位の技術ドリブンで乗り換えないようにする
技術ドリブンへの警告→Crime and Punishment: Hype Driven Development, カーゴカルトプログラミング
Railsは未だに8割の要件で最速最強
オーナーシップを持てない方はアーキテクチャを決めるべきでない
再度Railsから乗り換えたい理由をChatGPTにでも問いかける
---
エンジニアと組織の知の蓄積
これから起こる変化に適応していく体力がチームにはあるか?
「予備知識無しで語れること」なんて大概限られている
早く行きたければ一人で行け遠くへ行きたければみんなで行けが実現できない
---
経営観点で最後のジャッジを下す
ハードシングスを引き起こしたHype Driven Development(HDD)
個人開発のコストはDB次第
VercelとCloudflareではコスト面でCloudflareに軍配があがる
アーキテクチャは課金体系が決める
アーキテクチャ変更を決断するときCTOは何を考えているか? 技術的意思決定を経営陣に説明する実践的Tips
---
koushisa.icon
勘所は技術的負債でもまとめたが、どんなに優れていても経年劣化は避けられない
スタートアップの存在意義は未来の不確実性そのもの
ソフトウェア式年遷宮
コンウェイの法則の問題
技術による境界線ができると(人の問題で)スケールが難しくなる
属人性は低い方がよいが、属"技能"性はそうではない
技術トレンドの新陳代謝と人材流動性の2軸で考える
「フロントエンドファーストで技術の螺旋を登りながら段階的に成長可能」をキーとする
モジュラモノリス
マイクロフロントエンド
→段階的にマイクロフロントエンドへ移行していくための技術調査メモ