コラム

サーバーレスというとサーバーサイドエンジニア側のキーワードとして盛り上がってきました。AWS LambdaやGCP FunctionsとAPIゲートウェイサービスを組み合わせて関数毎に機能を公開したりします。

そんな中、ここ数年フロントエンド界隈においてもサーバーレスへの注目が集まっています。今回は事例を含めてフロントエンド×サーバーレスという潮流について解説します。

静的ホスティング × 動的スクリプト

Netlify、Vercel、Firebase Hostingなど各種静的ホスティングサービスが存在します。これらのサービスでは特別なフォルダを作ることで、その中のファイルはサーバーサイドで実行できます。多くはAWS LambdaやGCP Functionsを透過的に利用する形式になっており、サーバーレスで実行されます。これらのスクリプトは実行可能時間はごく短く（2秒など）、利用目的としてはメールの送信やサーバーサイドでの値検証などになります。

本来静的サイトなのですが、一部だけ動的にしたいというニーズが常に存在します。静的サイトながらコンテンツを動的に変更したい、認証を付けたい、Eコマースを実現したい、お問い合わせフォームを付けたい、コメント機能を付けたいなどです。従来であればEコマースサイトやお問い合わせフォームに転送したり、Webサイト内への埋め込みで対応することが多かったですが、より自然な形で動的サイトを実現したいという考えが根底にはあります。

Service Workersの活用

Service WorkersはWebブラウザに内包されている機能です。幾つかの機能がありますが、その内の一つにブラウザのリクエスト情報をコントロールする機能（フェッチ）があります。PWA（Progressive Web Apps）でいうオフラインアクセスを実現するのは、このService Workersのフェッチを利用したものです。

このフェッチを使うことで、サーバーにはない機能がまるで存在するかのように振る舞えるようになります。いわばブラウザ内部で動作するプロキシーのように利用できます。

そして、このService WorkersのようなAPIを使って、エッジでJavaScriptを実行できるのがCloudflare Workersになります。他のFaaSと異なり、ベンダーロックインの少ない仕組みになっています。

Web Assemblyの活用

Service Workersと同様に注目したいのがWeb Assembly（WASM）です。WASMはブラウザで動作するバイナリファイルであり、JavaScriptとともにモダンなブラウザであれば動作が保証されています。開発言語はRustやC/C++、Go、Java、C#などが選択できます。

このWASMは実行環境さえあれば、ブラウザ以外の環境でも動作します。例えばFastlyのCompute＠EdgeではWASMをサポートしており、サーバーレスでWASMを実行できます。開発言語は幅広いので、TypeScriptに限定されずに開発・実行できるのが魅力です。

クラウドサービスの拡大

静的ホスティングであっても動的な機能を提供するクラウドサービスが次々に登場しています。例えば認証であればAuth0やFirebase Authenticationがあり、決済はStripeがあります。他にもShopifyはヘッドレスコマースをサポートし、静的サイトであってもショッピングカート機能が実現できます。

コメント機能であれば昔からDisqusが使われていますし、ユーザーインタラクティブな機能は手軽に実装できます。データベース機能やファイルアップロードなどはBaaS（Backend as a Service）が得意としている領域であり、HexabaseもBaaSとして提供する機能になります。

検索エンジン対応

動的な処理はWeb検索エンジンでインデックスされづらいという問題がありますが、静的ホスティングサイトではSSGやISRに対応するものが増えています。ページがなければサーバー側で生成するようになったことで、静的ホスティングサイトの可用性が広がっています。

同様にOGP画像も動的に生成できるようになっており、ブログサービスなどで活用されています。この部分もサーバーレス、またはクラウドサービスで対応するのが一般的です。これにより、FacebookやTwitterでシェアされる際にも問題なく対応できます。

フレームワークの対応

最近リリースされるフロントエンドフレームワークで、サーバーレス環境をサポートしはじめています。Next.js（Serverless Nextjs Plugin）やNuxt（nuxt-serverless）などはその代表例と言えるでしょう。これらを用いることで、サーバーレス環境においてもデプロイし、その結果としてスケーリングなどを気にしない運用環境ができあがります。

Firebase Hostingのようにローカル開発時にもサーバーレスファンクションを利用できるものもあり、ごく自然に利用できるようになっています。なお、同じJavaScriptであってもブラウザ側とサーバー側では実行できるものに差があり、開発者は必要に応じて使い分けなければなりません。

トライ&エラーのスピードが求められる

現在、Webサービスは毎日のように次々と登場しています。そうした中でスタートアップ企業などでは、開発サイクルを早めてトライ&エラーを何度も繰り返す必要があります。そのため、バックエンドについてはクラウドサービスを活用しつつ、フロントエンドの開発を高速化したいというニーズがあります。

これは、フロントエンドがよりユーザーに近い存在であり、ユーザーの多くはフロントエンドの出来によって良し悪しを判断するためです。開発リソースの限られるスタートアップ、新規事業立ち上げフェーズにおいては、フロントエンド・バックエンド両方を開発するリソース確保が難しく、その結果としてフロントエンド開発へリソースを集中させることになります。

BaaS（Backend as a Service）などを使うことである程度の問題解決はできつつ、標準機能だけでは足りないケースも多々あります。そうした時にはサーバーレスファンクションを活用し、不足機能を拡張して補う形になります。

まとめ

フロントエンドエンジニアであってもサーバーレスの活用は必須になっています。また、JavaScript（Node.js）が使える環境が多いことから、フロントエンドエンジニアが自分で足りない機能を拡張することも良く行われます。その意味ではフロントエンド・バックエンドという境目が消えつつあるのが実情です。

サーバーレスというとサーバーサイドエンジニアのイメージがありましたが、実際に使う開発者はフロントエンドエンジニアの方が多くなるかも知れません。