Symfony Laravel Package

Technical Evaluation

Architecture Fit

• ORM Integration: Atlas is a data mapper (not a full domain model layer), making it a viable alternative to Doctrine for projects where:
  • Simplicity is prioritized over advanced ORM features (e.g., DQL, complex inheritance).
  • Code generation (skeleton-based mappers) aligns with teams preferring explicit, hand-written data access layers.
  • Lightweight persistence is needed (Atlas avoids Doctrine’s abstraction overhead).
• Symfony Compatibility: Designed as a Symfony 4 bundle, leveraging:
  • Dependency Injection (DI) for Atlas service autowiring.
  • Flex recipes for streamlined installation.
  • Environment variables (ATLAS_PDO_*) for config management.
• Trade-offs:
  • No Doctrine-level features: Missing DQL, second-level cache, or advanced event system.
  • Codegen dependency: Requires manual atlas:skeleton updates for schema changes (vs. Doctrine’s metadata-driven approach).

Integration Feasibility

• Low Friction for Greenfield Projects:
  • Works seamlessly with Symfony’s DI container and Flex.
  • Minimal boilerplate (e.g., atlas.yaml config, .env vars).
• Legacy Migration Challenges:
  • Doctrine → Atlas: Requires rewriting:
    • Entities → Atlas mappers (codegen vs. annotations).
    • Repositories → Atlas service methods.
    • Queries → Atlas-specific syntax (e.g., fetchRecord() vs. find()).
  • Database Schema: Atlas expects singular table names by default (configurable via atlas.cli.transform).
• Tooling Gaps:
  • No migration tools (e.g., Doctrine Migrations) for schema changes.
  • No IDE support beyond basic PHPStorm meta files (vs. Doctrine’s metadata drivers).

Technical Risk

• Stability:
  • Last release: 2018 (3+ years stale). Risk of:
    • PHP 8.x incompatibility (Atlas 3.x targets PHP 7.1–7.3).
    • Symfony 6/7 deprecations (e.g., Flex recipes, DI changes).
  • No active maintenance: Dependents = 0; no community support.
• Performance:
  • No benchmarks vs. Doctrine/Eloquent. Potential overhead from:
    • Codegen-generated mappers (reflection vs. compiled proxies).
    • Transaction handling (Atlas uses AutoTransact by default).
• Security:
  • PDO options (e.g., EMULATE_PREPARES) must be manually configured to avoid SQL injection risks.
  • No built-in query logging by default (requires log_queries: true + Profiler).

Key Questions

1. Why Atlas over Doctrine/Eloquent?
   • Is simplicity/codegen a hard requirement? If not, Doctrine’s maturity may outweigh Atlas’s risks.
   • Does the team prefer explicit mappers over ORM-generated entities?
2. Migration Path
   • For existing Symfony apps, what’s the cost of rewriting data access layers?
   • Are there critical Doctrine features (e.g., events, caching) that Atlas cannot replace?
3. Long-Term Viability
   • Can the team maintain Atlas compatibility if upstream stops updating?
   • Are there alternatives (e.g., CycleORM, Eloquent) with better Symfony integration?
4. Schema Management
   • How will database migrations be handled? (Atlas lacks built-in tools.)
   • Is the team comfortable with manual atlas:skeleton updates for schema changes?
5. Performance/Scaling
   • Has Atlas been benchmarked against Doctrine in production?
   • Are there known bottlenecks (e.g., transaction handling, query building)?

Integration Approach

Stack Fit

• Best For:
  • Symfony 4/5 projects needing a lightweight ORM with codegen.
  • Teams using Atlas 3.x (e.g., existing Atlas CLI users).
  • Applications where data access is simple (CRUD-heavy, no complex queries).
• Poor Fit:
  • Projects requiring advanced ORM features (DQL, caching, events).
  • Teams using PHP 8.x (risk of compatibility issues).
  • Applications with highly dynamic schemas (Atlas’s codegen may be cumbersome).

Migration Path

Compatibility

• Symfony 4/5: Fully supported (Flex recipes, DI integration).
• PHP 7.1–7.3: Confirmed (risk with PHP 8.x).
• Databases: Supports any PDO-compatible DB (MySQL, PostgreSQL, SQLite).
• Tooling:
  • No Symfony Profiler integration by default (requires log_queries: true).
  • No migration tools (use Doctrine Migrations or custom scripts).
  • No PHP 8 attributes (Atlas uses annotations/codegen).

Sequencing

1. Pilot Phase:
   • Integrate Atlas for non-critical modules first.
   • Compare performance/memory usage with Doctrine.
2. Incremental Replacement:
   • Start with read-heavy services (e.g., fetchRecord()).
   • Gradually replace write operations (transactions, events).
3. Fallback Plan:
   • Maintain dual Doctrine/Atlas support during migration.
   • Use feature flags to toggle between ORMs.

Operational Impact

Maintenance

• Pros:
  • Simple config: Most settings live in atlas.yaml and .env.
  • Explicit mappers: Easier to debug than ORM-generated code.
• Cons:
  • Manual updates: Schema changes require atlas:skeleton + manual fixes.
  • No migrations: Database changes must be scripted externally.
  • Stale package: No guarantees for future Symfony/PHP updates.

Support

• Community:
  • No active maintainers (last release 2018, 0 dependents).
  • Documentation: Atlas 3.x docs are outdated (e.g., no PHP 8 examples).
• Debugging:
  • Query logging: Requires manual log_queries: true + Profiler.
  • No stack traces: Atlas errors may lack context (e.g., no entity names).
• Vendor Lock-in:
  • Atlas-specific syntax (e.g., fetchRecord()) may complicate future ORM swaps.

Scaling

• Performance:
  • No benchmarks: Unknown overhead vs. Doctrine/Eloquent.
  • Transactions: AutoTransact may not scale for high-concurrency apps.
  • Memory: Codegen mappers use reflection (vs. Doctrine’s compiled proxies).
• Concurrency:
  • No connection pooling by default (relies on PDO).
  • No read replicas: Atlas lacks built-in support for multi-DB setups.
• Horizontal Scaling:
  • Stateless: Works well in distributed environments (no ORM-specific caching).

Failure Modes