Active Recordから考える次の10年を見据えた技術選定 / Architecture decision for the next 10 years at PIXTA

September 15, 2021 @ iCARE Dev Meetup #25

[t-wada]

"技術選定の一番の目的は流行を取り入れることではなく、ビジネス上の問題を解決することである" 事業の特性や制約、開発組織の状況などが技術選定やアーキテクチャ選定に強く影響する。考え抜かれた素晴らしい資料。

[sigwyg]

Rails7にWeb Vitals的な達成目標がないからActive Recordだけ利用すると。PrismaのようなTypeScriptのORMでは（現状では）Railsの生産性を再現できないので、Next.haやApolloまわりで新しい基盤を2-3年かけて作っていくと。長期的判断すごい

[Bryntsalov]

技術選定の理由付けはどうとでもなる。結局は好み。

[hshimoyama]

フロントとバックエンドの密結合によるユーザ体験指標の向上の価値は理解しつつ、将来的な再再設計の変更負荷を考えて、分解点を API とした疎結合を選びがちなので、そこの判断をもっと掘り下げて聞きたい

[miyasakura]

まだまだRailsは現役だなと思ったのは間違った感想ですかね？

[iga_k]

yasaichi さんの脱Rails TS ORマッパー選定の話

[iR3]

ふむふむ

[iekusup]

ほー。

[d4-1977]

似たような話を…中略…。 TypeScriptは伸びてきていて使いやすいけれど、ActiveRecordからの移行先は、なかなか難しいなあって思っていました。

[kikunantoka]

事例として参考になる

[motchang]

ES / CQRS も活用してユーザーが直接フェイシングするデータは計算済み、最小限のデータたけ露出するようなアーキテクチャを作れないと戦えない時代なのかなと思う。CQRS の裏で BASE もやらないといけないし。

[yuuAn]

Domein 層と Infrastructure 層は分けた方がいいですよ。

[tsuwatch]

PoEAAを読むとアクティブレコードにはバリデーションとコールバックがないということがわかるというのは盲点でした。読みます

[MH4GF]

面白かった。Railsの限界や課題の感覚もかなりわかるし、とはいえ次の選択肢となるとピタッと嵌るものがなく試行錯誤が続くというのもわかる。この意思決定を応援したいし個人としてもこの辺の技術を模索したい

[clash_m45]

サーバサイドとフロントエンドの言語の違いによる負荷が大きく出た、ってところにドキッとしたなぁー 自分ができても他のエンジニアには出来ないかもしれないよな…

[daaaaaai]

野心的。ポストRailsなTypeScript製のWAF、どんなのはやるだろうか

[clockwork9]

ここまで理詰めで選定しても、市場からの供給人材を通じて技術スタックの流行り廃りに支配される現実

[for-my-internet-demo]

新規チームで業務ロジック主体のwebアプリをそこそこ雑かつ分離設計したいときの現実感として今TSあるのはもはやなんとなくわかる(goやrustの使い所を間違った気はしている...

[pascal256]

後で読む

[keint]

保守(PMF後)の話があまり割かれていないのはこの業界だと当たり前なのか

[onesplat]

また見据えちゃったよ

[suginoy]

https://youtube.com/watch?v=NBpfy6TSCTU

[tofu-kun]

すごい面白かったし、感覚は分かる