thumbnail

ブログをNext.jsでリニューアルしました。

このブログをWordPressのブログからNext.js製のブログに作り変え、ついでにデザインの回収も行いました。
この記事では本ブログの技術スタックや、WordPressから移行する際の注意点・所感等まとめます。

その際の知見や備忘録はおいおい記事にしていきます。

主な技術スタック

主な技術スタックは次の通りです。

  • フロントレンドのフレームワーク:Next.js
  • 使用言語:TypeScript
  • スタイリング:styled-components
  • ブログ記事のAPI:GraphQL
  • ヘッドレスCMS: WordPress
  • デプロイ先:Netlify

それぞれの技術の選定理由

Next.js

Nuxt.jsとの二択だったのですが、個人的に最近はVueよりReactです。(最近Vueの記事を書いてないのもその辺の理由です…)。ちなみに、next exportはしておらず、一部ページでSSRを利用しています。完全なJamstackにするかどうかは要検討。

TypeScript

TypeSciript一択。

styled-components

新規で開発するならTailwind cssが良いと思っているのですが、このブログはWordPressで作ったものがベースにあり、0から実装したオリジナルデザインのSassを当てていました。そしてBEMをベースにしたCSS設計にしていたため、元々コンポーネント単位で設計したデザインファイルがありました。

それがstyled-componentsとの相性が良かったのが選定理由です。コンポーネントの粒度は少し違いますが、ベースのスタイリングのコードはコピペで済みました。

Graph QL

WordPressをヘッドレス化し、WPGraphQLというGraphQL APIで記事を取得できるAPIを利用しています。GraphQL APIはRest APIよりも優れていますし、なるべく新しい技術で実装したかったのが選定理由です。

WordPress

これは元々WordPressを使っていたため、継続利用です。すでにこのブログの投稿周りのデータがたくさん蓄積されていますし、なにより無料で使えます。管理画面も便利です。

Netlify

消去法です。VercelはAdsense入りのブログは無料枠で使えず、cloudflareは無料枠だとデータ容量が小さいので断念。

※追記
しばらく運用してみて感じたのが、Netlifyは思っていたより遅いです。というのもNetlifyは日本にCDNがありません。速さを求めるならVercelで課金するしかなさそう。

気を付けるべき点・反省点

Google関連の設定

Google Analytics、Adsense、Search Consoleの設定です。入念にチェックを行うべきでした。
サイトマップ自体は自動で生成していたのですが、WordPressの頃のサイトマップとのファイル名が異なっていたため、Googleがクローリングに失敗していました。また、Adsenseでads.txtを作るのを忘れていて忠告をくらったり、サイトアクセス数がカウントされなくなったり、問題が少々発生。
実装にばかり気を取られていました。

コードハイライタのPrism.jsがSWCに対応していない

もともとコードハイライタにPrism.jsを利用しており、それに依存したコードを書いていたため継続で利用することにしました。しかしどうやらNext.js版のPrism.jsはSWCに対応していなくて.babelrcを作成せねばならず、結局Babelを利用することになりました。何か解決策はあったかもしれませんが、時間の関係で断念。

Babelを使うことによって併発される不具合

Babelを利用することになったことによって、styled-componentsの設定もBabel用に設定しなおす必要があったりと、問題が併発しました。個人開発のライブ感でこの辺はどうにかなりましたが、事前の技術選定の重要性を再認識。

デプロイ先を実装が完了してから選んだこと

Netlifyを選んだのは、デプロイの準備が完了したあとになってからでした。Cloud flareがファイル容量の問題で使えず、急遽変更することになったのです。フォームの送信周りの実装をNetlify用に実装し直すという手戻りが発生してしまいました。

CodePenが全て表示されなくなる

これは実装の方法にもよっても変わってくると思いますが、私の場合はCodePenのデモが全てデフォルトで非表示になってしまいました。記事への埋め込み方法をiframeによる埋め込みに変えて元に戻したのはいいですが、CodePen自体を最近の記事では使っていなかったため、気づくまで1週間以上かかりました。

その他所感

BEMで実装していたおかげで、移行が容易だった

技術選定のところでも記載しましたが、このブログをWordPressで作ったときにBEMに基づいた設計をしていました。変更に対して強いBEMですが、技術の垣根を越えた変更にも強いことを実感しました。昨今のコンポーネント指向の開発と親和性は非常に高いです。

Chat GPT

開発でChat gptに多々頼りました。使ってみて実感しましたが、これからプログラミング系の技術ブログの価値は下がることになりそうです。特に疑問解決系の記事等。今後技術ブログは、他人に教えるという目的というより、ネットの海に残した個人的備忘録という側面が強くなるのでは、と思い、Chat GPTに聞いたら次のように答えました。

ChatGPTの存在が技術系のブログの価値を下げるとは言えません。技術系のブログは、特定のトピックや問題についての情報を提供することを目的としており、ChatGPTの存在はそれに影響を与えません。実際に、ChatGPTを使用することで、技術系のブログがより豊富な情報を提供することができ、読者の理解を深めることができるかもしれません。ただし、ChatGPTを使用しているかどうかにかかわらず、技術系のブログが価値を持つためには、信頼性の高い情報、正確な情報、分かりやすい説明、そして読者の役に立つ情報を提供することが必要です。

Chat GPT

今後について

今まではある程度長い記事を書いましたが、今後は短めの記事も増やしていきます。