プロポーザル

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

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

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

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

生成AI・LLMの登場において、多くの領域で変化を訪れようとしています。
開発者であればGithub Copilotを代表にコード自動生成・開発支援の進化を如実に実感していることでしょう。

そんな状況の中、私が個人的に注目しているのが「生成AI・LLMをUI/UXの改善に利用することはできないか？」ということです。
実際に生成UI(Generative UI)というAIシステムがユーザーのニーズやコンテキストに合わせて、動的にインターフェイスが生成される概念も提唱され始めています。

本セッションでは、生成AI・LLMによって生まれるかもしれない新たなUIの可能性やそれを実現するためのライブラリとしてVercel AI SDKをご紹介します。

近年の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開発について、現状やメリット・デメリットを解説。参加者に新しい視点を提供します。

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

本テーマでは、ダークテーマの実装時に、UI上で魅力的なカラートークンとアクセシビリティの基準を満たすカラートークンの設計方法について深く掘り下げます。
具体的には、Qiitaの実例をもとに、適切なカラーパレットの選定基準や方法、コントラスト比の最適化、効果的なカラートークンの設計方法に焦点を当て話します。
特に、Qiitaのカラートークンは「ブランドカラーとUIカラーを分ける戦略」と「拡張性を持たせた設計」を特徴としています。これは、「エンジニアを最高に幸せにする」というQiitaのビジョンと「デザインシステムは進化し続けるものである」という思想に基づいて設計しました。
このアプローチを他社でも応用・利用できるように話す予定です。

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

アプリケーションを開発し、長期にわたって運用するには、収益化が欠かせません。
ソフトウェアをサービスとして提供するSaaSモデルでは、月額や年額での定期的な請求（サブスクリプション）システムの組み込みが重要な要件となります。
しかしシステムの運用と同様に、サブスクリプションでは様々な運用課題がリリース後に発生します。
このセッションでは、サブスクリプションをアプリケーションに導入する際にのポイントについて紹介します。

紹介するポイントの例
・リリース後に発生する「運用課題」の例
・プランの種類と途中での契約変更
・使ってもらうための無料オファーの種類と使い分け
・プランとアクセス権の設計と割り当て

長くウェブサービスを運用していると、どうしても jQuery と付き合わなければいけない瞬間があります。
10年間の運用で40万行規模にふくらんだコードベースを管理しながら、より安全で、メンテしやすく、そして将来的に宣言的 UI に移行できるようにするために、
どのように開発計画を立て、リファクタリングを進めていったのかをお話しします。

• チームとコードベースが抱えていた課題
• 不要コードの削除
• セキュリティ問題の解消
• ESLint・スペルチェッカの導入
• 型チェックの導入
• バンドラーの導入

現在TechTrainというサービスを開発していますが、4人いる社員のうち全員が今までバックエンドをメインとして開発してきたエンジニアとなっています。そんなエンジニアたちがNext.jsとLaravelで開発しようとするとどうなるか？そうです。Next.jsの細かなことは調べながら開発することになります。そんな中でも生産性を出すためにこんなこと意識してるよという話をさせていただきます。

このトークで話すこと

• バックエンド中心の組織でフロントエンドのアーキテクチャ
• フロントエンドの実装とデザインの連携
• ちょっと失敗したなーと思っていること

2019年からエンジニアの教育サービスのTechTrainというサービスを作ってきました。
足掛け5年サービスを継続している中で、サービスのデザインリプレイスと技術的なリプレイス(Nuxt.js->Next.js)を何回か行っています。
そんな中、何が辛かったのか？失敗したことは何かなどをお話しします。
このトークでは、次の点をメインお話しします。

• リプレイスではどの単位で進めるのが良いのか？
• デザインリプレイスと技術のリプレイスを一緒に取り扱うのか？
• どうやってリプレイスを短期決戦にしていくのか？
• リプレイスとサービス特性をどう取り扱うのか？
• 技術的に辛くなりやすいところは何か？

フロント開発の自動テストでやったこと

ぼくはNext.jsを今年から触り始めたんですが、フロント側のテストって何を書いていいかわからない、UI部分のテストって書くのが難しそう、と思っていました。

そこでフロント開発（Bext.js)の自動テストについて調べて、実際に作成した時、こんなライブラリやツールを使ってこんなテストをしたよ、っていうようなことを話したいと思います。

具体的には以下のような内容を話す予定です。

•Storybookを使った自動テストの作成
•Jestを用いたテストの作成
•Chromaticを用いたUIの変更点のテスト作成
•Codecovを用いてコードカバレッジを取る

機械的に手を動かして書き換えるだけのリファクタリング作業は、なるべく避けたいものです。
ひとつふたつ書き換えるだけであれば問題ありませんが、それが幾多にも及ぶと手に負えません。

codemod はそういった作業を代行してくれる強力なツールです。
一方で、このツールの実装には抽象構文木(以下、AST) の知識が必要なことから、敷居が高いという印象を持たれてしまいがちです。

このセッションでは jscodeshift という Meta 製のライブラリを用いた codemod の開発方法をご紹介します。
開発を通して、jscodeshift がベースとしている Recast という ASTパーサーへの理解を深めつつ、JavaScript と TypeScript の ASTをマスターし、面倒なリファクタリングを苦もなくこなす便利な codemod を作れるようになりましょう！

Next.js App Routerの安定版がリリースされてから1年以上が経過しました。Next.js Pages Routerのままでよいのか、App Routerに移行するか、あるいは他のフレームワークへ移行するか、皆さんも悩まれていることでしょう。

本講では、開発開始から2年半、運用開始から2年の実稼働アプリケーションである、10万行超のNext.jsプロジェクトを事例としてご紹介します。強く結合したPages Routerを、1年の構想と約1ヶ月の作業期間でApp Routerに移行した手順や、移行によるメリット、デメリットをお話しします。

さらに、App Router化と同時に行った大規模なバックエンドのインフラ変更の実態も併せて、現場の臨場感あふれるWebアプリケーション開発の波乱万丈をお見せします。

Next.jsのAppRouterやRemixの台頭などますますフロントエンド開発においてReactに対する熱が高まってきています。
直近のフロントエンド開発において、もはやReactで作るということは必ず選択肢に上がるといっても過言ではないほどです。

そんな状況下で「いざReactで開発！」となったとき、より効率的に開発を進めるために設定しておきたいことがあります。

このLTでは、Reactを使った開発をするなら設定しておきたいことを時間の許す限りご紹介したいと思います。

Fast JSX: Don't clone props object #28768というPRがマージされました。これはReact19からjsxが高速になると言うPRです。

React19からpropsをクローンしていました。それには以下のような理由があります。

1. key, refの予約語をpropsから削除すること
2. createElementがpublic apiである

これらを二つの問題がReact19からは解消できるので、propsをクローンする必要がなくなり、jsxの変換処理を高速化できるようになります。

このトークでは、二つの問題をどのようにして解消できたのか、そして実際のコードを見てどのように高速化したのかについて簡単にお話しできればと思っています。

近年、フロントエンド開発の複雑性は増し続けており、サイトのホスティングだけでなく、データベースや認証機能など、バックエンド領域に関わる機能も必要不可欠となっています。
しかし、従来のAWS Amplifyでは、フロントエンドのコードとバックエンドに関する設定が分離されており、特にバックエンド開発に慣れていないフロントエンドエンジニアにとっては、習得にハードルがありました。

そこで今回ご紹介するのが、AWS Amplify Gen2です。Gen2では、待望のTypeScriptサポートが正式導入され、フロントエンドだけでなく、バックエンドの設定や開発も含め、全てをTypeScriptで統一して開発することが可能になりました。

本セッションでは、実際のコードやデモも交え、TypeScriptでパワーアップしたAWS Amplify Gen2の魅力を余すことなくお伝えします。

本発表では、フロントエンド開発におけるブラウザ互換を意識することの重要性に焦点を当てます。

過去の歴史的なブラウザ戦争から現代に至るまでを振り返りつつ、開発者やユーザーが直面するブラウザの課題と互換性の重要性を語ります。

• IEサポートという歴史を振り返りつつどのようにして現在の主要なブラウザたちが残ったのかを詳しく見ていきます
• Web標準に準拠した互換性がなぜ重要であるか、それが損なわれたWebはどのように影響を与えるかを掘り下げていきます
• ブラウザ互換性を維持するための各種取り組みを紹介し、エコシステム全体の健全性に貢献する方法を模索していきます

ブラウザ互換を意識したフロントエンド開発は、単なる開発者だけの問題を超えるWebの未来を守るための責務です。
このセッションで、ブラウザ互換の理解を深め、日々の開発において適切な意思決定ができるようになることを目指します。