Atraeコーポレートサイトリニューアルの裏側
先日、株式会社アトラエのコーポレートサイトがリニューアルされました。
デザイナーの@kumi1132さん視点からの記事が先日公開されましたが、
実装を担当したエンジニアからも裏側をちょっと話してみたいと思います。
(前提)リニューアル前の課題
「使用技術の古さ」
以前のサイトはRuby製のMiddlemanをベースに作られておりました。 今からすると、middlman?ナニソレ？みたいな印象になるかと思いますが、７年前はReactはまだまだ一般的ではなく、弊社もRubyがメインの会社であり、悪くない選択だと思っていました。（当時は）
「更新性の低さ」
リニューアル以前のサイトでは、CMS的な要素が一切なく、Github上で管理されているソースコードをローカルで編集し手元のPCからFTPを使って直接アップロードすることでしか、サイトを更新することが出来ませんでした。
ですので、公開されているコーポレートサイトとGithubにあるソースコードが一致しない（!?）ということも少なからずありました。
リニューアルに際し、 「更新しやすい」「社内で触れるメンバーが多い」 状態になるような技術選択が出来ればと思っておりました。
リニューアル後の構成
- Next.js
- Typescript
- Contentfull(headlessCMS)
- apollo（GraphQLクライアント）
- heteml（静的hostingサービス）
それぞれかいつまんで説明します。
Next.js
2021年現在のアトラエ社は完全にReactの会社です（Webフロントエンドは）。
ですので、React製のフレームワークを使い以外の選択肢は、ほぼ無いと思っておりました。
また、徐々に社内の各プロダクトでNext.jsが採用されてきていることで、コーポレートサイトを作るには少々too matchなフレームワークだとしても、社内のメンバーの馴染みやすさをとって、Next.jsを採用しました。
Typescript
2021年のフロントエンドでは（ほぼ）必須な言語です。
ですが、コーポレートサイトという性質上、デザイナー寄りのメンバーがコードを触ることが比較的多いです。デザイナーにとってはとっつきにくい言語ですが、全社的にTypescriptを採用しているので、慣れもらう機会として、採用させていただきました。
Contentfull
更新頻度の高いコンテンツを、非エンジニア・デザイナーメンバーが更新できるようにするためには、headelessCMSの採用がマストでした。
その中で今後の運用面や料金面を考えてContentfullを採用しました。
また、GraphQLを使えるということで、CMSの都合に依存しないデータ構造に出来ることもメリットとして大きかったです。
heteml
こちらは消極的な理由ですが、、
- 以前から使っている
- コーポレートサイトだけ別にするメリットがあまりない
別にするのが億劫だった
といったところです。
ゆくゆくはVercel等への移行を考えております。
deploy
リストにはないですが、触れておきます。
リニューアル以前のデプロイは、「個人のPCから直接アップロード」でした。
今回は、GithubActionからmainブランチを自動デプロイ出来るようにしてます。「個人のPCから直接アップロード」は原則禁止にしました。
今後に向けて
i18n
アトラエのコーポレートサイトは英語対応をしておりますが、Next.jsのi18nは使っておらず、そのあたりのRoutingや切り替えは全部手作りです。
Next.jsのi18nがStaticBuildに対応していないため（そりゃそうだ）、仕方ない処置です。いずれVercel等に移行した際にはNext.jsのi18nを使うつもりです。
Contentfullとの連携
コンテンツをContentfullで管理できるようにはなりましたが、デプロイする際は、GithubActionで権限を持っているメンバーが自動デプロイさせてる状況です。「Contentfull更新=>サイトも即反映！」という状況をどこかでやりたいなと思っております。
以上、簡単にではありますが、「Atraeコーポレートサイトリニューアルの裏側」でした。
Discussion