mottox2 blog

blog

サーバーサイドの人にも伝えたいJAM Stackと静的サイトのイマ

mottox2
mottox2
2018/07/06

aircloset社で行われたWeb界隈LT会で話した「サーバーサイドの人にも伝えたいJAM Stackと静的サイトのイマ」です。

静的サイトと動的サイト

静的サイト

早くて、落ちないし、セキュリティで心配することも少ないけど、自由度低いよね。

動的サイト

運用面倒。スケーラビリティ的に不利
攻撃される。
速度的に不利。

静的サイトジェネレータ

動的に静的サイトを生成するジェネレータ
基本的にGitHubのpushと連動してビルドするような感じ

時代は変わっている

monolithic services => micro services
FTP => GitHub中心の開発環境の変化
PC => スマホシフト

GitHubを中心とした開発者の環境の変化

ソースコード管理がGitHubになり、CIと連携してデプロイしたりすることが一般的に。
GitHub Pagesで簡単にサイトが公開できたり、GitHubと連携して静的サイトを公開できるNetlifyの登場
ビルドコマンドの指定や、Global CDN、PR Previewなどがデフォルトで使える。神サービス。

スマホデバイスによる速度の重要性の高まり

3Gから4Gになったとはいえ、都市部から離れると3Gや劣悪な通信環境が存在する。
Googleのアルゴリズムで遅いサイトはランクが下がりそう
より早くレスポンスを返して、通信量を抑える必要性が高まっている。
動的サイトはサーバーサイドでの処理の分速度的に不利。

Micro Services志向な思想

Micro Serviceが一般的になり、サーバーサイドの分離はともかく、Stipe(課金)やContentful(CMS)、Sentry(エラー収集)などの外部サービスとAPIを経由して利用する方法が一般化した(はず)。
backendは別サービスのAPIを使ったり、自前で実装するなりして、フロントエンドだけ別プロジェクトに切り出すのも自然。

これらの変化に対応するように静的サイトジェネレータも変わった。

以前の静的サイトジェネレータ

  • 基本的にGitHub上にあるMarkdownを元に静的ページを生成 直近の静的サイトジェネレータ
  • APIを叩いてそのデータを元に静的ページを生成

静的サイトよさそうでは?

なんと言ってもメンテナンスフリーになるなら最高だよね。

ここで主要なジェネレータを確認

Jekyll Ruby
Hugo Golang
Next JS(React)
Gatsby JS(React)
Nuxt JS(Vue)
=> JavaScriptを選ぶべき

なぜJavaScriptのジェネレータを選択するのか?

  • Serverで生成したHTMLをJSでいじるのはそろそろ辞めたい。
  • APIを叩いてViewに表示する処理がJSで完結する。
  • 考えることが増えないままSPAにできる
  • フロントエンドの資産である開発環境が便利。
  • ビルド環境を整えるのにNodeだけ用意すればよい。

JAM Stack

これらの
JavaScript
APIs
Markup
の要素を満たすスタックをJamStackという。

各フレームワークの紹介

Next.js

  • SSR付きのReactアプリケーション用のフレームワーク。
  • routerやSSRに関してレールを敷いてくれる。

Nuxt.js

  • @potato4d氏が日本に流行らせたVueのフレームワーク。
  • Next.jsインスパイア系のフレームワークだったけど、フルスタック方面に向かっている。
  • 設定より規約なフレームワークという印象。フロントエンドのRails(個人の見解です)

GatsbyJS

  • Reactで静的サイトを書くためのフレームワーク
  • とにかく普通に書けば早くなるように設計されている。
  • 複数のデータソースを扱いやすい設計になっている。

よくある質問

問い合わせフォームとかは?

Google FormとかNetlify Form、他フォーム系のSaaS

ビルド速度はどうなの?

静的ページをビルドするのはそんなに数分あればいける。生成処理は最適化が行われ続けているが、APIを叩くのがネックになりやすい。

React, Vueって考えることが多そう。

Next.js, GatsbyJS, Nuxt.jsを選べば、ある程度のレールが敷かれているためライブラリ選定問題と直面することは少ない。

WordPressを静的サイト化したい

わかる。既存のものはWordPressのまま静的HTML化するプラグインとかでごまかすのがよし。普通に既存の要件を満たそうとするとめちゃくちゃしんどい。
新規のものはWordPressではなく、Headless CMSを採用するとよさそう。

Next.js、Nuxt.js、Gatsbyの使い分け

SPAにする必要がない・更新頻度が高くないのであればGatsby。SPAにする場合でReactならNext.js、VueならNuxt.js。具体的にCGMとかだとNext.js、Nuxt.jsにする。Nuxt.jsの方が万人向けだと思う。
APIに利用制限がある場合、静的サイト化する必要があるのでGatsbyを選ぶ気がする。

One More Thing

Youのサイト、SPAでもよくね?

基本的にSPAも静的サイトと言って良い。
PrebuildではないのでJAM Stackとは呼べないが、より構築が簡単になるはず。

<html>
  <div id='app'></div>
  <script src='app.js'/> <!-- #appに対してSPAを展開するJS -->
</html>

SSRとか静的化の話をしているのは、

  • Googleがちゃんとクローリングしてくれるか不安
  • ソーシャルメディアにシェアされたときのOGP情報 の要件をSPAでは満たせなかったから

Netlify Prerendering

  • Netlifyがprerenderingをサポート
    • bot向けにJSでレンダリングした結果を返してくれる。
  • ホスティングサービスについたのでシームレスに設定可能

以前からもprerender.ioというサービスもあったが、設定がめんどくさそうであまり流行っていない印象

例: SmartDrive

takenorip先生のSmartDrive

どんどん静的サイトでできることが広がっている。

運用レスなサービス作っていこうぜ。

@mottox2フリーランスWebデベロッパー

都内でフリーランスエンジニア・デザイナーとしてWebサービスやスマホアプリを作っています。Ruby on Railsでの新規事業の爆速立ち上げや、使いやすいSPAの開発が得意です。

お問い合わせはこちら