Philosophy and Scope
Mirror ORM doesn’t try to be a “Swiss Army knife” that does everything poorly. It was designed to be an extremely lean data reflection engine. To keep overhead to 39ns/row, we made deliberate decisions not to implement certain common features in “heavy” ORMs.
What Mirror is NOT (and why)
Section titled “What Mirror is NOT (and why)”| Functionality | Status | Why? |
|---|---|---|
| Migrations | Out of scope | DDL is an infrastructure responsibility. We recommend specialized tools like dbmate, Umzug or pure SQL. |
| Validation | Out of scope | Validating business rules in the mapping degrades performance. Use class-validator in Lifecycle Hooks for decoupled validation. |
| Lazy Loading | Not supported | Lazy loading via Proxies hides asynchronous queries and causes the silent N+1 problem. In Mirror, loading is always explicit. |
| Entity Manager | Not supported | We avoid the “God Object” that tracks everything. Mirror is stateless by default, ensuring predictability and low memory consumption. |
| CLI | Not supported | Mirror is a runtime library. There is no code generation or terminal tools included in the core. |
Mirror Pillars
-
Explicit over Implicit: You always know when a query is being executed. No surprises in property getters.
-
Stateless Efficiency: We use Snapshotting instead of Proxies for Dirty Checking. This keeps the speed of accessing class properties identical to that of a native object.
-
JIT Hydration: In bootstrap, we compile a specific hydrator for each of your entities. V8 optimizes this code, eliminating generic loops when reading thousands of lines.
When to use Mirror?
-
If you need the performance of Raw SQL, but want the type safety of TypeScript.
-
If your environment (Serverless/Edge) requires an instant Cold Start.
-
If you want full control over what your ORM is sending to the database.