Jamstackはなぜ生まれたのかを解説してみる

Jamstackという手法が2016年にNetlifyから初めて言及されてから6年。日本でも流行り始め、いろんな会社・個人の方々が使っていますね。今回のLTでは、なぜJamstackが生まれたのか？について、エンジニアを長くやってきた経験から感じたことをお話したいと思います。

最初にJamstackについて言及された、Matt Biilmannのカンファレンス動画
https://vimeo.com/163522126

Transcript

1. Jamstackはなぜ生まれたのか？ を解説してみる 2022/08/22 ジャムスタックチョットデキル!!真夏のLT大会2022 @shinoyu
2. このLT is 何？ - Jamstackという手法が2016年にNetlifyから初めて言及されてから6年。 日本でも流行り始め、いろんな会社・個人の方々が使っているかと思い ます。 - なぜJamstackが生まれたのか？について、エンジニアを長くやってきた 経験から感じたことをお話したいと思います。 - 完全に私個人の主観でのお話となります。なるべく正確なお話をさせて いただくつもりですが、間違っているところや気になるところあれば後で やさしくおしえてください
3. chot inc. でCTOをやっているバックエンドエンジニアの酒クズの おじさんです。加工しか勝たん。 インターネットコンテンツとして生きてます。 経歴: 18年目 組込 ➡ 業務システム ➡ ソシャゲ ➡ EC ➡ 広告 ➡ SES ➡ chot inc. フロントエンドエンジニア多い会社なので、最近何かと肩身が狭 い(´・ω・`) フロントエンドスキルで会社をガシガシ引っ張っていってくれる 方大募集してます！！ このLT is 何？
4. - JavaScript/APIs/Markup の頭文字をとってそう呼ばれてます - 2016年、Netlify CEOのMatt Biilmannがとあるカンファレンスで発表したのが始 まり https://vimeo.com/163522126 - 当時は「The New Front-end stack」として紹介された - Git centric workflow, front-end build tools, API Economy Jamstackのはじまり
5. https://www.cloudflare.com/ja-jp/learning/serverless/glossary/backend-as-a-service-baas/
6. 様々な機能をAPIとして提供するサービスがめっちゃ増えた - 通称BaaS（backend as a service)と呼ばれる類のもの - 一般的なWeb Applicationを構築する場合、昔はバックエンドである程度自前 でミドルウェア立てたり開発必須だったが、各種サービス使えばそれで済むよ うになった - 本来のバックエンド側のレイヤーを外だし出来る環境が生まれた - DBですらサービスとして提供される時代に 開発の形が大きく変わった近年
7. 1サーバーから全部配信 (昔ながら) フロントとバックエンドを分けた SPA構成 (日本だと2014年頃から？) これまでのWebサービスの作り方 バックエンドがサービスの殆どを担っていた UIとビジネスロジックの分離が起きる フロントから直接APIを叩いて描画する
8. The New Front-end stack SSG SSR hosting( vercel, etc… ) CSR フロント側をハブにして、 いろんなサービスを併用し1つのアプリケーションを構築する
9. - 最初から静的なものはそのままHTMLなどにして配信する - フロント側でAPI叩かなくてもいいものは、静的ファイルとして CDNから配信する - セキュアでとてもはやい - バックエンドの管理コストが不要になる - バックエンド側のアップデートちゃんと回せてますか？ - バックエンドを作り込むよりサービスで賄えないかをファーストに - 出来合いのもので済むならそれ一番楽 - 自前で新しくバックエンド作るのは、 要件が出来合いのものを超えたとき - 一般的なWEBアプリ開発ではそこまで要求されるの多くない - 決済とかメール配信とか自前できっちりやろうとするとそれなりに大変 - クレカ管理とか、バウンスメールの対応とか ...おまかせしちゃったほうが楽 これまでの手法と比較してどういう違いがあるのか？
10. - 各バックエンド機能が外部サービスに分離したことによって、フロントエンド側である 程度ロジックを置かないといけなくなる - それぞれのサービスは単機能なので、それらをつなぐ実装が必要になる - とはいえ、UI部にビジネスロジックを書くのはアンチパターン 。 - 故にクラス化したり、 BFF層へ押し込めたりする。単体でちゃんとテストできるようにしようね - 本当にコアなロジックは自前で APIを作ってその中に収める必要があるのは変わらない - 外部サービスの障害で可用性に大きく影響する - 外部サービスに依存しているので、 どれかが障害起きると共倒れするリスクあ る - とはいえバックエンドも いろんなサービスのピタゴラスイッチ になってるのが現実だったりす る。 - ミッションクリティカル要件の場合は自分たちでコントロールできるようにしておいたほうが良さげで はある。あえてバックエンドを作る判断も必要 。 これまでの手法と比較してどういう違いがあるのか？
11. - メディアとかコーポレートサイトの改修系によく使ってる - microCMS + Next.js だけで完結することがほとんど 。相性がよい。 - Wordpressの管理が嫌になった企業からの引き合いがそこそこある - 今の市場的に、バックエンドよりフロント案件のほうが多く引き合い来てる - 様々な会社からモダン UIなWebシステム開発の話をもらっている。 - chot inc.がJamstackを押し出して営業始めたのが去年の夏 くらい。それなりの数 (30件ほど)の案 件を請け負ってきた。市場ニーズがめっちゃ高い。 - 外部サービスのサービスまじ優秀 - 契約して利用するだけで必要な機能がサクッと実装できる - 自前で作るほうがコストが高い現実 - 納品した後のメンテナンスとか考えると ...ね - フロントだけに集中して素早く機能を作り込むことができる chot inc.はJamstack最推ししてます
12. - Vercel使えばかんたんにプロダクションに載せられる手軽さ - PRごとに閲覧可能なURLを発行できるの最高に開発体験が高い - 全Webエンジニア体験してみてほしい - 導入が楽すぎて、CI/CDの作り込み実装が不要なのとてもつよい - Next.js API Routesの存在。外部のAPIを叩くときのBFFとしての機能 - SECRET KEYが必要なものをフロントで叩くわけにはいかない - そのためだけにバックエンドを用意して中継しなくてもこの機能で解決出来る - いざ自前のAPI functionが必要になっても、ある程度フロントエンドエンジニアが触 れて対応出来る体制を作れる - フロント・バックエンドで開発言語を共通化できる強さ - フロントとfunction側で型情報などが共有できる。とても楽 - 採用面とか、エンジニアのキャリアとかそのへんにも大きく影響してる - バックエンド側もある程度触ってみたい、というエンジニアが多いのもある そのためのNext.js + Serverless + Typescript
13. - サービスを組み合わせて素早く組み上げることが要求される世界に - 案件次第ではあるが、やはりビジネスのリードタイムは極力短いほうが好まれる - 色々なBaaSサービスがリリースされている土壌がある - 巨人の肩にのる。便利な車輪はうまく使う。 - 開発のしやすさも大きな要因に変わってきている。フレームワークの機能を使い倒せ - フロント要件の比重がメッチャ高くなってる - 使いやすく快適な体験がどこでも求められてる。年々顧客からの圧が上がってる - 見えてる氷山の比率が逆転してきて、フロント開発にコストが掛かる形になってきた - 顧客も市場の変化に必死に追いつこうとしてる。フロント側のユースケースをフレキシブルに変えら れるようにして支えられるように開発していくことが要求されてきている まとめ 変化に素早く追従して、最適な体験を早く顧客に提供できるのが肝要
14. ご清聴ありがとうございました