先日のGoogleのAngularJSミートアップに発表されたSynthは，Node.js上に構築された"APIファースト"のWebアプリフレームワークだ。
プロジェクトがGitHubで公開されて１ヶ月半の間に，1スターから500以上にまで達している。しかしながら作者は，コミュニティの大部分はこのフレームワークをまだ十分に理解していない，と言う。
Synthを開発したJon Abrams氏は自身のプロジェクトについて，従来のNode.js Webフレームワークとは異なる解釈に基づくもので，AngurlarJSビューのロード時に自動的にプリロード可能なバックエンドリソースを容易に開発するために設計した，と説明している。
Synthはページロード時のAngularモデルデータのプリロード，ページロード時のHTMLビューのプリロードといった機能を備えるとともに，フロントエンドコードを"front"フォルダに，バックエンドコード(nodeコードとパッケージ)を"back"フォルダに格納するという，簡略化されたプロジェクト構造を採用する。
プリロードの詳細について，氏は次のように述べている。
データを自動的にプリロード可能にすることで，一部のWebビューをロードする場合に生じる，データ表示の遅延という問題が解決されます。
Twitterが初めてSPA(Single Page App)アーキテクチャに移行した頃のことを覚えている方も多いでしょう。あるツィートのリンクをオンラインでクリックすると，最初にページがレンダリングされて，それから少し間をおいた後に，ツィートが最終的に見えていました。
もしTwitterがSynthを使っていたなら，データ取得用のAPIリクエストを要求する必要がありませんから，最初のレンダリングでツィートを正しく表示できていたはずです。
プリロード機能は，SynthのAPI処理関数にPromiseのサポートを追加することで実現されている。これによりAPIハンドラがExpress応答オブジェクトと直接通信する必要がなくなるため，APIハンドラの再利用が可能になる。APIハンドラはAPIコール時だけでなく，特定のWebビューが要求されたときにもコールされる。これにより，モバイルWebアプリに付きものの高いレイテンシを軽減することが可能になるのだ。
Synthはさらに，フォルダ作成や関数のネーミングに工夫を加えることで，新たなRESTful APIリソース作成を簡略化しようとしている。Synthはリソースフォルダから.js(あるいは.coffee)ファイルを検索して，それが配置されているフォルダ名に基づいたAPIを生成する。memoesソースを作成するには，同じ名前のフォルダを作成した上で，そのディレクトリ内の任意のファイルに対象とするHTTPメソッド用のリクエストハンドラを宣言すればよい。これはエクスポートする関数をアサインすることで行われる。
Synthに対するコミュニティの反応はさまざまだ。氏によると，AngularJSコミュニティは非常に肯定的であって，特にTwitterに関連した部分で顕著だという。その一方で氏は，先日Hacker Newsのフロントページに掲載されたSynthのプレゼンテーションにおいて，Synthが解決しようとする問題が一部の人々を混乱させたように感じている。
Cybercom FinlandのソフトウェアデザイナであるPanu Horsmalahti氏は，命名機能について次のようにコメントしている。
機能に影響するような新しい命名規則を覚えるのは，私の経験上，事態を簡単にするというよりも，かえって難しくしてしまいます。開発の"簡単さ"とか"早さ"を見せれば，クールなデモ効果を作り出すことはできます。しかし実際にアプリケーションのスケールになれば，事態はもっと渾沌として，命名規則の限界が見え始めるでしょう。
それに，このような機能を生成する命名規則があちらこちらに散在していたら，コードベースを学ぶのも難しくなってしまいます。
氏の考え方の健全性を疑うコメントもあった。ソフトウェア技術者のRichard Bishop氏は言う。
"クライアント側フレームワークのために専用のサーバを！" という件を見ると，何か勘違いしているように思えてなりません。
ブラウザは単なるクライアントです。 ブラウザ用のフレームワークはすべて，動的なブラウザアプリケーションを作るための抽象化(のはず)です。クライアントフレームワークで開発する上で，特別なサーバフレームワークの開発が必要ならば，それは一度立ち止まって，何かが間違っているのではないかと考えるべき兆候に違いありません。
氏は次のように答えている，
このアイデアがクレイジーなことは認めます。クレイジーなアイデア結構。クレイジー，いいじゃないですか！
ですが，ブラウザが単なるクライアントだという点には同意できません。そう扱いたければ，そうすることは可能です。ですが，アプリのデータにアクセス可能なサーバと同じような役割を，クライアントコードも果たすことができる，という事実のメリットを活用することもできます。そして，それがSynthを設計した目的なのです。
Synthは現在ベータ版で，活発な開発作業中だ。実運用で使用できる状況には達していない。InfoQの読者はGitHubプロジェクト(またはsynth-apiなどの子プロジェクト)を通じて，このオープンソースプロジェクトに貢献することが可能だ。