先週の Front-Trends 2013 カンファレンス でGregor Martynus氏は，"Look ma, no backend!" と題した講演を行った。アプリケーション開発を主にフロントエンドの側面から捉えて，サーバ側のコンポーネントは単にブラウザでサポートされない機能の実装手段とみなす，というのがその内容だ。このアプローチは，アプリケーションをサーバ側中心に考えて，フロントエンド技術を使ってそれを拡張するという，従来のWebアプリケーション開発とはまったく反対のものだ。このアイデアを広めるために，noBackend という名前のサイトもローンチされた。
InfoQでは氏に詳細を聞くことにした。
noBackendとは，つまりバックエンドを重視せずにアプリケーションを開発することだと思うのですが，なぜそれが興味深いのか，そこから何が望めるのかを説明してください – どのようなメリットがあるのでしょうか？
アプリケーションの開発プロセスは，以前に比べればずいぶん楽になりました。それでもアプリを開発しようとした時，まず最初にバックエンドの処理を考える，という手順自体は変わっていません。どんなテクノロジを使うか，データベースは何にするか，などを決める必要があります。つまりアプリ開発の設計プロセスは現在でも，バックエンド側の制約で決められているのです。しかしもう，そんな必要はないのではないか，と私は考えました。ユーザの観点から言えば，アプリで大事なのはユーザエクスペリエンスです。"どうやって動いているのか" なんて気にしません。noBackendが提供するのは，最初 "すべてが可能" としておいて，そこから遡って考えるという，フロントエンド駆動の設計プロセスなのです。
バックエンドを持たないWebアプリというのは実現可能なのでしょうか，どのような制限があるのですか？
noBackendというのは，バックエンドがまったくないアプリのことではありません。紛らわしいのは認めますが，覚えやすいことばだと思います。
noBackendの意味はつまり，バックエンドについてはもう 考えなくていい，ということなのです。現在のブラウザでできること，できないことを区別する必要はありません。そのようなギャップは，今ではJavaScriptで埋めることができます。舞台裏でサーバと通信しているという事実を隠すことも可能なので，フロントエンド開発者は気にする必要がありません。選択肢はたくさんあります。テクノロジ的な観点から言うと，フロントエンド開発者としての快適なエクスペリエンスのために必要なものが２つあります。
- CORS – クロスドメインのAJAX要求を行うために必要。
- 非同期コード – コールバック，イベント，あるいは約束で実装する。
いずれも入手可能な技術ですから，実現への準備は万端です。
サイトに ドリームコード(dreamcode) という用語がありますが，これは何でしょう？
Hoodie の開発を始めたとき，最初に手掛けたのはフロントエンド開発者向けのJavaScript APIでした。そこが一番気になる部分だからです。舞台裏がどれほど複雑でもいいのです。ユーザ向けの部分こそ，可能な限りシンプルにしなければなりません。そこで，すべての制約を忘れて考えることにしたのです: "オーケー，ユーザにサインアップしてもらおう。最高にシンプルなJavaScriptで実現するにはどうすればいいのかな？" その他にも私たちのサイトでは，いくつかのユースケース をリストアップしてあります。
その好例がjQueryです。jQueryはシンプルかつパワフルなAPIを提供するという，すばらしい仕事をしています。それが成功している一番の理由だと思います。
ドリームコードについてもうひとつ，本当にクールだと言えるのが，開発者ならば誰でもできるという点です。経験の深さに関係なく，誰でもコードを夢見る(dream)ことができるのです。たとえ初心者でも，私たちのようなシニア開発者の頭に刻み込まれているような制約を考えない分，かえってメリットがあるかも知れません。
そしてドリームコードは，noBacked なアプリ設計プロセスへと導くツールでもあります。普通の手順ならば，最初はバックエンド開発者に対して，ユーザアカウントとか，Eメール送信，アップロードといったように，何が必要かを説明することになるでしょう。バックエンド開発者がそれを開発してRESTfulなAPIを用意すれば，次はフロントエンドの担当者が，例えばjQueryのAJAXメソッドを使ってワイヤアップしなければなりません。ドリームコードではそうではありません。フロントエンドの担当者が，アプリケーションユーザの本当のニーズを記述できるようになるのです。それがフロントエンドとバックエンドの間のインターフェースになって，双方が開発に取り掛かることができます。
バックエンドから見たドリームコードは，
noBackendで使用されるバックエンドは，セキュリティに関してはどうなのでしょう？ EメールAPIのJavaSciptコンソールからの利用や，スパム送信への利用を防止するような方法はありますか？
何もありません。Eメールの送信方法をもっとも単純な方法で定義しているだけです。 Eメールの送信，支払いの受信など，どんなことであってもセキュリティが重要なのは当然です。ただ私が言いたいのは，フロントエンドAPIにそのようなものを反映する必要はない，ということなのです。とにかくシンプルでなくてはなりません。スパム防止のロジックなどは，サーバ側で実装すべきです。アカウントを持たないビジターによるＥメール送信を防止することは可能ですし，１分間に10以上のＥメールを送信しようとした場合も同じです。このようなことは，バックエンド担当者ならば以前から取り組んできた問題です。彼らはこの種の処理には長けています。フロントエンド担当者はそのような問題に煩わされたくないでしょうし，その価値も十分にあります。私はそう確信しています。
もし次世代のHerokuを作りたいのなら，バックエンドであることの苦労をすべて取り除いて，美しく構築されたフロントエンドを提供することです。そういうものがあるなら，いくらだって払いますよ。
noBackendはBackend-as-aServiceとはどのように関連しているのでしょう？アイデアが非常に似ているように思えますが。
Backend-as-a-ServiceはnoBackendの特別な形式です。noBackendをUX開発者の視点で議論したのと同じように，ビジネスの視点から説明することができます。
例えば Firebase はBackend-as-a-Serviceです。Parse や Kinvey，あるいは Backendless などもそうです。それから remotestorage.io，deployd.com などのオープンソースにも，noBackendソリューションと呼べるものはあります。ただしそれらは自分自身でホストしなければならなかったり，ホスティングサービスが有償のオプションであったりします。
あなたがWebサイトで紹介しているnoBackendサービスの中には，オフラインでも動作して，インターネット接続が可能になったときに同期を行うサービスがあります(remorestorage.ioやhood.ieなど）。この機能はモバイルアプリケーションにとって重要なものでしょうか，あるいはオフライン機能の方が関連性が高いのでしょうか？
オフラインで動作するということは，インターネット接続なしてアプリが操作可能になること(だけ)ではありません。レイテンシを低くする，という意義もあるのです。それによってファンタスティックなユーザエクスペリエンスを提供します。minutes.ioを例に取ってみましょう。minutes.ioはユーザがタイプしている間，その操作内容をすぐに，すべてブラウザのローカルキャッシュに保存します。その次のプロセスで，入力データとサーバを同期するのです。
noBackendはアプリケーション開発の新手法なのでしょうか，あるいは単に，特定カテゴリのアプリケーションのための "noBackend方式" というアプリケーション開発方法として解釈するものなのでしょうか？
新しいテクノロジは何であれ，特定の種類のアプリケーションだけのものだと思います。 noBackendは，ユーザエクスペリエンスが最重要事項であるフロントエンドに大半のロジックを実装するアプリケーションに適した，特別なアプローチなのです。
フロントエンド開発者は特に，選択肢のひとつとして理解しておくべきでしょう。noBackendソリューションは，これまでは実現できなかったアプリを開発する力を与えるような，優れたツールになるかも知れません。
noBackend Webサイトには，noBackend形式のアプリケーションを今すぐ構築するために利用可能な 既存のバックエンドソリューションの一覧が紹介されている。