新しい1ファイルのマイクロバックエンドソリューションである Manifest は、バックエンド開発を簡素化するアプローチについて、開発者コミュニティで大きな議論を巻き起こしています。迅速なプロトタイピング、マイクロサービス、CRUDを多用するアプリケーション向けに設計された Manifest は、既存のコードベースに直接統合される単一ファイルで必要なバックエンド機能を提供することを目指しています。しかし、コミュニティはそのセキュリティモデル、データベース実装、機能の制限について重要な疑問を提起しています。
セキュリティ懸念が実装の課題を浮き彫りに
Manifest を検証した開発者たちは、ユーザーに重大なリスクをもたらす可能性のあるいくつかのセキュリティ問題を特定しました。最も懸念されるのは、指定されたポリシーがない任意のアクションに自動的に公開アクセスを許可するデフォルトの権限システムです。あるコメンターが「見事な落とし穴」と表現したように、これは開発者が各エンティティとアクションに対して明示的に権限を定義しなければ、機密データや操作が認証されていないユーザーに公開されるリスクがあることを意味します。
当初指摘されたもう一つのセキュリティ問題は、パスワード保存専用に設計されたより適切なアルゴリズムの代わりに、SHA-3をパスワードハッシュに使用していたことでした。Manifest チームはその後 bcrypt に更新しましたが、コミュニティメンバーが指摘するまでこの見落としはドキュメントに反映されておらず、プロジェクトのセキュリティ優先アプローチに疑問が投げかけられました。
Manifestの主な機能:
- 認証システム
- データ検証
- ストレージ機能
- 画像リサイズ
- 管理パネル
- 動的エンドポイント
- REST API
- JavaScript SDK
- ウェブフック
コミュニティが指摘した制限事項:
- デフォルトの権限モデル（指定がない限り公開アクセス）
- 適切なデータベースロッキングの欠如
- マイグレーションツールがない（現在開発中）
- 以前はパスワードハッシュにSHA-3を使用（現在は bcrypt に更新）
- 「1ファイル」とマーケティングされているにも関わらず複雑なディレクトリ構造
言及された類似ソリューション:
- PocketBase
- PostgREST
- Prisma + PostgREST
データベース実装が信頼性に関する疑問を提起
Manifest のコードベースの技術分析により、その基盤となるデータベース実装に関する懸念が明らかになりました。ある開発者は、適切なロック機構が欠如していることを指摘し、複数のインスタンスを同時に実行するとデータが破損する可能性があると警告しました。この基本的なアーキテクチャ上の問題は、同時ユーザーやプロセスを持つアプリケーションに潜在的な信頼性の問題があることを示唆しています。
「ロックを使用していないようなので、2つのインスタンスを実行するとあなたの「データベース」が破損するでしょう...おそらく sqlite にとどめておくのが最善です！」
マイグレーションツールの欠如も大きな制限として強調されましたが、Manifest の開発者はデータベース同期が現在スキーマの変更を処理しており、適切なマイグレーションは将来のリリースで計画されていると回答しました。
既存のソリューションとの比較
多くのコメンターが Manifest と PocketBase、PostgREST、従来のフレームワークなどの類似ツールを比較しました。PocketBase は、同様の簡素化されたバックエンドアプローチを採用しているが、より成熟した実装を持つ代替手段として頻繁に言及されました。いくつかの開発者は小規模なプロジェクトで PocketBase を使用した肯定的な経験を共有し、現時点では本番環境での使用にはより信頼性の高いオプションかもしれないと示唆しました。
Manifest チームは、彼らの製品の差別化要因として、開発者が IDE 内に留まり、GitHub Copilot や Cursor などの AI ツールを活用してバックエンドを構築できる完全にコードベースであることを強調しました。この YAML ベースの DSL を使用したコードファーストアプローチは、UI ベースのバックエンドサービスと比較して特に AI フレンドリーであると強調されましたが、一部の人はエンティティ宣言での絵文字の使用の必要性に疑問を呈しました。
プロジェクト構造と開発者エクスペリエンス
一部の開発者は、1ファイルのマイクロバックエンドとして宣伝されているにもかかわらず、Manifest の GitHub リポジトリには多数のファイルと依存関係が含まれているとして、プロジェクトの組織に懸念を表明しました。あるコメンターは、実際の実装コードを見つけるためにディレクトリ階層をどれだけ深く掘り下げる必要があるかを測定することでプロジェクトの品質を評価する方法を共有し、この指標では Manifest はあまり良い評価を得られなかったと示唆しました。
YAML ベースの設定アプローチには賛否両論がありました。一部の人はその単純さを評価する一方で、ドキュメントで説明されていなかったエンティティ宣言での一見必須の絵文字使用などの設計選択に疑問を呈しました。Manifest チームはこれらの設計決定に関するドキュメントを改善できることを認めました。
これらの懸念にもかかわらず、多くの開発者はそのコンセプトと小規模プロジェクト、プロトタイプ、MVP への潜在的な有用性に関心を示しました。Manifest チームはフィードバックに積極的に取り組み、問題を認識し、改善計画を示しています。
多くのベータ段階のプロジェクトと同様に、Manifest はバックエンド開発を簡素化する興味深いアプローチを提示していますが、実験的なプロジェクト以外での採用を検討する前に、現在の制限を慎重に考慮する必要があります。コミュニティのフィードバックに対するチームの対応の良さは、プロジェクトが成熟するにつれて成長と改善の可能性を示唆しています。
参照: manifest