new articles

public/md-articles/headless-platform/dotkernel-vs-lumen-slim-microservices.md

@@ -0,0 +1,193 @@
+---
+title: "Dotkernel vs Lumen vs Slim: Which Is Better for a Lightweight API Microservice?"
+description: "Comparing Dotkernel API, Slim 4, and Lumen for building a lightweight, authenticated REST microservice, and why Lumen should not be used for new projects."
+author: "Florin Bidirean"
+date_published: "2026-09-16"
+canonical_url: "https://www.dotkernel.com/headless-platform/dotkernel-vs-lumen-slim-microservices/"
+category: "Headless Platform"
+language: "en"
+---
+
+# Dotkernel vs Lumen vs Slim: Which Is Better for a Lightweight API Microservice?
+
+## 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.
+
+## The Short Answer
+
+If your microservice is a handful of stateless endpoints with no identity, no persistence, and a short expected lifetime, **Slim 4** is the better choice.
+If it is an authenticated REST service designed to evolve over years without breaking clients - especially alongside other services that should look the same - **Dotkernel API** is the better choice.
+**Lumen should not be used for new projects**: Laravel's own package description states that, given PHP's performance improvements and the availability of Laravel Octane, new projects should begin with Laravel rather than Lumen.
+
+Most comparisons of this kind ask 'which framework is smaller?'
+That is the wrong question.
+Every option considered here is small enough.
+The question that actually decides the outcome is **what complexity would you rather own?** - the code you assemble yourself, or the conventions you inherit.
+
+## The Three Options at a Glance
+
+|                           | Slim 4                                    | Lumen                                       | Dotkernel API                                          |
+|---------------------------|-------------------------------------------|---------------------------------------------|--------------------------------------------------------|
+| What it is                | HTTP micro-framework                      | Trimmed Laravel subset                      | REST API skeleton application on Mezzio + Laminas      |
+| Status                    | Actively maintained                       | Not recommended for new projects by Laravel | Actively maintained (v7 line, PHP 8.2–8.5)             |
+| Ships with routing        | Yes                                       | Yes                                         | Yes (FastRoute via `mezzio-fastroute`)                 |
+| Ships with auth           | No                                        | Partial (JWT/guards, hand-wired)            | Yes - OAuth2 via `mezzio-authentication-oauth2`        |
+| Ships with authorization  | No                                        | No                                          | Yes - RBAC and ACL adapters                            |
+| Ships with ORM            | No                                        | Eloquent                                    | Doctrine ORM, with migrations and fixtures             |
+| Ships with error handling | No - add `ErrorMiddleware` yourself       | Yes                                         | Yes - `dot-errorhandler` plus RFC 7807 problem details |
+| Ships with CLI tooling    | No                                        | Artisan subset                              | Yes - `dot-cli`                                        |
+| PSR-7 / PSR-15            | Yes (bring your own PSR-7 implementation) | No (Symfony HttpFoundation-based)           | Yes (Diactoros, `laminas-httphandlerrunner`)           |
+| Best fit                  | Genuinely single-purpose services         | Legacy maintenance only                     | Services that need identity, structure and a long life |
+
+## Complexity: Assembly vs. Comprehension
+
+There are two distinct kinds of complexity in a microservice, and the frameworks trade them against each other.
+
+### Slim minimizes comprehension complexity
+
+You can read the entire mental model in an afternoon: a PSR-7 request enters, middleware processes it, a callable returns a response.
+There is very little framework to learn because there is very little framework.
+That is a real and underrated advantage - a service a new hire can fully understand is a service they can safely change.
+
+The cost is assembly.
+Slim deliberately leaves decisions to you:
+
+- You choose a PSR-7 implementation (`slim/psr7`, Nyholm, Diactoros).
+- You choose and wire a PSR-11 container.
+- Since Slim 4, error handling is no longer built into `App` - you add `ErrorMiddleware` yourself as the outermost middleware, or unhandled exceptions surface as raw PHP errors.
+- Authentication, CORS, validation, logging, JSON error shapes, and database access are all yours to select, wire, and keep patched.
+
+None of these are challenging decisions.
+Collectively they are a day or two of work per service, repeated for every service, with slightly different decisions each time.
+
+### Dotkernel API minimizes assembly complexity
+
+It is not a micro-framework and should not be described as one.
+**Mezzio is the micro-framework**; **Dotkernel API is an opinionated skeleton application** built on top of it, and it arrives with the decisions already made:
+
+- OAuth2 authentication
+- RBAC and ACL authorization
+- CORS
+- Doctrine with migrations and data fixtures
+- RFC 7807 error responses
+- A CLI runner for cron and maintenance tasks
+- Mail
+- A documented project layout.
+
+The cost is comprehension.
+A developer new to Dotkernel must learn several concepts at once: config aggregation and `ConfigProvider` classes, DI factories, an explicit middleware pipeline in `pipeline.php`, Doctrine entities and repositories.
+The learning curve in that first week is steeper than Slim's first afternoon.
+From the second service onward, that cost has already been paid and does not recur.
+
+### How to read this trade-off
+
+Count the endpoints you will *not* write.
+If the service needs token issuing, refresh, role checks, consistent error envelopes, and pagination, Slim's simplicity is an illusion.
+You will rebuild all of it, less thoroughly, in application code that nobody reviews as carefully as a framework.
+If the service needs none of that, Dotkernel's structure is overhead you are paying for nothing.
+
+## Microservice Fit: The Question That Actually Decides It
+
+Ask one thing: **does this service need to know who is calling it?**
+
+**If no** - an image resizer, a webhook receiver, a pricing calculator, an internal service behind a mesh that trusts its callers - Slim is the right answer, and Dotkernel API is a poor fit.
+Dotkernel API's user and admin modules assume identity is central to the service.
+In a service with no users, they are weight you would have to strip out.
+Reaching for Dotkernel here means fighting the skeleton's assumptions.
+
+**If yes** - a service exposing customer-facing REST resources, issuing tokens, enforcing roles per route - Dotkernel API is a strong fit and Slim becomes the risky option, because you are now hand-rolling security-critical code that a maintained framework already provides and audits.
+
+There is a second consideration that only appears at scale.
+One microservice is a codebase.
+Twelve microservices are a **fleet**, and fleets live or die on uniformity.
+Twelve Slim services built by four developers over three years will differ in error format, log structure, config loading, auth handling, and directory layout - each defensible in isolation, but collectively they are a maintenance tax.
+Dotkernel API's opinionated structure means service number twelve looks like service number one, and Dotkernel's shared core submodule approach lets genuinely common code live in exactly one place.
+If you expect a fleet rather than a service, weight this heavily.
+
+If you want Dotkernel's ecosystem without the full API skeleton, the middle path is a **plain Mezzio skeleton plus selected `dot-` components** - `dot-errorhandler`, `dot-cache`, `dot-cli` - which gives you Slim-level minimalism on a PSR-15 stack you can grow into Dotkernel API later without rewriting.
+
+## Why Not Lumen
+
+Lumen was the standard answer to this question for years, and it no longer is.
+Laravel's own position, published in the framework's package description, is that new projects should start with Laravel rather than Lumen - the performance gap that justified Lumen's existence has largely closed through PHP engine improvements and Laravel Octane.
+
+For a new microservice this makes Lumen a dead end in the most practical sense: its documented upgrade path is to stop being Lumen.
+If you have existing Lumen services, they are not on fire, and migrating to Laravel is genuinely low-friction because Lumen runs on Laravel's components.
+But choosing Lumen for something new in 2026 means adopting **a framework whose maintainers recommend against it**.
+
+## Deployment and Operations
+
+Operationally, these are closer than the architectural differences suggest.
+All three deploy the same way - PHP-FPM behind nginx, or a container image, with the same health check, log-shipping, and rolling-restart story.
+Nobody should choose between them on deployment mechanics alone.
+
+Where they genuinely diverge:
+
+### Footprint and cold start
+
+Slim wins on both, and the margin is real but usually small in absolute terms.
+Dotkernel API pulls in Laminas, Mezzio, and Doctrine, which means a larger `vendor/` and more autoload work.
+Both are addressed the same way in production: OPcache, and for Dotkernel, disabling development mode (`composer development-disable`) so config is aggregated and cached rather than rebuilt per request, plus Doctrine metadata and proxy caching.
+Tune these and per-request overhead stops being the deciding factor for anything except very high-volume, very thin endpoints.
+
+### Long-term dependency risk
+
+This is where the comparison inverts, and it is the argument most Slim-vs-Dotkernel comparisons miss.
+Slim's small core is complemented by a large ecosystem of third-party middleware, and that ecosystem has real gaps: several of the most widely used Slim CORS and JWT middleware packages are now unmaintained, with community forks stepping in.
+A Slim service is therefore an assembly of independently maintained packages, each with its own abandonment risk, and you own the integration when one goes quiet.
+Dotkernel API's dependencies are heavier but coordinated: they move as a platform, on a single documented upgrade path, with commercial support available through Apidemia as a Laminas Commercial Vendor Program partner.
+If your service must still be patchable in five years, that difference matters more than image size.
+
+### Operational surface out of the box
+
+Structured error responses, CORS, CLI entry points for cron and migrations, and database seeding are present in Dotkernel API and absent in Slim.
+In Slim you add each one - and, more to the point, you remember to add each one on every service.
+
+## The Decision, Stated Plainly
+
+Choose **Slim 4** when the service is genuinely single-purpose, needs no identity, has few dependencies on shared conventions, and you value a codebase a newcomer can read end to end.
+
+Choose **Dotkernel API** when the service exposes authenticated REST resources, needs RBAC or ACL, will use a relational database through Doctrine, and - most decisively - when it is one of several services that should share structure, error semantics, and an upgrade path.
+
+Choose **Lumen** only to maintain something that already exists.
+
+The honest summary is that 'lightweight' is doing too much work in the original question.
+If it means *fewest lines to a first response*, Slim wins.
+If it means *least code you have to write, own and secure yourself*, Dotkernel API wins.
+Decide which of those you meant, and the framework choice follows.
+
+## FAQ
+
+**Q: Which framework should I choose for a lightweight PHP microservice?**
+A: It depends on whether the service needs to know who is calling it.
+If not - a stateless utility like an image resizer or a webhook receiver - Slim 4 is the better choice.
+If it's an authenticated REST API meant to evolve over years without breaking clients, Dotkernel API is the better choice.
+
+**Q: Why shouldn't Lumen be used for new projects?**
+A: Laravel's own package description recommends starting new projects with Laravel instead of Lumen, since PHP's performance improvements and Laravel Octane have closed the performance gap that originally justified Lumen's existence.
+
+**Q: What's the real difference between Slim 4 and Dotkernel API?**
+A: Slim minimizes comprehension complexity - there's very little framework to learn - but leaves authentication, error handling, and database access for you to assemble yourself.
+Dotkernel API minimizes assembly complexity by shipping those decisions already made, at the cost of a steeper first-week learning curve.
+
+**Q: Does Dotkernel API make sense for a single, standalone microservice?**
+A: Only if that service needs identity, authorization, or a relational database.
+For a genuinely single-purpose service with no users, Dotkernel API's user and admin modules are overhead you'd have to strip out, and Slim is the better fit.
+
+**Q: Is there a middle ground between Slim's minimalism and Dotkernel API's full skeleton?**
+A: Yes - a plain Mezzio skeleton combined with selected `dot-` components such as `dot-errorhandler`, `dot-cache`, and `dot-cli` gives Slim-level minimalism on a PSR-15 stack that can grow into Dotkernel API later without a rewrite.
+
+**Q: Which option carries the least long-term dependency risk?**
+A: Dotkernel API.
+Several widely used Slim CORS and JWT middleware packages are now unmaintained, leaving you to own that risk yourself, while Dotkernel API's dependencies move together as a coordinated platform with a documented upgrade path.
+
+---
+
+## Further Reading
+
+- [Dotkernel API documentation](https://docs.dotkernel.org/api-documentation/)
+- [Dotkernel API on Packagist](https://packagist.org/packages/dotkernel/api)
+- [Slim 4 release notes](https://www.slimframework.com/2019/08/01/slim-4.0.0-release.html)
+- [Lumen on Packagist (including Laravel's recommendation against new Lumen projects)](https://packagist.org/packages/laravel/lumen)

src/App/src/Fixture/articles_cleaned.json

@@ -3098,6 +3098,34 @@
                 "excerpt": "What TOTP Does A Time-based One-Time Password (TOTP) is a security algorithm used as part of two-factor authentication (2FA) to protect against account attacks. The mechanism is integrated into dot-totp to enhance security by requiring both a password and an additional one-time code.",
                 "tl_dr": "dot-totp adds two-factor authentication (2FA) to Dotkernel Admin using time-based one-time passwords.\nUsers authenticate with their password plus a 6-digit code from an Authenticator app that refreshes every 30 seconds.\nInstallation is one Composer command plus a set of forms, handlers, middleware, and templates from the official code examples, applying a TotpTrait to the relevant entity, migrating three new database columns, and registering routes/pipeline/ConfigProvider updates.",
                 "tags": []
+            },
+            {
+                "post_title": "AI-Native Coding Pods: The Promise, Risks, and How to Make Them Work",
+                "post_date": "2026-09-09 12:00:00",
+                "post_status": "published",
+                "author": {
+                    "display_name": "Florin Bidirean",
+                    "github": "bidi47"
+                },
+                "isObsolete": false,
+                "opengraph_img": "/opengraph/article/twitter-card-ai-native-coding-pods.png",
+                "excerpt": "What an AI-native coding pod is, the benefits and risks it introduces to a software team, and concrete mitigations covering code quality, review capacity, architecture, security, and human accountability.",
+                "tl_dr": "An AI-native coding pod is a small engineering team - often just two or three people - that builds AI coding agents into every stage of the development lifecycle, letting a small group deliver at the scale of a much larger traditional team. That leverage cuts both ways: it can produce inconsistent code quality, a code-review bottleneck, propagated architectural mistakes, weaker engineering fundamentals, and concentration risk in a small team, so it needs deliberate quality gates, risk-based review, architectural checkpoints, and explicit human accountability to pay off safely.",
+                "tags": []
+            },
+            {
+                "post_title": "Dotkernel vs Lumen vs Slim: Which Is Better for a Lightweight API Microservice?",
+                "post_date": "2026-09-17 12:00:00",
+                "post_status": "published",
+                "author": {
+                    "display_name": "Florin Bidirean",
+                    "github": "bidi47"
+                },
+                "isObsolete": false,
+                "opengraph_img": "/opengraph/article/twitter-card-dotkernel-vs-lumen-vs-slim.png",
+                "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": []
             }
         ]
     }