トーク

クリーンアーキテクチャの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を使う際の注意点をお話させていただきます。

概要:
アプリケーションの構築にComponent-Drivenなアプローチがあります。このアプローチでは、コンポーネントを中心とした設計がデザインと開発の両面で重要です。しかし、デザインとフロントエンド開発の間にはしばしばコミュニケーションの断絶が見られ、結果としてコンポーネント設計において不一致が発生します。
このセッションを通じて、デザイナーとフロントエンド開発者がより効率的に協力し、一貫性のあるユーザー体験を創出できるようになることを目指します。

内容:
・ Figmaの進化： DevMode、Code Connect、フロントエンド開発者も知っておきたい内容を抜粋
・ Storybookの利用: テスト、ドキュメント、FIgmaとの連携など、Storybookの利用方法を実際の取り組みを交えつつ紹介
・ HTML,CSSの変化： コンポーネントにフォーカスした技術の変化を紹介

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

本テーマでは、ダークテーマの実装時に、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)を何回か行っています。
そんな中、何が辛かったのか？失敗したことは何かなどをお話しします。
このトークでは、次の点をメインお話しします。

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

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

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アプリケーション開発の波乱万丈をお見せします。

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

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

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

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

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

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

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