※このブログはヌーラボ真夏のブログリレー2024の6日目の記事です。
こんにちは！ウェブサイト課の松永です。
最近のウェブサイト課の活動として大きなものはNulab Developer APIサイトのリデザインとJBUG（ジェイバグ）サイトの新規開発があり、2024年6月にいずれも公開することができました。この記事では、フロントエンドエンジニアの視点でJBUGサイトの開発について共有できたらと思います。
目次
なぜ作ったか
JBUGはJapan Backlog User Groupの略で、Backlogユーザーによるコミュニティです。これまではJBUGに関する情報を紹介するページが存在せず、ヌーラボがJBUGについて情報発信をするときはブログやSNSに限られていました。もっと多くの人にわかりやすくJBUGの活動をお届けし、かつJBUGの理念や目的を一貫性のあるメッセージでお伝えすることで、JBUGをよりBacklog愛のある方が集まる場にできればと思い、新たにサイトを立ち上げることにしました。
なお、JBUGの参加受付については引き続きconnpassで行っております。
どんな仕上がりになったか
にぎやかな雰囲気とともに、全国各地でJBUGが開催されていることがイメージできるようなイラストで、Figmaでデザインが共有されたときに私自身とてもワクワクしました。
福岡は「みずほPayPayドーム福岡」と「福岡タワー」のイラストがありますね。JBUGのキャラクター「ジェイビー」もJBUGウェブサイト中のいろんなところに顔を出してくれていますので、ぜひ探してみてください！
JBUGサイトのトップページ
どのようにして作ったか
今回はログイン機能などがなく、動的サイトにする必要がなかったので、あらかじめ用意したファイル（HTML, CSS, JavaScript）でページを配信する静的サイトにしたいと思いました。
ただ、CMSで記事を投稿できるようにする必要があったので、WordPressの投稿データをGraphQLで取得するようにし、記事内容を含んだHTMLをAstroで事前に生成する方式を採用しています。
Astro
AstroはJavaScriptフレームワークのひとつで、静的サイトジェネレータとしての利用ができます。今回の場合、Next.jsではオーバースペックになってしまいAstroの機能で十分足りるのではないかということ、そして同時期に開発していたNulab Developer APIサイトでAstroを利用していて良さそうだったこともあり、Astroを利用することにしました。
結果的にAstroで複雑な追加設定をすることもなく、スムーズに開発できたと思います。Astroは必要に応じてReactやVueなどの他のフレームワークを取り込んで複合的に利用できる柔軟性もありますが、今回はそれらを利用する必要がなかったこともあり、Astroだけで完結させることができました。
おおまかなフォルダ構成は下記の通りになっています。
/ ├── public/ │ └── favicon.png ├── src/ │ ├── components/ │ │ ├── atoms/ │ │ ├── molecules/ │ │ ├── organisms/ │ │ ├── templates/ │ │ ├── pages/ │ ├── images/ │ └── pages/ │ └── styles/ │ └── utils/ └── astro.config.mjs └── package.json └── tsconfig.json
src/components/ フォルダ
このフォルダはAstroのデフォルトの環境でも用意されているものですが、src/components/ 内部のフォルダをAtomic Designの構成にアレンジしました。他のヌーラボのウェブサイトも同じようなAtomic Designの構成になっていて、ウェブサイト課のメンバーと相談の上で、そのまま採用することにしました。
各コンポーネントファイルに<style>を追加してCSSを書いていくだけで、デフォルトで自動的にスコープされるようになっています。つまり他のコンポーネントのスタイルに影響を与えることがありません。これはとっても便利な機能だと思います。
<style>
h1 {
color: red;
}
.text {
color: blue;
}
</style>
上記のようなコードが下記のようにコンパイルされます。
<style>
h1[data-astro-cid-2n2twevq] {
color: red;
}
.text[data-astro-cid-2n2twevq] {
color: blue;
}
</style>
[data-astro-cid-2n2twevq]が対象のコンポーネントに対しても追加されることで、スコープが有効になっています。
src/images/ フォルダ
画像を最適化できるように、可能な限りsrc/に画像を保存することをAstroがおすすめしているので、srcフォルダに新たにimages/フォルダを作りました。一方でfaviconやogimageなど、画像へのリンクを直接公開したい場合は画像をpublic/フォルダに保存しています。
src/pages/ フォルダ
このフォルダもAstroのデフォルトの環境で用意されています。src/pages/フォルダの構成は下記のようになっています。
/ ├── src/ │ └── pages/ │ │ ├── news/ │ │ │ ├── [category]/ │ │ │ │ ├── [page].astro │ │ │ │ ├── [slug].astro │ │ │ │ ├── index.astro │ │ │ ├── [page].astro │ │ │ ├── index.astro │ │ ├── 404.astro │ │ ├── index.astro
src/pages/フォルダにある.astroページコンポーネント、MarkdownとMDXファイル（.md, .mdx）は、自動的にウェブサイトのページになります。そのため特別な設定もなく、src/pages/news/index.astroは、jbuginfo.backlog.com/news/でページにアクセスできます。
また、フォルダ名・ファイル名をブラケットで囲んで動的ルーティングを利用しています。ファイル上の細かい設定は割愛しますが、例えばsampleカテゴリにtestスラッグの記事が存在する場合、jbuginfo.backlog.com/news/sample/test/で記事にアクセスできるようにしています。[page].astroのpageの部分には数字が入るようになっており、記事一覧のページネーションのために利用しています。
src/styles/ フォルダ
先述のとおり、CSSはsrc/components/フォルダ内の各コンポーネントファイルに書くようにしていますが、グローバルなCSSやmixinなどはこのフォルダに置いています。
src/utils/ フォルダ
例えばブログの投稿の日付をフォーマットする関数など、グローバルで使える便利な関数を置く場所としています。
GraphQL
GraphQLはFacebookによって開発されたAPIの規格です。他のヌーラボが管理しているウェブサイトでも利用事例があります。今回はWPGraphQLプラグインを利用して、GraphQLでWordPressの投稿データを取得しています。
例えば下記のようなGraphQLのクエリでリクエストすることによって、記事に関するデータをJSONで取得することができます。
query getPosts {
posts {
edges {
node {
id
title
date
slug
featuredImage {
node {
sourceUrl
mediaDetails {
width
height
}
}
}
categories {
nodes {
name
uri
slug
}
}
}
}
}
}
REST APIが投稿データのうち利用しないデータまでレスポンスとして返してしまうのに対して、GraphQLは必要な情報だけリクエストすればその分だけレスポンスを返してくれる点で使い勝手が良いと思います。
やってみてどうだったか
近年では様々なJavaScriptフレームワークが出てきていますが、それらと同様にすぐにAstroの環境構築ができました。思い立ってすぐに開発が進められるのは嬉しいことですし、開発サーバーの利用やビルドに関しても特にストレスを感じることはありませんでした。全体的にとてもいい体験でしたが、特によかったところや考慮が必要だったところを下記に共有したいと思います。
URLに関する設定
astro.config.mjsというAstroのconfigファイルで設定をすれば、URLの末尾にスラッシュをつけるかどうかの設定ができたり、リダイレクト処理の設定も入れることができたりします。このあたりも手軽に設定できてよかったです。
import { defineConfig } from 'astro/config'
export default defineConfig({
// 例: URLの末尾のスラッシュを必須にする設定
trailingSlash: 'always',
// 例: /old から /new にリダイレクトする設定
redirects: {
'/old': '/new',
},
})
サイトのパフォーマンス
静的サイト全体的に言えることだと思いますが、サイトのパフォーマンスの最適化がしやすいです。JBUGサイトに関して言えば、今のところアニメーションなどの負荷がかかるような要素もないですし、比較的高いパフォーマンスでサイトを公開できていると思います。
JBUGサイトトップページのLighthouseのスコア（Desktop）
特に、パフォーマンスの観点で言えば、Astroに組み込まれているImageコンポーネントの利用が便利でした。フォルダ構成のセクションで先述の通り、これを利用するにはsrc/フォルダに画像を置く必要がありますが、比較的容易に画像の最適化を行うことができると思います。
import { Image } from 'astro:assets'
import photo from '@images/photo.png'
---
<Image class="test" src={photo} alt="JBUG（ジェイバグ）の会場の雰囲気" />
例えば上記のように書けば、下記のように出力されます。
<img src="/_astro/photo.hash.webp" class="test" alt="JBUG（ジェイバグ）の会場の雰囲気" width="103" height="50" loading="lazy" decoding="async">
Imageコンポーネントのsrc属性とalt属性に関しては、必ず追加する必要があります。src/フォルダの画像を利用することでいくつかの属性は自動的に追加され、入力する画像の拡張子によってはデフォルトでwebpに変更されます。
loading属性やdecoding属性はデフォルトで値が決まっているので、状況に応じてImageコンポーネントに属性や値を追加で設定する必要があります。
必要な投稿データだけ取得
例えば投稿データのタイトルとリンクだけが必要な場合など、必要なものだけ選んでデータを取得できるのはGraphQLの特徴でありメリットだと感じました。私がGraphQLにそれほど明るくなくて気づいていないところもあると思うので、利用しながらデメリットも見つけていきたいと思います。
前提が違うのですが、Markdownで記事を書くことができるならCMSを利用せずともAstroでブログ記事を作成することができます。md(mdx)ファイルをGitで管理できるので、利用者によってはMarkdownで管理するほうが便利なこともあると思います。
運用面で解決しきれていない問題
ウェブサイトの公開までに解決できなかった問題が残っており、WordPress上で公開しているサイトデザインに即したプレビューができるようになっていないことや、Jenkinsでビルド・デプロイを自動化している部分に時間を多く要している問題があります。これらはヘッドレスCMSとしてWordPressを使う場合に起きる（起きやすい）問題だと思うので、事前に対策を考えておくべきでしたし、今後解決していきたいと思っています。
おわりに
Astroがどんなサイトにも適しているわけではないと思いますが、今回のブログのようなウェブサイトを制作するときには積極的にAstroを利用したいと思いました。Astroの機能のほとんどはまだ利用できていないのと、アップデートも早い印象があるので、これからもAstroの情報を追っていきたいと思います。
JBUGサイトもアップデートを続けて、JBUGに関する情報が網羅されるような状態を目指していきます。もっと多くの方にJBUGの活動がお届けできますように！
