LayerX バクラク事業部 Enabling チームでスタッフエンジニアをしている izumin5210 です。 Ubie さんの「社内デザインシステムをMCPサーバー化したらUI実装が爆速になった」を拝見し、悔しかった感動したので、自分でも試してみました。 MCP ツール設計 以下に引用する Ubie さんのスライドで解説されているとおりですが、現行モデルでは全コンポーネントのコードやルールを一気に渡してもノイズが多くなりすぎるためか、満足のいく性能は出ませんでした。 これは MCP サーバ化したとしても同様で、Tool 1回の呼び出しで全コンポーネントの詳細情報をすべて返すとやはり情報がぼやけてしまいます。 AI Coding Agent Enablement - エージェントを自走させよう (p.23) これらを踏まえると、以下のような2つのツールに分けて提供するのがよさそうだと判

Catalogs を使うモチベーション Catalogs のメリットについては、ドキュメントではざっくり以下の3点が挙げられています。 単一バージョンを維持できることで、パッケージの重複によるバグの発生を防ぐ pnpm-workspace.yml を編集するだけで依存関係のアップグレードが完了する 依存関係アップグレード時に package.json を編集しなくてよくなり、git でのコンフリクトを避けられる 筆者の環境では特に1つ目の、「パッケージの重複によるバグを防ぐ」というのが大きなモチベーションとなりました。 モノレポと共通パッケージとパッケージ重複 筆者の環境では一部の Web Frontend もモノレポで運用しており、そのなかで一部の共通実装はモノレポ内パッケージとして切り出されています。以下は架空の例ですが、おおまかにこのような構造となっています。 たとえば各 webap

この記事は LayerX のエンジニアブログがたくさん出る #ベッテク月間 の8記事目になります。こちらのカレンダーに、これまでの記事と今後出る予定がまとまっています。 LayerX のバクラク事業部には GraphQL Gateway というバクラク全プロダクトから参照される GraphQL スキーマが存在します[1]。今回の記事は、その GraphQL Gateway のスキーマをより良い状態にしていくためにぶつかった課題を強引に突破したときの話です。 モチベーション GraphQL スキーマの破壊的変更によって GraphQL Document がスキーマに適合しなくなる場合、そのリクエストはエラーになります。例えば以下のようなケースが考えられます： 使わなくなったフィールドを削除したい 削除されたフィールド（存在しないフィールド）を含む Document を処理することはできない

7月はLayerX エンジニアブログを活発にする期間です。今日は誰がなんと言おうと 7/6 です。 昨日 7/5 は「Datadog のコスト最適化で月額費用を 30% 削減した」でした。 2022年10月3日に、GraphQL Code Generator（以下、graphql-codegen）のおすすめ設定に関する記事を公開しました。 しかし、その後、graphql-codegen v3のリリースに伴い、ReactやVueではclient-presetが推奨されるようになりました。 client-preset前提の環境では、利用可能な設定項目などがいくつか変わるため、本記事では改めて、graphql-codegen以降のClient preset時代のおすすめ設定をまとめています。 全体 設定を TypeScript で書く graphql-codegen v3から公式ドキュメントで案