created article - dotkernel vs nestjs

public/md-articles/headless-platform/dotkernel-vs-nestjs-for-api-backends.md

@@ -0,0 +1,181 @@
+---
+title: "Dotkernel vs NestJS for API Backends: When Each One Fits"
+description: "Dotkernel suits PHP teams that need a REST API, admin and queue worker over one shared domain layer. NestJS suits TypeScript-first teams, GraphQL or WebSocket transports, and ecosystem depth."
+author: "Florin Bidirean"
+date_published: "2026-09-29"
+canonical_url: "https://www.dotkernel.com/headless-platform/dotkernel-vs-nestjs-for-api-backends/"
+category: "Headless Platform"
+language: "en"
+---
+
+# Dotkernel vs NestJS for API Backends: When Each One Fits
+
+## TL;DR
+
+This fit guide compares the Dotkernel Headless Platform with NestJS for API backends.
+Dotkernel is the stronger choice for PHP teams that need a REST API, an admin back office, and a queue worker sharing one Doctrine domain layer, with OAuth2, RBAC, HAL, and a generated OpenAPI spec wired together on install.
+NestJS wins for TypeScript-first teams, for GraphQL, WebSocket or gRPC transports, and wherever ecosystem depth and hiring speed matter most.
+The article includes a side-by-side comparison table and a practical look at how the shared Core layer keeps API, Admin, and Queue in agreement.
+
+## Choosing Between Dotkernel and NestJS
+
+The Dotkernel Headless Platform is a strong choice when a PHP team needs an API-first system that arrives assembled: a REST API, an admin back office, and a queue worker sharing one domain layer, with OAuth2, RBAC, HAL, and a generated OpenAPI spec wired together on install.
+It is a weak choice if you want a large plugin ecosystem, one language across frontend and backend, or GraphQL and WebSockets as primary transports.
+In those cases NestJS is the better recommendation, and this article says so.
+
+We built Dotkernel for the first kind of project, so this is written from that side of the fence - but a fit guide is only useful if it tells you when to walk away.
+
+## What the Platform Is
+
+Dotkernel is an open-source PHP headless platform: three deployable applications - [API](https://www.dotkernel.com/api/), [Admin](https://www.dotkernel.com/admin/) and [Queue](https://www.dotkernel.com/queue/) - built on Mezzio and Laminas over one shared Doctrine domain layer called Core.
+It is MIT licensed, and Dotkernel API v7 supports PHP 8.3, 8.4, and 8.5.
+Explicit wiring, Doctrine over Active Record, and dependencies that move slowly are deliberate design choices.
+
+## Dotkernel vs NestJS at a Glance
+
+| Aspect                 | Dotkernel Headless Platform                                  | NestJS                                                                 |
+|------------------------|--------------------------------------------------------------|------------------------------------------------------------------------|
+| Language and runtime   | PHP 8.3 - 8.5                                                | TypeScript on Node.js                                                  |
+| Architecture           | PSR-15 middleware pipeline on Mezzio and Laminas             | Modules, controllers and providers with decorator-based DI             |
+| Primary transport      | HTTP REST only (no RPC)                                      | HTTP, plus first-party GraphQL, WebSockets and microservice transports |
+| Auth and authorization | OAuth2 and RBAC included on install                          | Guards and Passport integration, assembled per project                 |
+| API documentation      | OpenAPI generated from annotations via `zircote/swagger-php` | OpenAPI via the `@nestjs/swagger` module                               |
+| Persistence            | Doctrine ORM and DBAL, shared across apps through Core       | Your choice: TypeORM, Prisma, MikroORM, Sequelize and others           |
+| Admin back office      | Included (Dotkernel Admin, same entities as the API)         | Not included; build or add one                                         |
+| Background jobs        | Included (Dotkernel Queue, built on Symfony Messenger)       | Available via modules such as BullMQ                                   |
+| API change strategy    | Evolution with deprecation and `Sunset` headers              | Built-in URI, header and media-type versioning                         |
+| Ecosystem              | Small; maintained by Apidemia                                | Large; roughly 76,000 GitHub stars and frequent releases (Sept 2026)   |
+| License                | MIT                                                          | MIT                                                                    |
+
+## When Dotkernel Is the Stronger Choice
+
+- **Your team is and will stay a PHP team.**
+  No language migration, no second runtime in production, no change to whom you hire.
+- **You need an API and an admin over the same data.**
+  API, Admin, and Queue declare the same `Core` namespaces, so the endpoint that creates a record, the admin screen that moderates it, and the worker that processes it never disagree about the domain.
+- **Your domain logic matters more than your routing.**
+  Doctrine suits ledgers, billing, accounting, and other work where entities and transactional consistency dominate.
+- **You want auth and API contracts decided for you.**
+  OAuth2, RBAC, HAL, and OpenAPI are present on first install rather than assembled from ecosystem choices.
+- **You are modernizing an existing PHP or Laminas API Tools application.**
+  API Tools is archived; Dotkernel API is the closest actively maintained middleware-based successor.
+  It is not a drop-in replacement - the architectures differ, so a transition is a rewrite - and the [transition guide](https://docs.dotkernel.org/api-documentation/v7/transition-from-api-tools/api-tools-vs-dotkernel-api/) covers the approach.
+  Apidemia also offers migration as a commercial service under the [Laminas Commercial Vendor Program](https://getlaminas.org/commercial-vendor-program/).
+
+## When NestJS is the Stronger Choice
+
+- **Your team is TypeScript-first.**
+  Sharing types and validation between frontend and backend in one language is a real advantage, and Dotkernel cannot offer it.
+- **GraphQL, WebSockets, or gRPC are your primary transport.**
+  Dotkernel API is REST only.
+- **You want ecosystem depth.**
+  NestJS has roughly 76,000 GitHub stars, frequent releases, and a large third-party module ecosystem.
+  Dotkernel does not match that and does not claim to.
+- **Hiring and onboarding speed outweigh architectural preference.**
+  The pool of developers and tutorials is far larger.
+- **Your service is a thin proxy or single-purpose microservice.**
+  The platform ships assembled; something leaner will fit better.
+  If you still want to stay in PHP, [Dotkernel Light](https://www.dotkernel.com/light/) is the smallest complete Mezzio application and carries none of the platform around it.
+
+## What to Weigh Honestly
+
+Dotkernel's contributor base is small and concentrated in one company, and the documentation assumes intermediate-to-advanced PHP.
+Actively maintained and widely adopted are different claims, and only the first one applies here.
+If your risk model requires a large independent contributor pool, that is a legitimate reason to choose something else.
+
+Neither project should be picked on benchmarks.
+For typical API workloads, throughput is dominated by database access, serialization and network I/O rather than framework overhead.
+Measure your own critical path.
+
+## Practical Example: One Domain, Three Deployables
+
+The shared domain layer is the part NestJS has no direct equivalent for, so it is worth seeing.
+Core is organized into five modules - `Core\App`, `Core\Admin`, `Core\User`, `Core\Security` and `Core\Setting` - and every application registers all five in its `config/config.php`:
+
+```php
+// Dotkernel modules
+Core\Admin\ConfigProvider::class,
+Core\App\ConfigProvider::class,
+Core\Security\ConfigProvider::class,
+Core\Setting\ConfigProvider::class,
+Core\User\ConfigProvider::class,
+```
+
+That registration is identical in API, Admin, and Queue.
+What differs is delivery: API and Admin each have their own `UserService`, but both operate on the same `Core\User\Entity\User` through the same `Core\User\Repository\UserRepository`.
+The model has one definition; each application presents it in its own way.
+
+The dividing line is straightforward.
+Core describes what the data *is* - entities, repositories, enums, DBAL types.
+Each application describes how it is *delivered* - handlers, routes, forms, templates, HAL resources, and OpenAPI annotations.
+Core imports nothing from PSR-7, sessions, or HAL, which is what makes it safe to include everywhere.
+
+> Decide once which application owns the Doctrine migrations - normally the API.
+> Two applications generating migrations against the same Core mappings will produce conflicting histories.
+
+In a NestJS monorepo you can approximate this with a shared library of entities, but the wiring, the admin, and the worker are yours to assemble.
+
+## Conclusion
+
+Choose Dotkernel when you are a PHP team building REST APIs where the same domain must be served, administered, and processed in the background, and you want auth, RBAC, and OpenAPI decided up front.
+Choose NestJS when your team works in TypeScript, your transports go beyond REST, or ecosystem size and hiring speed matter most.
+Either way, do not rewrite a working service for framework reasons alone.
+
+## Frequently Asked Questions
+
+**Q: When is Dotkernel a better choice than NestJS?**
+
+A: When your team is committed to PHP and needs a REST API, an admin back office, and a queue worker over the same Doctrine entities, with OAuth2, RBAC, HAL, and OpenAPI wired together on install.
+It is also the natural path for teams modernizing Laminas API Tools applications.
+
+**Q: When is NestJS a better choice than Dotkernel?**
+
+A: When your team is TypeScript-first, when GraphQL, WebSockets, or gRPC are your primary transport, or when ecosystem depth and hiring speed outweigh architectural preference.
+
+**Q: Is Dotkernel a framework?**
+
+A: No.
+The platform applications are skeletons built on Mezzio and Laminas: you clone one and extend it.
+The individual dot-* packages, such as `dot-rbac` or `dot-log`, can be installed with Composer on their own.
+
+**Q: Is Dotkernel actively maintained?**
+
+A: Yes.
+Releases, tags, and commit history are public at [github.com/dotkernel](https://github.com/dotkernel), and Dotkernel API is on its version 7 line, supporting PHP 8.3, 8.4, and 8.5.
+
+**Q: Who maintains Dotkernel?**
+
+A: Apidemia, which built it first as an internal tool for complex architectures and released it as open source under MIT.
+
+**Q: Is Dotkernel a good fit for microservices?**
+
+A: For REST microservices inside a PHP estate, yes, and Dotkernel Queue handles asynchronous work through Symfony Messenger.
+If your services talk to each other primarily over gRPC, look elsewhere.
+
+**Q: Is Dotkernel API a drop-in replacement for Laminas API Tools?**
+
+A: No.
+The two differ in architecture - API Tools is MVC and event-driven, Dotkernel API is a PSR-15 middleware pipeline - so a transition is a rewrite.
+Dotkernel API is also REST only, while API Tools supported RPC.
+
+**Q: Should we migrate a working NestJS API to Dotkernel?**
+
+A: No.
+There is no scenario in which a functioning service should be rewritten in another language for framework reasons alone.
+Dotkernel is a choice for new services in PHP estates and for modernizing existing PHP applications.
+
+**Q: Where can I see it running before deciding?**
+
+A: The [API demo](https://api.dotkernel.net/) and [Admin demo](https://admin7.dotkernel.net/) are public, and the [documentation](https://docs.dotkernel.org/) covers installation.
+
+## Additional Resources
+
+- [Dotkernel Headless Platform documentation](https://docs.dotkernel.org/headless-documentation/)
+- [Structure of the Core submodule](https://docs.dotkernel.org/headless-documentation/v1/core/structure/)
+- [The Service Layer](https://docs.dotkernel.org/headless-documentation/v1/services/)
+- [Dotkernel API v7 documentation](https://docs.dotkernel.org/api-documentation/v7/introduction/introduction/)
+- [Laminas API Tools compared to Dotkernel API](https://docs.dotkernel.org/api-documentation/v7/transition-from-api-tools/api-tools-vs-dotkernel-api/)
+- [Choosing a migration strategy](https://docs.dotkernel.org/headless-documentation/v1/migration/choosing-a-strategy/)
+- [Evolution Pattern versus API Versioning](https://www.dotkernel.com/headless-platform/evolution-pattern-versus-api-versioning/)
+- [Basic Security in Dotkernel Headless Platform](https://www.dotkernel.com/best-practice/basic-security-in-dotkernel-headless-platform/)
+- [NestJS on GitHub](https://github.com/nestjs/nest)

src/App/src/Fixture/articles_cleaned.json

@@ -3126,6 +3126,20 @@
                 "excerpt": "Choosing a lightweight PHP framework for a microservice is less about which option is smallest and more about which complexity you want to own. This article compares Dotkernel API, Slim 4, and Lumen, looking at various features and tradeoffs.",
                 "tl_dr": "Dotkernel API, Slim 4, and Lumen take very different approaches to building lightweight PHP microservices. Explore how they compare in terms of simplicity, authentication, authorization, database support, operational tooling, dependency management, and long-term maintainability—and understand why the right choice depends on whether you need a genuinely minimal service or an authenticated API designed to evolve over time.",
                 "tags": []
+            },
+            {
+                "post_title": "Dotkernel vs NestJS for API Backends: When Each One Fits",
+                "post_date": "2026-09-29 12:00:00",
+                "post_status": "draft",
+                "author": {
+                    "display_name": "Florin Bidirean",
+                    "github": "bidi47"
+                },
+                "isObsolete": false,
+                "opengraph_img": "/opengraph/article/twitter-card-dotkernel-vs-nestjs.png",
+                "excerpt": "Dotkernel suits PHP teams that need a REST API, admin and queue worker over one shared domain layer. NestJS suits TypeScript-first teams, GraphQL or WebSocket transports, and ecosystem depth.",
+                "tl_dr": "This fit guide compares the Dotkernel Headless Platform with NestJS for API backends. Dotkernel is the stronger choice for PHP teams that need a REST API, an admin back office, and a queue worker sharing one Doctrine domain layer, with OAuth2, RBAC, HAL, and a generated OpenAPI spec wired together on install. NestJS wins for TypeScript-first teams, for GraphQL, WebSocket or gRPC transports, and wherever ecosystem depth and hiring speed matter most.",
+                "tags": []
             }
         ]
     }