Instant 1.0 – AIで作成したアプリ向けバックエンドプラットフォーム
(instantdb.com)- バイブコーディングで作ったアプリに リアルタイム同期、オフラインモード、認証、ファイルストレージ をまとめて追加できるオープンソースのバックエンド
- バックエンド生成はVMの起動ではなく DB行の追加 なので、数ミリ秒でバックエンドが作成され、使わなければコストはゼロ
- フロントエンドでは
db.useQueryとdb.transactだけで リレーショナルクエリとデータ変更 をそのまま処理でき、別途APIサーバーを構築する必要なし - 楽観的アップデート が標準なので、ネットワークが遅くてもUIが即座に反応し、失敗時は自動でロールバック
- ファイルアップロードもDB行として管理されるため、投稿を削除すると 添付ファイルもCASCADE削除 — S3同期コードを書く必要なし
- Magic Code、OAuth、Guest Auth などの認証方式を選んで使え、Presenceで「誰が接続中か」もすぐに実装可能
- AIエージェントが API/CLIで直接アプリ作成、スキーマ変更、権限設定 まで実行できるため、プロンプトだけでフルスタックアプリのデプロイまでつなげられる
npx create-instant-appの1行で NextJS、Bun、Vite など好みの環境に即座にプロジェクトを作成- クエリ言語 InstaQL はJavaScriptオブジェクト構文をそのまま使えるため、GraphQLのようなビルド段階やコード生成なしで動的クエリが可能
- 4年かけて開発された Postgresベースのマルチテナント構成 により、数千のアプリを単一インスタンスで運用し、GitHubで全体をオープンソース公開
2件のコメント
Hacker Newsのコメント
正直な疑問なんだけど、なぜvibe codedアプリにフレームワークが必要なのかわからない
コーディングエージェントに、フロントエンドはHTML5/Vanilla JS/CSS、バックエンドは好きな言語で書けと指示すればいいだけでは
何百もの依存関係も不要だし、デプロイもエージェントに任せれば終わり
コードが増えるほどコストだけでなく性能も落ちるし、バグや不要な抽象化も増える
結局は良いフレームワークを自分で作らせようとして時間を無駄にすることになる
むしろ学習データに含まれている既存フレームワークを使うほうがいいと思う
今のモデルでは、ランディングページを超える規模にはおすすめしない
良い抽象化は可読性と保守性を高めるし、純粋なHTML/CSS/JSはすでに主流ではない
人間が理解して検証できる必要があり、車輪の再発明でトークンと時間を浪費することになる
LLMも人間のように複雑なスパゲッティコードにはまり込むことがある
例として、ボタンをクリックするだけでバックエンドを作成し、25行のコードでリアルタイムtodoアプリを完成できる
すぐにビジネスロジックに移れて、すでに検証済みのパターンとツールの中で作業できる
エンタープライズソフトウェアは依然として大規模なコードベースを必要とするので、フレームワークの価値は大きい
数多くのエッジケースをすでに解決済みの実戦投入済みソリューションを提供してくれる
良いフレームワークを選べば、何千もの意思決定と保守の負担を減らせる
フレームワークは結局、スケーラビリティのために存在する
そもそも人々が本当にこういうものを必要としているのか気になる
FigmaやLinearのようなマルチプレイヤーアプリを作る人がどれだけいるだろう？
ほとんどはCRUDアプリだろうし、わざわざ独自技術に縛られる理由があるのかなと思う
たとえばLinearはマルチプレイヤーだけど、他のCRUDアプリがそうでない理由はよくわからない
抽象化がうまくできていれば、同期エンジンベースのアプリのほうがむしろ簡単に作れる
Linearチームもこのツイートでそう述べていた
GitHubリポジトリ
CRUDアプリは単純で反復的だから、AIにぴったり
バックエンドはGoバイナリ、フロントはReactで、99.9%のケースをカバーできる
月5ドルのノードでも10万MAUを余裕でさばける
個人プロジェクト用には完璧なツールに見える
ただ、「エージェント」の部分がもう少しシームレスに統合されるといいと思う
自分のコーディングエージェントがこれをどう扱うのか知る方法はある？
ブログに関連スキルへのリンクを追加するとよさそう
PRリンク
npx skills add instantdb/skillsコマンドで追加できるbunx/pnpx/npx create-instant-appでのプロジェクトスキャフォールディングもおすすめリリースおめでとう！ InstantDBは使った中でいちばん楽しいツールだった
小さなおもちゃプロジェクトでしか試していないけど、この分野では最もシンプルで直感的
ただ、コア製品がかなり良いだけに、AIの強調が少し不自然にも感じられる
最近は資金調達のためにそういうポジショニングが必要なのかなと思ってしまう
2024年8月にオープンソース化して以来、Webサイトは更新していなかった
当時の投稿以降、AIでアプリを作るユーザーが急増した
そのためメッセージングを刷新し、エージェント体験をより楽しくするために投資した
ほとんどのユーザーがAIでコーディングしているので、それに合わせて最適化した
誤解しているのかもしれないけど、なぜ「AI-coded」なのか気になる
シンプルなバックエンドを探している立場からすると素晴らしい選択肢に見えるが
他のバックエンドと比べて何がAI中心なのかがよくわからない
それとTS中心に見えるけど、モバイルネイティブバインディングの計画もあるのか気になる
本当に素晴らしいデモだった。AI連携のアイデアはすばらしいが、説明が足りない
チュートリアルを見たが、SaaSアカウント作成中心だった
Triples、Datalog、ClojureのようなリアクティブアプリのパターンがInstantにはうまく溶け込んでいる
個人的にClojureは難しく、Datalogもなじみが薄かったが、Instantの抽象化はとても歓迎できる
InstantQL-Datalog変換器が別コンポーネントとして提供されたら本当に便利だと思う
バックエンドがClojureベースなのでPostgresを選んでいるのは理解できるが、ローカルデプロイではSQLiteのほうが簡単かもしれない
「リレーショナルクエリ + リアルタイム」を実際に実装した点は印象的
ただ、コンソールUIはインフラやWebサイトほどには手が入っていない感じがする
1.0リリースおめでとう、これからもInstantで作り続けるつもり
ホームページのデモ、エッセイ、ドキュメントをかなり改善した
ダッシュボードは数週間以内にリデザインする予定
興味深いことに、AIエージェントがアプリを作ってスキーマを変更しても
ユーザーはExplorerコンポーネントを使ってデータを直接探索することをより好む
ドキュメントでrate limitingに関する記述が見つからない。存在するのか気になる
Pocketbaseを使ったことがあるが、Instantも似た用途で良さそう
ただPocketbaseはサーバー拡張性が強みだった
JSやGoでフックを書いて、プッシュ通知のような機能を追加できた
InstantDBでもこうしたことが可能なのか、それとも別のワーカーを作る必要があるのか気になる
それとDart SDKの計画もあるのか知りたい
db.subscribeQueryを使って変更に反応できるwebhook機能もまもなく追加予定で、他言語向けSDKも長期的にはサポートする計画
「事前定義されたパターンがトークンコストを下げる」という見方には共感する
自分たちもempla.ioを作るときに似た経験をした
バックエンドの判断をエージェントに任せると、トークン使用量が3〜4倍に増える
宣言的クエリ言語は人間よりもAIに大きな効率をもたらす
気になる点は2つある
バイブコーディングしたものまで宣伝するんですか