Skip to main content

CAMPHOR-のWebサイトをリプレイスした (フロントエンド編)

honai RELEASE
このエントリーをはてなブックマークに追加

この記事はCAMPHOR- Advent Calendar 2021 9日目の記事です。

こんにちは、ほない です。

先月、CAMPHOR-のWebsite をリプレイスしました。

デザインや機能に大きな変更はなく、使っているフレームワークや技術構成を変えたというのがメインです。

本記事では、主にフロントエンドを担当した筆者が、移行のきっかけやプロセスを振り返ろうと思います。

CAMPHOR-新Website

以下では、移行前のWebサイトを「旧Website」、移行後のWebサイトを「新Website」と表記します。

なぜ移行したか

フロントエンドの辛さ

旧Websiteは、Djangoを利用したサイトでした。フロントエンドはBootstrapとjQueryを中心としたものでしたが、Bootstrapをカスタマイズしていたり、Djangoとは別でフロントエンドのJavaScriptやSCSSをGulpでビルドする必要があったりと、Djangoでモノリシックにやっている割にはフロントが複雑化していたのが辛さとして挙げられます。

さらに決定的だったのは、ある日jQueryのバージョン（マイナーバージョン）を上げたらフロントの一部機能が動かなくなるという事案が発生しました。
労力をかけて更新する必要を感じましたが、今のままの構成で頑張るなら、モダンなフロントエンドにしてみるのもいいかもと思い、筆者がほかの運営メンバーに提案したのが移行のきっかけとなっています。

バックエンド

Django自体はCAMPHOR-の他のサービスでも使っていて、特に移行のきっかけとなるような辛さはありませんでした。しかし、フロントを移行するにあたって、バックエンドはAPIとしてデータを提供するだけでいいだろうということになりました。

Djangoの既存コードを流用できるDjango Rest Frameworkなども考えられましたが、運営メンバーにはPythonのままでやりたいと思う人はおらず、むしろ別言語で作り直したほうがいいという意見が多かったので、バックエンドもDjangoを捨て、作り直すことになりました。

移行してみたかったから

我々は企業ではなく、技術が好きな学生が集まっているコミュニティです。自分たちが触ってみたい技術を、コミュニティのメンバーと一緒に（個人開発よりは大きい規模で）触れるのはとても楽しいことです。

負債になるかどうかを慎重に検討したり、移行したときの手間とメリットを掛け合わせて考えたり、そういったことを考えるのももちろんエンジニアリングの一環で、重要なことです。しかし、モチベーションがあるメンバーがいるなら、やってみよう、手を動かしてみようという姿勢が技術コミュニティでは大切だと思います。

新しい構成

新Websiteでは、バックエンドとフロントエンドが別レポジトリになりました。（現状、どちらも公開はしていないのでご了承ください）

フロントエンド

フロントエンドで主に使っているのは

  • TypeScript
  • React, Next.js
  • styled-components
  • react-bootstrap

などです。

バックエンド

バックエンドは

  • Go
  • MySQL
  • gRPC

などです（詳しくは明日の記事で！）

API

フロントエンドとバックエンドは、gRPC-webを用いたAPIで通信しています。

フロントの解説

この節ではフロントエンドで特徴的な技術要素をピックアップして解説します。

next/imageによる画像最適化

旧Websiteでは、高DPIのディスプレイでの表示をきれいにするために、一部の画像やスポンサーのロゴなど、手動で2種類の解像度の解像度の画像を用意していました。

画像を2枚ずつ用意していた

next/image を利用することで、解像度の高い画像を入れておけば、適切なサイズ・フォーマットに変換してキャッシュしてくれるようになり、開発・運用がしやすくなりました。

ただし、CSSのbackground-imageに使っている画像はサイズも大きく最適化できていないので、これは今後の課題となっています。

スタイリング

移行前はSCSSでスタイリングをおこなっていましたが、違うSCSSファイルから同じセレクタに対してスタイリングが行われていたりと、可読性に欠ける部分がありました。

移行後は、 react-bootstrap と styled-components を組み合わせた構成になりました。

Bootstrapはclassベースでのスタイルを提供していますが、それをラップしてReactのコンポーネントにしたライブラリがreact-bootstrapです。

基本的には、styled-componentsによりスコープのあるスタイルとなり、またコンポーネントの定義と同じファイルにスタイリングがあるため、開発体験が向上したように思います。

さらに、最近リリースされた react-bootstrap v2 にバージョンアップすることで、依存しているBootstrapのバージョンがv4からv5になり、jQueryへの依存がなくなるなど、メリットがありました。

ただし、JavaScriptベースでコンポーネント指向であるReactと、HTMLとCSSでclassを基本としたBootstrapとでは相性が悪い部分もあります。

例えば、細かい調整をしたいときに、BootstrapであればUnitily Classを使ってある程度の調整ができますが、Reactでそれをやるべきかは微妙なところです。ある程度以上のスタイリングが必要な場合は、以下のように styled-components で上書きを行います。

また、ブランドカラーなどスタイル関係の共通の変数が、SCSSのVariableで行っている部分と、TypeScriptの変数でstyled-componentsのテンプレートリテラルに流し込んでいる部分とが混在しています。基本的にはTypeScriptに寄せたいところですが、Bootstrapをカスタマイズする必要があるので、SCSSをなくすことはできていません。これも今後の課題です。

大変だったこと

移行に2年半かかった

そんなにかかるか？と思われる方も多いと思いますが、フロントエンドに関しては、initial commitから実際に公開するまで2年半かかりました。

もちろんずっと作業をしていたわけではありません。運営メンバーが忙しくて開発が止まったり、ある程度見た目が整った後にバックエンドの開発との調整が進まないまま放置してしまったり、運営メンバーの代替わりがあったりと、時間がかかってしまいました。

Contributionのグラフ

こちらがフロントエンドのレポジトリのContributionのグラフです。休止期間のほうが開発期間より長いことがわかります。恥ずかしい。

Next.jsのメジャーバージョンアップを3回した

開発を始めた2年前（2019年5月）、当時は現在ほどNext.jsはメジャーではありませんでした。そのため当初はcreate-react-appを利用していました。その後、Next.jsのSSGの機能などが充実してきてメジャーになってきたタイミングでNext.jsに移行しました。

最初の移行は2020年10月ごろで、Next.js v10が出る少し前でしたので、そのときはv9でした。そこからv10、v11、v12と3度のメジャーバージョンアップがありました。

Breaking Changeがたくさんあったわけではありませんが、必要なReactのバージョンがほかに使っているライブラリと競合したり、使いたいライブラリとの相性が悪かったりと、振り返ると意外と工数がとられた部分です。

学んだこと

期限や再開時期の設定

前半に、「学生コミュニティだから、移行してみたかったらやってみるのも大事」と書きましたが、それでも1年半以上開発が止まってしまうのはよくないです。

開発が長期間止まった原因の1つは、「担当者がインターンで忙しくなるからいったん休止するか」となった時に、再開時期の目安を決めていなかったことだと思います。インターンが落ち着いて授業期間に入ったのちも、担当者で足並みをそろえて再開することができませんでした。この時点でモチベーションが下がってしまい、長い休止期間に入ってしまいました。

さらに、バックエンドの検討をあまりせずにフロントエンドだけ見切り発車的に開発を始めてしまったこともあります。私はバックエンドをメインで担当できる技術力もなかったため、他の運営メンバーに頼るしかなかったのですが、バックエンドをやるモチベーションがある人がいるかの確認や、どういう構成が必要かなどの相談があまりできていなかったように思います。

再開のきっかけとなったのは、CAMPHOR-の他のタスクも含め放置されているものを一気に掘り起こして、やるかやらないかを決める会をしたことです。その会で、バックエンドも含め、Websiteのリプレイスは「やる」ことに決まり、再び本格的にプロジェクトが動き出しました。

集中開発日の効果

趣味でのチーム開発にありがちだとは思いますが、それぞれ授業やサークルで開発できる時間がばらばらで、非同期のコミュニケーションだけだと、開発は結構難しくなります。

プロジェクトが休止状態になってしまったら積極的に予定を合わせて集中開発日を設けるのがよいと思います。

Websiteの移行も、後半は集中開発日での開発がメインで、バックエンドとフロントエンドの細かい調整などもしつつ何とか完成に持っていくことができました。

学生コミュニティとモチベーション

学生コミュニティにおけるタスクは、メンバーに直接金銭的なメリットや強制力がないことがほとんどです。さらに今回のような緊急性がない重めのプロジェクトだと、やりたい、やるべきというモチベーションだけが頼りになることも多いでしょう。今回のWebsite移行で改めてそういったタスクをチームで進めていくことの難しさを実感しました。

まとめ

大変なこともありましたが、なんとか先月、新Websiteを公開することができました。ページ遷移は爆速になりましたし、メンバーにとってもメンテナンスしやすい構成になったと思います。ぜひみなさんも新Websiteを訪れてみてください。

明日のCAMPHOR- Advent Calenderの担当はKMConnerさんです。

このエントリーをはてなブックマークに追加

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です