前回『MVP開発でおすすめのPaaS』についてご紹介しましたが、
もし効率を考えるのであれば、『連携しやすいPaaSで揃える』という手があります。

 

例えばFirebaseで揃えたり、AWSのPaaSで揃えたり……といった感じです。

 

特に、複雑なバックエンド周りはなるだけシンプルに済ませたいですよね？
今回はそう言うときに便利な『BaaS』についてご紹介します。

 

BaaSとは何か？

さきほど『Firebase』や『AWSのPaaS』といったくくりを述べましたが、これは厳密にはBaaSではありません。
BaaSはBackend as a Serviceの略なので、バックエンドで使うPaaS単体に焦点を当てた場合に、BaaSと呼ぶこととなります。

 

ただし、基本的にFirebaseはバックエンドのサービスばかりなので、BaaSと呼んでしまっても、そこまで『間違っている』とは言われません。

 

しっかり言葉にして定義すると、『Web アプリおよびモバイル アプリ開発者にバックエンドを簡単に構築する方法を提供するサービス』と呼ぶことが出来ます。
※なので『モバイルバックエンド』を指して『MBaaS』と呼ばれることもあります。

 

BaaSのメリット

迅速に開発できる

これは前の記事でも説明しましたが、『通常行わなければいけないインストール作業や初期設定をすべて省略し、すぐに使い始めることができる』ことがBaaSの利点です。
特にバックエンド周りは、複雑な部分や、セキュリティ等緻密さが求められる箇所があります。
こういった難易度の高い部分をサービスとして提供してくれるのがBaaSという訳です。

 

コスト削減

BaaSの多くは『従量課金』となっています。
必要となった分だけ支払えばいいので、無駄なコストを支払う必要がありません。
更に、ツールの保守に当てる時間等も減らす事ができます。

 

アプリ（ビジネス）の開発に集中できる

そして金銭的なコストだけでなく、人的なコスト・時間コストの面でもBaaSは優れています。
バックエンドに充てていた時間を、すべてアプリ本体の開発に回すことが出来ますし、
なにかトラブルが起きたとしても、バックエンド側の設定ミスや異常を疑う必要がほぼないため、原因の切り分けを素早く行うこともできます。

 

スケーラビリティ

多くのBaaSでは、自動的にスケーリングする機能が備わっています。
なのでトラフィックが急増したとしても、サーバがダウンして信頼性を失う……といったことを避けることができます。

 

速度

基本的にそれぞれのBaaSでは、各機能が迅速に動くよう最適化されています。
もちろん、一概に『BaaSのほうが早い！』と言える訳ではありませんが、最適化を行っていないバックエンドシステムと比較すれば、非常に大きな差が出るでしょう。

 

手厚いセキュリティ

BaaSにはハイレベルなセキュリティ保護が掛けられています。
また、新たに見つかった脆弱性にもいち早く対策が取られるため、『あわててパッチを充てる』等大慌てする必要もなくなります。

 

アップデートの手間がいらない

先程のセキュリティについてもそうですが、
日々改善されたり、新たな機能が加えられたりしている為、それらの恩恵にいち早く預かる事ができます。
それに、本来アップデートで掛けなければ行けない手間や、メンテ時間をサービスの向上へ充てる事ができます。

 

BaaSのデメリット・気をつけるべき点

一方で、BaaSだからこそのデメリットも存在します。

 

カスタマイズがしにくい・出来ない

基本的にBaaSは用意された機能しか利用できません。
『この機能を加えられれば問題が解決するのに』と思っても、サービスの裏側を触ることは出来ないため、諦めるか、何かしら別のツールを介して処理を挟む必要があります。

 

サービスに依存することとなる

先程の点と重なることですが、提供できるサービスをBaaS側に左右されることとなります。
また、BaaS上で組んだサービスを他に持っていくことは、非常に難易度が高い作業です。
もしBaaS側が突如サービスの値上げを発表したとしても、受け入れるしかないことがほとんどでしょう。

更にきついのは『サービスの終了』が告げられた時です。
発表から終了までの短い間に、代替手段を考えなければなりません。

 

他サービスとの連携が難しい

BaaS内部での連携について、非常に行いやすいというメリットを紹介しましたが、
裏を返せば、外部との連携が取りにくいという側面もあります。

もちろん、BaaS内部のサービスも外部連携の手段をいくつか用意してくれていますが、セキュリティ等の観点から通常の手段が取れないこともあるでしょう。

 

コストが計算しにくい

『従量課金性』にはいくつものメリットがありますが、逆にコストは計算しにくくなるでしょう。
年度の初めに予算を申請する場合等、計算が非常に難しく感じるかもしれません。

 

 

PaaS、IaaSとBaaSの違いは？

ここまで読んだ方の中には、『BaaS』と『PaaS』、『IaaS』の違いがわからない……という方もいらっしゃるでしょう。
特に、先程挙げたメリット・デメリットのいくつかは、『PaaS』『IaaS』にも言うことができる点が多く含まれています。
しかしながら、これらはそれぞれ別個のものです。

 

IaaSとBaaSの違い

IaaSはあくまで基本的なインフラを提供するものです。
『仮想マシーン』『ストレージ』『ネットワーク』等がついてはいますが、
それに乗る『OS』『ミドルウェア』『アプリケーション』等は自分でインストールを行い、管理する必要があります。

 

そのサーバ上で何をするのも自由ですが、代わりにサポートやアップデート等を受けることは出来ません。

 

PaaSとBaaSの違い

PaaSはアプリケーションを開発・デプロイ・実行するためのプラットフォームを提供しています。
一見、BaaSとPaaSが同じものに見えるかもしれませんが、
PaaSはフロントエンドからバックエンドまでの全体的なサポートを提供する一方
BaaSはあくまでバックエンドの管理を行うサービスになります。

 

なので例を挙げると『Firebase Hosting』はPaaSです。あくまで静的なHTMLのホスティングが主なので、バックエンドではありません。

 

一方で『Firebase Authentication』はBaaSです。これはバックエンドの一部として機能を提供するものだからです。

 

では『Cloud Functions for Firebase』はどうでしょうか……
これは少し難しいですね。関数をトリガーできるという意味ではBaaSですし、コードをデプロイして実行できる面を見ればPaaSになります。

 

更には『Firebase Cloud Messaging』を例にあげると、これはPaaSではありません。プラットフォームではないからです。
通知の統計や管理の面で言えばSaaSに分類されるでしょう。しかしプッシュ通知の送信という面ではBaaSには含めることも可能になります。

 

この通り、PaaSとBaaS（更にはSaaS）の境目は時々曖昧になります。
なので、使い方も混同されることがほとんどです。（というより、１個１個のツールについてバックエンドかフロントエンドかを突き詰めていくのは、面倒ですし意味がありません……）
あくまでそれぞれの特性を理解した上で、イメージとして捉えておくのをおすすめします。

 

 

おすすめのBaaS

Firebase

ここまでたくさん取り上げてきたFirebaseですね。BaaSで最も有名なサービスといえばFirebaseでしょう（厳密なところはさておき）
Firebaseは、アプリケーションのバックエンド関連のサービスを、主な目的として提供しています。
Firebaseだけでサービスを作ることも問題なくできますし、英語のものを含めれば、ドキュメントも広く用意されています。

 

AWS Amplify

AWSは、主にPaaSとして捉えられるか、もしくはEC2・S3のようにIaaSとして捉えられることが多いですが、ではAWSの中でBaaSを提供するものは何か、といえば『AWS Amplify』となります。

 

特にフロントエンドを得意としている人が、手早くバックエンド側を済ませたい場合に有用なサービスです。

 

Azure App Service

ウェブサイトを構築するためのプラットフォームとして作られたもので、元々は『Web Apps』という名前で展開されていました。
BaaSとして紹介していますが、フロント部分も充実しています。
React, React Native, Angular, Vue等、幅広いフレームワークに対応しているからです。
Azureで揃えたい人にはお勧めのサービスです。

 

Back4App

Firebaseに対抗するサービス！といえば聞こえがいいですが、運営が自称しているだけで規模感は異なります……。
しかしBack4Appにはユニークな点があります。それはオープンソースのBaaSであることです。

 

といっても、ソースコードを細かく見る人はそう多くないと思いますが、
オープンソースであるということは、『最新の技術』や『他のツールで手が届かないところ』等に対して、柔軟に対応してくれることを期待できます。
実際、SQLやGraphQLへの対応等、Firebaseに出来ないことがBack4Appでは出来たりします。
最近ではChatGPTプラグインによるアプリ構築等も実装されているようです。

 

Supabase

『オープンソースのFirebaseの代替ツール』と言えばSupabaseも欠かせません。（というよりSupabaseのほうが有名ではあります）

 

Firebaseの主要な機能はほぼ網羅しつつ、管理画面等は非常に整理されているため、
『Firebaseはごちゃごちゃしてわかりにくい……もっとBaaSをシンプルに使いたい』という人にはおすすめのサービスです。

 

Vercel

Vercelは前回の記事でも紹介しましたが、
正直なところBaaSと呼べるか、といえばBaaSではありません。

 

あくまでフロントエンドの機能が主眼だからです。
しかしながら、BaaSを使うに当たって、Vercelと組み合わせることで素早くサービスを開発できますし、
非常にシンプルなものであれば、Vercelのオプション機能だけでバックエンドまで作ってしまうことも不可能ではないでしょう。

 

Hexabase

『国産のBaaSはないのか』という方におすすめするのが『Hexabase』です。
ログイン、ユーザー管理、アクセス制御、データベース、APIゲートウェイ、拡張コードの実装(FaaS)等、一通りの主要なBaaS機能は揃っています。

 

そして国産サービスである強みは、UI・ドキュメントが全て日本語で用意されていることですね。
なので初めてBaaSを触る方にもおすすめできます。（ただし、費用は少し高めです…）

 

『とにかく形にする』時、非常に役立つBaaS

フロント部分を得意とする人にとって、バックエンド部分というのは鬼門です。
見た目の優劣やユーザーの使い勝手を模索すればいいフロント部分とは違い、バックエンドは『データベースの管理』『API設計』『セキュリティの確保』等、専門的な知識が多分に求められます。
また、「果たしてこれで合っているのだろうか」という確証も持ちにくいため、たとえ完璧にこなしていたとしても常に不安がつきまといます。

 

しかしそういった状況にある開発者にとって、BaaSの存在は救いです。
複雑なバックエンド構築の手間を大幅に軽減し、最適なサービスが最適な形で提供されています。
デメリットももちろんありますが、『１つのサービスを形にする』にあたり、最速の手段はBaaSを使うことでしょう。

 

ChatGPTの出現等により、日々目まぐるしく状況が動くWEBサービス界隈において、早いことは強力な武器です。
ぜひシステムを作るに当たって、BaaSにバックエンドを任せることが出来ないか、一度検討してみてください。

 

 

お問合せ＆各種リンク

お問合せ：GoogleForm

ホームページ：https://libproc.com

運営会社：TodoONada株式会社

Twitter：https://twitter.com/Todoonada_corp

Instagram：https://www.instagram.com/todoonada_corp/

Youtube：https://www.youtube.com/@todoonada_corp/

Tiktok：https://www.tiktok.com/@todoonada_corp

 

presented by