Introduction
Teams on MySQL often face the same request: “Can we get a REST API over this data for the mobile app / partner / new dashboard?” The database is sound. The schema is known. But hand-rolling CRUD endpoints, auth, and documentation for dozens of tables is weeks of work that adds little strategic value.
DreamFactory is one answer to that problem. In plain terms, it is a platform that generates APIs from existing databases — including MySQL — so you can expose data and operations without writing every route yourself. Think of the mental model many developers use for PostgREST on PostgreSQL, applied to a commercial product that also bundles auth, keys, and admin tooling.
What DreamFactory actually does
DreamFactory connects to your MySQL instance (and other sources), introspects schema, and produces REST endpoints for tables and relationships you choose to expose. Typical capabilities include:
- Auto-generated REST for CRUD and related records
- Authentication and role-based access so not every client sees every table
- API keys and usage controls for partners and internal apps
- Optional server-side scripts when generated behaviour is not quite enough
The pitch is speed: integrate mobile, web, or automation clients in days rather than sprints of boilerplate.
When generated REST is enough
Auto-generated APIs shine when:
- The workload is mostly read-heavy or straightforward CRUD
- Business rules are simple or can live in the database (constraints, views)
- You need a stable HTTP surface quickly for a pilot or internal tool
- An AI agent or MCP server needs predictable HTTP tools over legacy MySQL
They are a poor primary choice when:
- Every request needs complex orchestration across many systems
- Domain logic must stay in application code you test and version carefully
- You already centre the product on a headless CMS or custom service layer (for example Directus plus Prisma, which we often ship for Enamic clients)
In practice, many organisations use DreamFactory as a bridge: expose legacy MySQL safely while a longer-term service extraction proceeds.
Security and agents
If you connect an AI agent to generated APIs, the same discipline applies as for any MCP integration:
- Least privilege: expose views or tables, not the whole instance
- Separate credentials per agent or integration, with audit trails
- No destructive tools unless a human approves them
- Validation on anything that is not pure read
DreamFactory does not remove the need for threat modelling. It compresses the time to a reviewable HTTP surface so you can focus on what is exposed, not on wiring Express routes for the hundredth time.
DreamFactory vs bespoke backends
| Concern | Generated REST (DreamFactory) | Bespoke API (Node, Directus, etc.) |
|---|---|---|
| Time to first endpoint | Very fast | Slower |
| Complex workflows | Scripts or external services | Native in code |
| Versioning and tests | Platform-dependent | Your CI/CD norms |
| Fit for MCP tool menus | Good for table-centric tools | Good for domain verbs (“closeTicket”) |
We often build custom backends when the product is the API — when rules, caching, and multi-step flows are the differentiator. We point teams at generators like DreamFactory when the goal is access, not novelty, especially over mature MySQL estates.
Bottom line
DreamFactory is not a replacement for thoughtful architecture. It is a accelerator for a common pattern: MySQL already holds the truth, and multiple clients need HTTP access now. Pair it with tight permissions and clear boundaries, and it can feed mobile apps, partner integrations, and agent toolchains without a month of CRUD endpoints.
If you are weighing generated REST against a custom layer for MySQL, talk to us at enamic.io. We will help you decide what should be generated, what should be hand-built, and how MCP fits either path.