Stackbitを触って感じるWebアプリ構築の進化のひとつの形

この記事はBASEアドベントカレンダー 19日目の記事です。

devblog.thebase.in

Webアプリの解体

こんにちは。フロントエンドエンジニアの松原(@simezi9)です 近年、Webアプリはクラウドの発展とともにそのあり方を大きく変質させてきました。 具体的にはXaaSの発展により、Webアプリはその構成要素をあらゆるレイヤにおいて細かく分解され、それらを開発者が組み合わせることで作られるようになりました。 このアプローチによりシステムはプラガブルになり可用性の面でも品質面でも大きく進化しました。 その反面で当然このアプローチにも問題があります。その最たるものが組み合わせの複雑度の増加だと思います。 あらゆるものがプラガブルになった反面、それぞれのサービスをどのように組み合わせてWebアプリを構築していくのか自体が一つの知見・分野となり、「昔はWebアプリフレームワーク一個さえあればそれでよかったのに」というような声が出てくる一因となっているようにも思います。 そうした流れの中にあっては、必然的にプラガブルになったサービスをまとめること自体をサポートするサービスやフレームワークが出てきます。それはかつてのRailsであり、AWS Elastic Beanstalkであり、最近で言えばNuxt.jsのようなものであったりします。

Stackbitはそうした「Webアプリ開発にレールを敷く」サービスの1つであり、 近年急激に隆盛した「JAMstack」アプリを一気通貫に作成することができます。

JAMStackの登場

JAMstackとはJavaScript+APIs+Markupの頭文字をとった概念で、

  • アプリとしての動作や機能はすべてクライアントサイドのJSに集約し、
  • データやロジックはすべてAPI経由で取得し、
  • そのデータを表示するテンプレートをデプロイ時に事前にビルドした静的ファイルで返却する

ようなWebアプリを指す概念です。 こうした構成を取るメリットはいくつもありますが、とりわけ「静的ファイル(HTML,CSS,JS)配信を中心にした構成」によるサイトパフォーマンスの向上やスケーリングの楽さが多く取り上げられています。 JAMStackは特にWordpressなどのCMSが担ってきた領域のアプリを実現するための手法としてよく登場します。

というよりも個人的な印象で言えば、Webアプリで多く使われていたCMSを分解しプラガブルなサービス群へと変換していく中で生まれたベタープラクティスがJAMstackという形になったというような気もします。

JAMstackなCMSを構築する過程では機能とそれを提供するサービスは大きく以下のように分類されます

  • HTML/CSSで静的ページを出力する( 例:Hugo, GatsBy, VuePress ・・・etc)
  • クライアントサイドでのルーティングやAPIとの連携を行う機能 (JavaScript)
  • コンテンツの配信・管理を行い、APIでデータを提供する機能(例:Netlify CMS, Contentful・・・etc)
  • 生成したファイルをホスティングする機能(例:Netlify, Github Pages・・・etc)

これらの組み合わせをあれこれ試しつつサイトを構築するのは一人のエンジニアとしては腕の見せ所でもありとても楽しい部分ではありますが、実際にサービスを作る上では一定の知見や検証が必要になります。 その部分を代わりに担保してくれるのがStackbitのようなサービスになります。 実際にこのStackbitを使ってサイトを生成してみようと思います。

Stackbitを試してみる

Stackbitでは以下の事を自動で設定してくれます(ただし本記事執筆時点ではBETAのため、組み合わせるサービスの選択肢は多くがCOMING SOONの状態) - 生成されるサイトのビジュアルテーマの設定 - サイト生成に使用する制定サイトジェネレータの決定 - Headless CMSとして仕様するサービスの設定 - Gitによるコードのホスティングとデプロイフローの整備

サイトの生成までは特に難しいことは有りません

サイトの生成を始める

f:id:simezi9:20191216074845p:plain

サイトのテーマを選ぶ

用途にあわせて標準のテンプレートからサイトのスタイルを選びます。 ひとまず一番先頭にある「Exto」を選びます

f:id:simezi9:20191216074905p:plain

サイトジェネレータを選ぶ

サイトの構築に利用する静的サイトジェネレータを選びます。 ここではとりあえずGatsbyを選択します f:id:simezi9:20191216074915p:plain

CMSを選ぶ

サイトのコンテンツを管理するためのCMSを選びます。 ここではサイトのデプロイにNetlifyを使うので、NetlifyCMSを選ぶことにしてみます

f:id:simezi9:20191216074942p:plain

githubとの接続

生成されたサイトのバージョン管理をするために、GitHubアカウントと生成するサイトの紐付けを行います。

f:id:simezi9:20191216074954p:plain

サイトの生成

これで最初の作業は完了し、サイトの構築・ビルド・デプロイまでが開始されます

f:id:simezi9:20191216075037p:plain

Github

サイト生成のタイミングでGithub上にリポジトリが作られて、サイトの開発・記事の投稿、デプロイフローなどの整備が全て整った状態でリポジトリが用意されます。 ローカル開発を開始するための手順なども用意されていて、静的サイトジェネレータを触ったことがある方にはすぐに開発できるような状態が整っています

実際に出来上がったサイト

標準状態で、一通りの機能を備えたサイトがWebサイトとして公開されるところまで自動実行されます。 これらはソースはGithub、サイトはNetlify上に展開されており、自前で管理するサーバーが一切ないという広義でのサーバレスが実現されています。

f:id:simezi9:20191216075056p:plain

Lighthouse

Lighthouseを使ってページのメトリクスを測定してみます。 性能にスロットルをかけたモバイル環境の設定で実行してもご覧の通り、かなり高いパフォーマンスを持ったサイトになっています

f:id:simezi9:20191216075108p:plain

記事の投稿

今回はNetlify CMSを利用しているため、記事の投稿はそちらを経由して行います。 ページ右上部にStackBitが提供するコントロールパネルがあるのでそこからアクセスをします

f:id:simezi9:20191216075128p:plain

するとCMSの管理画面が出てくるのでここから記事を投稿します。 このあたりは、HeadlessCMSらしく、コンテンツの管理に必要な機能だけが搭載されたシンプルなものになっています。

f:id:simezi9:20191216075149p:plain

記事を投稿すると、その投稿がGithubリポジトリにコミットされ、静的サイトジェネレータが実行されサイトの再ビルドが動き始めます。その様子はサイトのコントロールパネルからも確認できるようになっています。

f:id:simezi9:20191216075157p:plain

まとめ

StackbitはWebアプリ構築の第一歩を強烈に加速してくれるサービスでした。 そして不要になったらGithub上にコードがあるのですぐにサービスを切り離すことも可能です。 カスタマイズ性の高さと構築の定形作業のコストを軽くしてくれるという意味でとてもバランスのよいサービスだと思います。 このサイトを作るまでの工程は、非エンジニアの方でもおそらく数十分〜数時間程度あれば可能なほどに容易です。 ただし、あくまでWeb開発のベタープラクティスを集合させたサイトの雛形を提供してくれるものなので、 Webサイトの構成がどうなっているのかを把握できていないレベルの方ではサイトのレイアウトを変えたり、機能を追加開発することは厳しいのではないかと思われます。 そういう意味ではある程度フロントエンド側の構築に理解がある方がパパっとポートフォリオだったりブログサイトを作るのにはとても便利なサービスかと思います。もちろん技術構成自体は普通に大規模サイトでも通用するようなものなので、その第一歩として活用することも十分可能だと思います。 自分でWordpressを構築して、デプロイできるサーバーを探して・・・とやっていた時代がそれほど昔でないことを思うと、 この生産性の高さは強烈だなあ、すごい時代だなあと思わずにはいられません。

サービス自体はまだベータ版ですが、正式版のリリースが待ち遠しいサービスだと思います。

明日はData Strategy Sectionの岡さんとPAY株式会社 テックリードの東さんです。お楽しみに!