ウェブサイトをAstroでリニューアルした

2018年にGatsbyで構築したこのウェブサイトをAstroでリニューアルしました。この記事では、リニューアルに至った背景や技術スタックについて紹介します。

リニューアルの背景

このサイト自体は2018年5月にファーストコミットが行われており6年もののサイトになっていました。サイト自体のデザインやコードが古くなり、手を入れたい気持ちが高まっていました。一方でGatsbyの本を出版している程度には思い入れがあるため、現状のGatsbyサイトを残したいという気持ちがストッパーになっていました。 しかし、Gatsby本体の開発が実質停止状態になっていたのに加え、仕事で扱うことの多いNext.jsと比べても、そのモダンさとのギャップが目立つようになりました。そうした理由からリニューアルを行うことにしました。

技術的なお話

Astroの採用

リニューアルの構成を検討するにあたり、Next.jsやRemixといった主要フレームワークも候補に挙げましたが、最終的にはAstroを採用することにしました。Astroはアプリケーションというより、ドキュメントサイトやブログなどの「コンテンツ中心」のウェブサイト向けに特化しており、やりたいことがシンプルに実装でき、ブログ中心のウェブサイトにはピッタリだと考えました。

以前から続けてきたesaへの投稿をAPI経由で取得し、ウェブサイトに表示するフローはそのまま維持しています。これはAstroのv5で導入された「Content Layer」を利用することで簡単に実現できました。ビルド時にコンテンツをキャッシュできるため、API制限のあるサービスを扱う際も負荷がかからず、とても使い勝手がいいです。 ほぼ同じことができるGatsbyJSのGraphQLのデータレイヤーよりも洗練されていると感じています。

Content Layer用のローダーの自作

esaは国内向けのサービスであるため、AstroのContent Layerに対応したローダーが存在せず、自前で実装する必要がありました。 他のローダーの実装を参考にしながら開発を行いましたが、非常にスムーズに実装できました。しばらくして、コードが固まったタイミングでnpmパッケージとして公開します。

Astroはマークダウンを扱うremark系の処理を公式が持っていて、それに相乗りする形でマークダウンの変換処理も任せることができました。旧式のマークダウン変換処理と差分がありましたが、適切なプラグインを導入し、妥協できるレベルの出力にしました。 今まではesaが変換してくれたHTML¹を利用していましたが、フレームワークに乗っかったことで、より柔軟な変換処理ができるようになりました。

zodでスキーマを定義してデータのバリデーションを行いつつも、TypeScriptの型として提供されるのは、とてもいい仕組みだと思いました。

マイクロインタラクション

このサイトではリニューアル現在はクライアントで動作するJavaScriptを（3rd Party Scriptは除いて）書いていません。ただその中でも、ページ左上ナビゲーションの現在位置を示すドットに、View Transition APIを活用したインタラクションを実装しています。 ページ間の遷移時に、ブラウザがスムーズにアニメーションを付けてくれるのが特徴です。今回のリニューアルでお気に入りの箇所です。

その他の開発技術

今回のリニューアルではTypeScriptをファーストクラスで採用し、スタイリングにはTailwind CSS、パッケージマネージャーにはpnpmを利用しています。また、今回はデプロイをNetlifyではなくVercelで行っています。Netfliyも同人誌を書くレベルで好きだったのですが、時は残酷です。

数年ぶりの大きなアップデートでしたが、「ウェブフロントエンドの変化がとにかく早い」と言われていた時期に比べると、あまり変化はないと思いました。適切な頻度で知識のアップデートを行えば、ついていく分には問題がなさそうで安心しています。

これからの展望

このウェブサイトはもともとフロントエンドエンジニアとしての技術の素振りも兼ねていました。今となってはUIデザイナーが本業なので、素振りというよりは今までとは違った表現やメモ置き場として運用していきたいと思っています。 ゆくゆくは海外のデザインエンジニアがやっているようなCrafts的なものを作っていきたいです。

旧サイトのGatsbyJS版のソースコードはGitHubのパブリックリポジトリに引き続き残しておきますので、興味がある方はぜひ覗いてみてください。