トーク

HonoXはHonoベースで作られたフレームワークです。そしてHonoには、react-rendererというサードパーティーのmiddlewareがあります。
このHonoXとreact-rendererを組み合わせることで、HonoXでReactを使用することが可能になり、Reactベースのuiライブラリを使用しつつ開発を行うことが可能になります。

本セッションの詳細は以下の通りです。

• Hono/HonoXの説明
• HonoXとreact-rendererの組み合わせによる利点
• HonoXとさまざまなuiライブラリを組み合わせる

プロダクトにおいて、モバイルアプリとWebアプリのどちらも開発が必要な場合、どのような技術選定を行うかは非常に悩ましいところかと思います。

最近では、Expo Routerが、Next.jsのようなファイルシステムベースのルーティングを実現できるようになるなど、React Native・Expoを利用したモバイルアプリとWebアプリの同時開発が、有力な選択肢として頭角を表しているのではないでしょうか？

このトークでは、React Native・Expoで開発されたモバイルアプリのWeb版を、ReactやNext.jsを用いてイチから作るのではなく、"React Native for Web"や”Expo Router”によるモバイルアプリのコード資産を活用しながら開発することで感じた良かったポイントや苦しかったポイント等を共有できればと思います。

Webフロントエンドの自動テストをチームで無理なく継続するためには「軽やかなテスト」を書くことのできる開発環境と設計が極めて重要です。

本トークでは、開発から8年が経過したプロダクト開発チームでWebフロントエンドの自動テスト文化を醸成した経験をもとに、軽やかなテストを構築するための実践例とそれによって得られる開発体験について紹介します。

詳細は以下の内容を予定しています：

• 結合テストを支えるコンポーネント設計：Container/PresentationパターンとResult型を駆使することでテストのしやすいコンポーネントを構築する
• 単体テストとの付き合い方：ネットワークの入出力に着目した単体テストでカバレッジを広げる
• 開発体験：Storybook駆動で小さく精度の高いPull Requestを実現する
• +α：E2Eテスト・画像回帰テストとの付き合い方

ヘッドレスCMS「Storyblok」を使用したプロジェクトにおいて、エンジニア、デザイナー、ライターという三つ巴の天敵となり得るメンバーたちがどのようにコミュニケーションの問題を解決してきたかを解説したいと思います。
Storyblokの特徴であるビジュアルエディターは、デザインの変更がリアルタイムで確認しながら編集が可能で、非技術者でも直感的に操作できます。また、ブロックライブラリにより、再利用可能なコンポーネントを簡単に管理し、プロジェクト全体で一貫性を保ちながら効率を向上させることができます。
これを導入することでフロントエンドとバックエンドを完全に分離し、メンバーが同時進行できる部分が多くなります。導入初期のトラブルを共有します。また機能をどのように活用すれば、チームのリソースを最大限に活用できるか、初心者がつまずき易いポイントも紹介します。

React Nativeは、JavaScript（TypeScript）でiOS・Android対応のクロスプラットフォームアプリを素早く開発できることで知られています。

その一方で、メンテナンス性が悪くなりやすいデメリットがあります。
特に、React Nativeのアップグレードには、iOS・Androidの設定ファイルやコードの変更、さらにはサードパーティのJSライブラリやネイティブモジュールの更新が必要なケースもあり、とても大変です。

しかし、Expoが提唱している、「Continuous Native Generation(CNG)」というコンセプトを取り入れることで、スケーラブルでメンテナンス性に優れたクロスプラットフォームアプリ開発が可能になります。
このトークではCNGの概要、CNGを取り入れたExpoアプリ開発のプロセス、導入事例ついてお話しできればと思います。

Web アプリケーションを開発する中で, 同一アプリケーション内の他ページや別アプリケーションへのリンクを纏めた Global Navigation をヘッダーやフッター部分などに横断的に配置したくなるケースがあるでしょう. 事業の成長に伴って Global Navigation の内容も進化していくものですが, 一方でアプリケーションのリポジトリやサービスが分散されているとその更新やデプロイコストが高くなってしまいます.

日経電子版においてその更新コストに Platform Engineering でどのようにして立ち向かってきたか, そしてチームを跨いで利用される Platform Service の管理やコミュニケーションをどのようにして行なってきたか, を紹介し Web Frontend における Platform Engineering を行なっていくための知見をご紹介します.

ChatGPTの発表以来、生成AIを活用したサービスが数多く登場しています。これらのサービスにおいて、生成AIとユーザーをつなぐ重要な役割を担っているのはフロントエンドを担当する私たちです。
私の取り組んだ「わたしの現代新書」も生成AIを取り入れたプロジェクトです。このサービスでは、ユーザーが入力した書籍のタイトルをもとにAIがキャッチコピーを生成し、vercel/ogを使って書影画像をつくります。
この企画を作るにあたって、生成AIを利用する際にユーザーが待ち時間を感じないようにするデザインの工夫と、素早く高品質な画像を生成するエンジニアリングの工夫を行っています。その結果、多くのXユーザーに利用されるものになりました。
本セッションでは、デザインとエンジニアリングをどのように組み合わせたか、具体的な取り組み内容について詳しくお話しします。

この発表では、サイボウズが提供する製品「サイボウズ Office」における、フロントエンド (Next.js App Router) の監視基盤について紹介します。

React Server Components や Server Actions のようなサーバーの存在が前提となっている機能の登場によって、フロントエンドにおいてもサーバーを運用する必要性が高まってきました。このセッションをきっかけとして、フロントエンドの監視に関する知見が広がることを目指します。

詳細は以下の内容を予定しています:

• フロントエンドサーバーにおけるオブザーバビリティデータの収集方法
• Next.js での OpenTelemetry 対応の詳細とユーザー側ですべきこと
• Grafana Faro を利用した Real User Monitoring の実践

大規模なBtoBサービスにおける段階的なシステムリプレイスを実施しています。JSPで構築されているシステムのフロントエンド部分をNext.js（Pages Router）とGraphQL（Relay）にリプレイスしています。
フロントエンドチームのリーダーとして関わり、開発を開始してから約2年が経過し、初期リリースからは約1年が経過しました。
これまでの経験から、リプレイスを進める中で良かったこと、大変だったこと、技術選定の振り返り、今後気をつけたいことなど、これからフロントエンドリプレイスを検討している方々に様々な知見を共有したいと考えています。

本セッションでは、スキーマ駆動開発に焦点を当て、その中でもConnectを利用した開発について話します。

このセッションでは、まず、スキーマ駆動開発でのIDLであるOpenAPI、Protocol Buffers、GraphQLの中で、Protocol Buffersが記述のシンプルさと柔軟性において優れている点をお伝えします。
次に、Connect-Webを活用したスキーマ駆動開発の方法について解説します。Connectは2022年に公開された、 gRPCやgRPC と互換を持ったHTTP APIを作成するためのライブラリです。 Protocol Buffersを活用したAPIの定義から、クライアント側のコード生成をシームレスにサポートします。Connect-Webの特徴や利点について詳しく説明し、実際にどのように活用するかを示します。

クリーンアーキテクチャのWebフロントエンドへの適用は、クラスとの相性やフレームワークが前提とする処理の流れと違うといった課題があり、そのままの適用が難しいことはこの数年で徐々に認識されてきたことと思います。しかし、クリーンアーキテクチャを1つのアーキテクチャとして捉えるのではなく、いくつかの設計のパターンとして捉えることでフロントエンドにも活用できる学びがあると考えています。

本セッションでは、Vue.jsでクリーンアーキテクチャの導入を試し、その後のReactへの移行に際して、良い設計を部分的に適用する中で得られた知見について紹介します。

• なぜフロントエンドにクリーンアーキテクチャは不向きか？
• types, reducers, utils を使ったエンティティの表現
• 外部インターフェイスを抽象化していたことで、Vue.js→React移行がスムーズに

ウェブフロントエンドでサイズの大きいPDFを表示しようとしてパフォーマンスやユーザビリティに悩んだことはないでしょうか？
本セッションではサイズの大きいPDFを可能な限り高速にブラウザ上で表示するための工夫と、フロントエンドでcanvasにPDFをレンダリングする方法と比べたときの実際のパフォーマンス差についてお話させていただきます。
ちなみに今回ご紹介するPDFの高速表示方法は特許を取得済みです！
https://prtimes.jp/main/html/rd/p/000000038.000063428.html

プロダクトと組織の成長に伴って複雑化していくコードベースやお客様からのご要望に「Feature Flag」という武器で立ち向かいます。
UIだけでなくバックエンドAPIとのつなぎ込みやTesting（VRTやE2E）とのインテグレーションなど、Feature Flagの活用方法は多岐にわたります。
この一年間Feature Flagと向き合い続け、酸いも甘いも（？）理解した僕が、Feature Flagを使った開発が変化に柔軟で価値検証速度を高めることができる理由とFeature Flagを使う際の注意点をお話させていただきます。

Next.jsのApp Routerでは、React Server Components（以下RSC)を活用した実装になっています。
RSCのServer Componentsは、名前の通りサーバー側でレンダリングされるコンポーネントです。
ここで既存のSSRも似たことをする技術ですが、RSCとの関係性・違いはどのようなものでしょうか？
本トークでは、SSR・RSCの生成物を確認しながら機能・仕組みの違いを調査します。

仕組みの違い：https://qiita.com/karintou8710/items/28dee39c5cb82bd1775d

Next.jsアプリケーションをひとつのモノリスアプリケーションとして立ち上げたところから、拡大に伴いコンパウンド戦略を実現するマルチアプリケーションとして分割するところまでの4年間の変遷と移行ステップを紹介します。

フェーズによって最適な構成が異なることがわかってきたので、創業期〜拡大期におけるチーム構成や人数感の変遷を共になぞりながらお話しします。

以前Zennに投稿した以下の記事のその後の話でもあります。

• SPA Componentの推しディレクトリ構成について語る: https://zenn.dev/knowledgework/articles/99f8047555f700
• フロントエンドアーキテクチャの話: Resource Setの紹介: https://zenn.dev/knowledgework/articles/91a3dd575f99a2

近年のfrontend開発においてtypescriptは中心的な技術であり、それを利用した「コード生成」での工数削減や品質向上が一般的になってきています。
本セッションでは、graphql-codegen, pathpida, hygen等のライブラリを使いかながら、codeFirstとschemaFirst両方の「コードからコードを生成する技術」について整理していく内容になります。

また、graphql apiとの型互換性を保って開発するためのschemaFirstな生成や、githubactionsワークフロー内で必要な生成を行う方法などのチーム開発で自動生成を活用する為のテクニックについても解説します。

本セッションでは、防災教育を目的とした「ハザードマップゲーム」というゲームについて、どのようなゲームなのか、また、どのような意図で作ったのかという点について説明します。
ゲームを開発する際に於いて、様々な選択肢がある中、なぜTauri + Web開発の技術を採用したのかという技術選択の決定、およびその詳細について紹介をします。
開発中に直面した課題とその対処法、更により優れた選択肢が無いのかというところにも言及します。
公開が控えているTauriのver.2.0の展望についても述べたいと思います。

分散モノリスによって生まれた技術負債を解決すべくモジュラモノリス＋マイクロサービスの新しい基盤に移行しフロントエンドをNext.js(App router)+PandaCSSにリプレースしているお話

フロントエンドWeb開発には JavaScript を使うのが一般的ではあります。しかし、それ以外のプログラミング言語によるフロントエンドWeb開発も、実は既に実用レベルで使用が普及しています。今回は、スピーカーが特に詳しい C# によるフロントエンドWeb開発の現状を中心に、JavaScript 以外のプログラミング言語によるフロントエンドWeb開発について、現状やメリット・デメリットを解説。参加者に新しい視点を提供します。

昨今のフロントエンドにおける技術選定はReact + ViteやRemix, Next.jsのPages/App Routerなどが普及しており、選択肢の自由度が高くなっております。
その一方、それぞれのプロダクト特性や社内の知見に応じて技術選定することは大切であり、その難易度も難しくなっています。
本発表では、チーム開発の立ち上げに携わった際にフロントエンドの技術選定としてNext.jsのPage Routerを選択した背景と1年間開発・運用していく上でやってきたことをお話ししたいと思います。
・チームの立ち上げと技術選定
・テスト戦略と導入
・OpenAPIの型定義の自動生成とテストへの活用
・開発運用を進めていく中で困ったこと
・これからやっていきたいこと