TailorにおけるSchema-driven UIの実践例

Transcript

1. © tailor inc. TailorにおけるSchema-driven UIの実践例 Seiya Izumi (sy_izumi)
2. © tailor inc. 今日の発表内容はあくまで React勉強会時点で自分が考えている脳内のスナップショットです 注意事項 Disclaimer
3. © tailor inc. Seiya Izumi (@sy_izumi) Introduction Lead Frontend Engineer at Tailor
4. © tailor inc. Tailorとは? What is Tailor? 在庫管理や受発注管理、購買管理などのビジネスドメインをプラガブルなモジュールと して提供し、必要なモジュールを組み合わせることで高速に Tailor-madeな基幹システ ムERPを構築できるプラットフォーム製品 組み合わされたモジュールは GraphQL APIとして提供され、フロントエンド SPAに限 らずモバイル、デスクトップ、 AIなど様々な環境から利用できる
5. © tailor inc. Tailorの組織構成 Departments 今日の話に関係あるざっくりした組織構成図
6. © tailor inc. ※超簡略化したProfessional Servicesでの開発の流れ (バックエンドにはTailor Platformを最初期から利用) 顧客向け開発のプロセスの現状 Process 要件定義 プロトタイピング・イテレーション プロトタイプのFBに基づき フロントエンドをスクラッチ開発 (with Next.js) 時間軸 本番運用 ※ Retool … 業務システムに特化した高機能な No-codeアプリビルダー
7. © tailor inc. • 実装工数の二度手間 ◦ できればRetoolで作ったフロントエンドをそのまま使いたい (が、後述の問題で難しい) • Retoolの技術的な課題 ◦ 画面上のコンポーネントが多い画面は初回のレンダリングがめちゃくちゃ遅い ▪ UIビルダーで作られた画面をフロントエンドで全て組み立てているような挙動をする • M3 Macbook Proでも気になるレベルの遅さ (お客さんの端末では...) ▪ エンタープライズ向けのSaaSなのに...? ◦ UIビルダーの挙動がFlaky ▪ UIビルダーが固まるとか遅いとか、そういうレベル ◦ サポート体制: クリティカルなバグがあるのに、なかなか修正されない ▪ 例えばオンプレ版とクラウド版で挙動が微妙に違う、など ▪ エンプラサポートでもそこまで優先度上げてもらえない 課題 Problem
8. © tailor inc. 以下を満たすˮ何かˮが欲しい... • Retoolを使うのと同等レベルで高速なプロトタイピングができる ◦ 仮にそれが非フロントエンドエンジニアであったとしても。 • そのまま本番運用でき、パフォーマンス劣化を引き起こさずスケールさせられる ◦ 仮に何かトラブルが起きたとしても、エンジニアリングで解決できる 欲しいもの What we want
9. © tailor inc. プロトタイプをするデザイナの方と話して : 1. サイドバーやヘッダーのような大枠のナビゲーションやレイアウトについては顧客サイドから大きな要望 がくることは稀 2. コンテンツ部は只の全画面テーブルのこともあれば、業務のコアとなる画面では細かなレイアウトや UX レベルの要求があることも多い。 3. データテーブルUIのコンポーネントでは見え方の細かいカスタマイズ要望が多い傾向 更にわかってきたこと Another findings カスタマイズが必要な ところ以外をサボりたい...
10. © tailor inc. プロトタイプをするデザイナの方と話して : 1. サイドバーやヘッダーのような大枠のナビゲーションやレイアウトについては顧客サイドから大きな要望 がくることは稀 ◦ ⇒ナビゲーションやベースのレイアウトは OpinionatedなUIの基盤を提供 2. コンテンツ部は只の全画面テーブルのこともあれば、業務のコアとなる画面では細かなレイアウトや UX レベルの要求があることも多い。 ◦ ⇒パターンのある画面は GraphQLクエリから自動で作ってしまう ◦ ⇒開発工数を本当にカスタマイズが必要な画面だけに集中 3. データテーブルUIのコンポーネントでは見え方の細かいカスタマイズ要望が多い傾向 ◦ ⇒テーブルコンポーネントは頑張って内製 (地味に大変だが ...) 現時点でのアイデア Potential idea ここで Schema-driven したい!
11. © tailor inc. Schema-driven UI
12. © tailor inc. Schema-driven UI (fabrix) TailorではGraphQLをメインのAPIインターフェイスにしてい るので、ここから最低限の画面まで作れてしまえば、デリバ リまでのプロセスを効率化できるのでは ? という仮説があっ た Approach いろいろ使えそうなライブラリはあったもの の、微妙に痒いところに手が届かず、将来的 なことを考えてOSSでReact用のライブラリを 作ることに。 https://github.com/fabrix-framework/fabrix
13. DEMO (prototype)
14. © tailor inc. まとめ • UIをカテゴリ(ドメイン?で括れば、なんとなくパターンが見えてくる ◦ 我々の場合はˮ業務システムˮというカテゴリ • 真心込めて作るべきところと、そうでないところを見分けて高速にデリバリーしていきましょう ◦ サボれるところは限界までサボりたい ◦ 我々の場合は、それが GraphQLベースのSchema-driven UIであるという仮説 • 人間が楽できるインターフェイスであれば、 AIにも優しい ◦ GraphQL書くくらいならAIにスキーマ定義食わせて自然言語で指示するのは余裕 Summary
15. © tailor inc. 比較検討候補 • Refine ◦ 求めるものとしては若干レイヤーが低い • ReactAdmin ◦ GraphQLアダプタのデザインが微妙 (全てのフィールドをselectionする挙動...) ◦ MUIベッタリなのは嬉しくない • NextAdmin ◦ インターフェイスはいいが、 Next+Prisma前提なので微妙 Appendix: comparison
16. © tailor inc. Thank you! 👋