[Next.js Update! 2021/11/24] Web Frontend Unit の立ち上げとリアーキテクチャに際してNext.js を採用したワケ
Web Frontend Unit の立ち上げと
リアーキテクチャに際して
Next.js を採用したワケ
株式会社 NewsPicsk
Product division Web Frontend Unit
イイダユカコ
@becyn on
2021/11/24『【Next.js Update!】v12リリースを踏まえ、Next.jsの採用を考える』事例講演
2
はじめまして
Web Frontend Unit の立ち上げとリアーキテクチャに際してNext.js を採用したワケ
略歴
2013 年 4 月より
株式会社サイバーエージェントにサーバーサイドエンジニアとして入社。
2015 年 12 月より
AbemaTV への異動をきっかけにフロントエンドエンジニアとして従事。
2019 年 9 月より
株式会社ニューズピックスにエンジニアとして入社。
入社後 API 開発なども行っていたが、
2020年よりフロントエンドエンジニアをメインに従事。
現在
NewsPicks の Web Re-architecture を提案し、
2021年7月に Web Frontend Unit が発足。
現在は同 Unit のメンバーとして開発を行う。
主な興味分野は、
a11y、design systems。
安心感高い開発環境を
つくっていきたい!
4
Web Frontend Unit 立ち上げ前までの状態
Web Frontend Unit の立ち上げとリアーキテクチャに際してNext.js を採用したワケ
NewsPicks Product Division (経済メディアサービスの開発を担当する division)
Product Design Team
Product Development Team
Enterprise Development Team
Core Development Team
課金事業担当Unit
SRE Unit
レコメンド等アルゴリズム担当Unit
新機能開発担当Unit プロダクト計画Unit CS/OP Unit
プラットフォーム関連の開発担当Unit テスト関連開発担当Unit
入稿ツール担当Unit
課金事業コンテンツ担当Unit
アプリ担当 Unit
* 組織図は、2021年6月時点のものです。
12 Unit
姉妹サービス担当Unit
5
Web Frontend Unit 立ち上げ前までの状態
Web Frontend Unit の立ち上げとリアーキテクチャに際してNext.js を採用したワケ
Product Design Team
Product Development Team
Enterprise Development Team
Core Development Team
課金事業担当Unit
SRE Unit
レコメンド等アルゴリズム担当Unit
新機能開発担当Unit プロダクト計画Unit CS/OP Unit
プラットフォーム関連の開発担当Unit テスト関連開発担当Unit
入稿ツール担当Unit
課金事業コンテンツ担当Unit
アプリ担当 Unit
* 組織図は、2021年6月時点のものです。
12 Unit
姉妹サービス担当Unit
Web 面の開発を行う Unit
NewsPicks Product Division (経済メディアサービスの開発を担当する division)
6
Web Frontend Unit 立ち上げ前までの状態
Web Frontend Unit の立ち上げとリアーキテクチャに際してNext.js を採用したワケ
● Java の Spring Framework で Server side rendering
○ Thymeleaf (template engine ) + Coffee Script + 時々 jQuery
○ Grunt を使用して minify などのタスクが行われている
● Test は一部 e2e テストが行われている
● html ファイルがざっくり共通部分やページごとに管理されている
○ 使い回しができている部分とそうでない部分がある
○ fragments、layer などの分類でディレクトリがわかれている
○ desktop 向けと mobile 向けで別ファイルで管理されている
● package のメンテナンスは最低限 … ?
○ 率先してメンテナンスをする担当者がいない状態
■ 逆に「自分やります!」が通りやすい環境だった
現行基盤で採用されている技術や環境
7
Web Frontend Unit 立ち上げ前までの状態
Web Frontend Unit の立ち上げとリアーキテクチャに際してNext.js を採用したワケ
● つくられた当初の最善の設計をベースに大きく育った状態
○ メインは「アプリ」ということもあり、Web project が重要視されていなかった
● 数年前に比べて開発メンバーも増え、環境も変わり、
「多くの人が、前提知識なく commit しやすい環境」とは言えない状態
● 使用している技術が現代のフロントエンド技術や知識を導入しにくい状態
現行基盤の状態まとめ
体制面
技術面
● Web project を複数の Unit が触れる体制になっている
● 特に Web project のメンテナーが存在していない
8
● Web project のメンテナーを置き、他 Unit の方が触っても
「怖くない」と思える環境をつくりたい
○ テスト、開発環境をより良いものにすることで改善できそう
Web Frontend Unit 立ち上げ前までの状態
Web Frontend Unit の立ち上げとリアーキテクチャに際してNext.js を採用したワケ
● 現代のフロントエンド技術や知識を導入しやすい状態にしたい
○ 我々の tech vision は「経済を、技術でもっとおもしろく。」
■ まずは、造り手が「おもしろい!」と思える環境を用意したい!
○ 2021年の工夫を取り入れ、メンバーの挑戦を後押しできる環境にしたい
● 本来作りたかったものに集中できる環境にすべく、多方面のフロントエンドに関する
テストを導入したい(Accessibility Testing、Visual Testing …)
私が、特に改善したいと思ったこと
体制面
技術面
21
Web Frontend Unit の立ち上げとリアーキテクチャに際してNext.js を採用したワケ
現行システムのアーキテクチャ(略図)
NP DB
API & Web 用 rendering を担う
GraphQL 未対応ページについてはNP Server に引き続きリクエストする
最終的にAPI に特化した project になることを目指す(
Web を切り離す)
既存の NP Server
Java
project
Web Client
ALB
23
リアーキテクチャを行うにあたってのロードマップ
● スピーディで安定感ある開発を可能とすること(Next.js を使うことで叶いそう!)
● 「全ページ一気に置き換える」より、「ページ毎に置き換える」手法をとること
● Web 用 API が一部分しか存在しない&JSON 形式でない場合もあるため、
開発が必要だが最低限に抑えたい
○ 既存のアプリ用 API をうまく活用したい
Web Frontend Unit の立ち上げとリアーキテクチャに際してNext.js を採用したワケ
リアーキテクチャをどう行っていくか
現実解を求める上での条件
● path-based routing を設定し、path ごとに request 先を handling する
○ /articles/XX の path のみ新基盤に request を送信することが可能
● GraphQL を導入することで既存のアプリ用 API を活用しながら開発する
実際にとった戦略
24
Web Frontend Unit の立ち上げとリアーキテクチャに際してNext.js を採用したワケ
現行システムのアーキテクチャ(略図)
NP DB
API & Web 用 rendering を担う
GraphQL 未対応ページについてはNP Server に引き続きリクエストする
最終的にAPI に特化した project になることを目指す(
Web を切り離す)
既存の NP Server
Java
project
Web Client
ALB
25
Web Frontend Unit の立ち上げとリアーキテクチャに際してNext.js を採用したワケ
新基盤のアーキテクチャ(略図)
NP DB
API & Web 用 rendering を担う
GraphQL 未対応ページについてはNP Server に引き続きリクエストする
最終的にAPI に特化した project になることを目指す(
Web を切り離す)
既存の NP Server
Web server
Java
project
Next.js
project
初回来訪時
Next.js project 内の
ページ遷移時に発生する
API Request
ALB
対応状況により
path ごとに振り分け
(Path-based routing)
GraphQL
Web Client
26
Web Frontend Unit の立ち上げとリアーキテクチャに際してNext.js を採用したワケ
新基盤のアーキテクチャ(略図)
NP DB
API & Web 用 rendering を担う
GraphQL 未対応ページについてはNP Server に引き続きリクエストする
最終的にAPI に特化した project になることを目指す(
Web を切り離す)
既存の NP Server
Web server
Java
project
Next.js
project
初回来訪時
Next.js project 内の
ページ遷移時に発生する
API Request
ALB
対応状況により
path ごとに振り分け
(Path-based routing)
GraphQL
Web Client
27
Web Frontend Unit の立ち上げとリアーキテクチャに際してNext.js を採用したワケ
新基盤のアーキテクチャ(略図)
NP DB
API & Web 用 rendering を担う
GraphQL 未対応ページについてはNP Server に引き続きリクエストする
最終的にAPI に特化した project になることを目指す(
Web を切り離す)
既存の NP Server
Web server
Java
project
Next.js
project
初回来訪時
Next.js project 内の
ページ遷移時に発生する
API Request
ALB
対応状況により
path ごとに振り分け
(Path-based routing)
GraphQL
Web Client
28
Web Frontend Unit の立ち上げとリアーキテクチャに際してNext.js を採用したワケ
新基盤のアーキテクチャ(略図)
NP DB
API & Web 用 rendering を担う
GraphQL 未対応ページについてはNP Server に引き続きリクエストする
最終的にAPI に特化した project になることを目指す(
Web を切り離す)
既存の NP Server
Web server
Java
project
Next.js
project
初回来訪時
Next.js project 内の
ページ遷移時に発生する
API Request
ALB
対応状況により
path ごとに振り分け
(Path-based routing)
GraphQL
Web Client
「全ページ一気に置き換える」より、
「ページ毎に置き換える」手法をとること
path-based routing を設定し、
path ごとに request 先を handling する
現実解を求める上での条件 (1)
29
Web Frontend Unit の立ち上げとリアーキテクチャに際してNext.js を採用したワケ
新基盤のアーキテクチャ(略図)
NP DB
API & Web 用 rendering を担う
GraphQL 未対応ページについてはNP Server に引き続きリクエストする
最終的にAPI に特化した project になることを目指す(
Web を切り離す)
既存の NP Server
Web server
Java
project
Next.js
project
初回来訪時
Next.js project 内の
ページ遷移時に発生する
API Request
ALB
対応状況により
path ごとに振り分け
(Path-based routing)
GraphQL
Web Client
GraphQL を導入することで既存のアプリ用 API を
活用しながら開発する
Web 用 API が一部分しか存在しない&JSON 形式でない場合もあるため、
開発が必要だが最低限に抑えたい
現実解を求める上での条件 (2)
30
Web Frontend Unit の立ち上げとリアーキテクチャに際してNext.js を採用したワケ
新基盤のアーキテクチャ(略図)
NP DB
API & Web 用 rendering を担う
GraphQL 未対応ページについてはNP Server に引き続きリクエストする
最終的にAPI に特化した project になることを目指す(
Web を切り離す)
既存の NP Server
Web server
Java
project
Next.js
project
初回来訪時
Next.js project 内の
ページ遷移時に発生する
API Request
ALB
対応状況により
path ごとに振り分け
(Path-based routing)
GraphQL
Web Client