Manifest, a new 1-file micro-backend solution, has sparked significant discussion in the developer community about its approach to simplifying backend development. Designed for rapid prototyping, microservices, and CRUD-heavy applications, Manifest aims to deliver essential backend features in a single file that integrates directly into existing codebases. However, the community has raised important questions about its security model, database implementation, and feature limitations.
Security Concerns Highlight Implementation Challenges
Developers examining Manifest have identified several security issues that could pose significant risks for users. One of the most concerning aspects mentioned repeatedly is the default permission system, which automatically grants public access to any action without a specified policy. This spectacular footgun, as one commenter described it, means developers must be extremely careful to explicitly define permissions for every entity and action or risk exposing sensitive data and operations to unauthenticated users.
Another security issue initially identified was the use of SHA-3 for password hashing instead of more appropriate algorithms designed specifically for password storage. While the Manifest team has since updated to bcrypt, this oversight wasn't reflected in their documentation until community members pointed it out, raising questions about the project's security-first approach.
Key Features of Manifest:
- Authentication system
- Data validation
- Storage capabilities
- Image resizing
- Admin panel
- Dynamic endpoints
- REST API
- JavaScript SDK
- Webhooks
Community-Identified Limitations:
- Default permission model (public access unless specified)
- Lack of proper database locking
- No migration tools (currently in development)
- Previously used SHA-3 for password hashing (now updated to bcrypt)
- Complex directory structure despite "1-file" marketing
Similar Solutions Mentioned:
- PocketBase
- PostgREST
- Prisma + PostgREST
Database Implementation Raises Reliability Questions
Technical analysis of Manifest's codebase revealed concerns about its underlying database implementation. One developer noted the absence of proper locking mechanisms, warning that running multiple instances simultaneously could corrupt data. This fundamental architectural issue suggests potential reliability problems for applications with concurrent users or processes.
Looks like it doesn't use locking, so running two instances will corrupt your 'database'... Probably best to stick to sqlite instead!
The lack of migration tools was also highlighted as a significant limitation, though a Manifest developer responded that database synchronization currently handles schema changes with proper migrations planned for future releases.
Comparison to Existing Solutions
Many commenters drew comparisons between Manifest and similar tools like PocketBase, PostgREST, and traditional frameworks. PocketBase emerged as a frequently mentioned alternative that follows a similar simplified backend approach but with a more mature implementation. Several developers shared positive experiences using PocketBase for small projects, suggesting it might currently be a more reliable option for production use.
The Manifest team emphasized their product's differentiator as being fully code-based, allowing developers to stay in their IDE and leverage AI tools like GitHub Copilot or Cursor to build backends. This code-first approach, using a YAML-based DSL, was highlighted as particularly AI-friendly compared to UI-based backend services, though some questioned the necessity of emoji usage in entity declarations.
Project Structure and Developer Experience
Some developers expressed concern about the project's organization, noting that despite being marketed as a 1-file micro-backend, Manifest's GitHub repository contains numerous files and dependencies. One commenter shared their method of evaluating project quality by measuring how deep into the directory hierarchy they needed to go before finding actual implementation code, suggesting Manifest didn't fare well by this metric.
The YAML-based configuration approach received mixed feedback. While some appreciated its simplicity, others questioned design choices like the seemingly mandatory emoji usage in entity declarations, which wasn't explained in the documentation. The Manifest team acknowledged they could improve their documentation around these design decisions.
Despite these concerns, many developers expressed interest in the concept and its potential usefulness for small-scale projects, prototypes, and MVPs. The Manifest team has been actively engaging with feedback, acknowledging issues, and indicating plans for improvements.
As with many beta-stage projects, Manifest presents an interesting approach to simplifying backend development but requires careful consideration of its current limitations before adoption in anything beyond experimental projects. The team's responsiveness to community feedback suggests potential for growth and improvement as the project matures.
Reference: manifest