Firebaseの存在をフロントエンドから隠蔽するために

「Firebase は安いし楽だしマジ最高」という一心で技術選定してしまったプロダクトが成功して見えてきた課題、割高なコスト・権限管理・カスタマイズ性、そして （特性やスキルセット的に）RDB 製品が適していたのに無理やり Firestore を採用したことによるデータ不整合。 その結果チーム内で Firebase を抜ける機運が高まるも、Firebase べっとりなアプリケーションすぎて移行しづらいといった問題に出会うかもしれません。 そのような場合に備え、Firebase の存在を隠蔽して開発することに挑戦してみましょう。 注意: Firebase を剥がしているときに「俺、次は絶対そうするわ」と感じたものを書いているだけであり、まだ実際にはこのパターンでプロダクション導入していません。 あくまで個人開発で試してみていけそうと思ったので、提案しますという体です。 また Firebase

[mizchi]

隠蔽するぐらいならFirestore使わないほうがいい気がするし、現実的にこういう問題が発生るするのはわかりつつも、やっぱりリアルタイム性が必要な箇所だけ使うに留めたほうがいい気がする

[takahashim]

"RDB 製品が適していたのに無理やり Firestore を採用したことによるデータ不整合" つらそう。でも隠蔽に頑張りすぎると「安いし楽だしマジ最高」のメリットが半減しそう

[IzumiSy]

コレを言うならReactとかVue.jsも未来のフレームワーク移行のためにプレゼンター層として切り離したほうが良さそうに思えてきた。

[ssig33]

早すぎる最適化、本末転倒

[j5ik2o]

分離するのはドメインオブジェクト群でよいけど永続化の抽象は問題になる。それがまさにリポジトリの責務なので、だいたいはこの記事のとおりになる。サーバサイドでも同じことをやってますね

[yug1224]

いや右車線は追い越しする時だけだろ

[partylife]

本末転倒感がすごい

[YaSuYuKi]

移行するときにFirebaseを騙る抽象層を作る方法で駄目な理由が見つけられない。リアルタイムは特殊で実現は容易ではなさそうだが、それ以外は

[taguch1]

フロントの人は永続化層のIFを抽象化してない時はどうやってテスト書いてんだろう？

[ka-ka_xyz]

ただ、firebase抜けするとしたらデータ構造含めて一から練り直しなんやろな感があって、コード上でfirebase実装を隠蔽するところに労力をかけるべきかどうか微妙なとこだと思う。（あと、まだ今の所そんな余裕が無い）

[yimajo]

“依存とはモジュールが他のモジュールの存在を知っていること」という考えで、「UI 層に Firebase という文字を出さない」といった設計を目指していきます。 ”

[nikutaiha]

firebase

[shozzy]

ブコメ含めて参考になる。最初から隠蔽するのはYAGNIだけど、どこかで一旦隠蔽する形にリファクタリングして、そこから別サービスへの移行を実施するのがよい感じかな。

[tattyu]

右車線は速度重視じゃなくて追い越し専用だろ。「僕は自信の直感に従って法律を犯します」宣言されたら、記事読む気が失せる。

[t10471]

ミドルウェアを隠蔽するコストよりもテストしやすくロジックを切り出す努力にコストを割いた方が健全な気がするな...

[Soraneko]

"RDB 製品が適していたのに無理やり Firestore を採用したことによるデータ不整合"　あるあるそう

[koogawa]

“つまり、pages/, components/, containers/ などで import firebase from 'firebase'を書かない”

[takezaki]

“見えてきた課題、割高なコスト・権限管理・カスタマイズ性、そしてRDB 製品が適していたのに無理やり Firestore を採用したことによるデータ不整合。 その結果チーム内で Firebase を抜ける機運が高まる”

[laiso]

脱Firestoreしやすいようにするデータ層のデザイン例

[odan3240]

“型推論でも firebase.User を使わない ” わかる