DEV Community: David Evdoshchenko

I Stopped Following API Validation Best Practices. Here's Why.

David Evdoshchenko — Fri, 12 Jun 2026 16:14:33 +0000

For years, I followed what most Symfony developers would call best practices. A new API endpoint appeared in the backlog, and the process was always the same:

Design the domain model
Create DTOs
Add validation constraints
Connect everything together

It looked clean and professional. It looked exactly like the examples I saw in conference talks, blog posts, and framework documentation.

And it almost never survived contact with reality.

Not because Symfony was wrong, not because DTOs were bad, but because the projects I worked on had one thing in common: the business didn't actually know its data model yet.

The Assumption Behind Most API Design

Most API examples start with a stable domain:

a customer has a name.
an order has a status.
a product has a price.

From there, everything makes sense. You build entities and DTOs. Then attach validation rules, expose an API.

The model exists first - the API is built around it. This works beautifully when the model is known.

But many enterprise projects don't work like that.

The Reality I Kept Seeing

For several years, I worked on APIs inside a large company. The company was not selling software, software was simply one of the tools supporting the real business. That changes everything. Because the business rarely arrives with a complete model. Instead, requirements often look like this:

We need to accept these fields.

A few weeks later:

We also need these additional fields.

A month later:

Another partner sends a slightly different structure.

And eventually:

Existing clients must continue working exactly as before.

At that point, the beautiful DTO hierarchy starts fighting reality. Not because the code is bad. Because the assumptions were wrong. We assumed we already understood the shape of the domain.

We didn't.

The Endless Refactoring Cycle

The pattern became familiar.

Week 1:

{
  "customerId": "123",
  "amount": 100
}

Week 3:

{
  "customerId": "123",
  "amount": 100,
  "customerType": "business"
}

Week 6:

{
  "customerId": "123",
  "amount": 100,
  "customerType": "business",
  "partnerSpecificData": {}
}

Week 10:

{
  "customerId": "123",
  "amount": 100,
  "legacyField": "must still be accepted"
}

Every change triggered another round of:

DTO updates
Validator updates
Serializer changes
Documentation changes

The code stayed clean, the model stayed elegant, the API contract remained unstable.

The Moment I Changed My Mind

At some point I realized I was solving the wrong problem. I wasn't trying to model the business. I was trying to define what the API accepted. Those are not always the same thing. An API contract answers a much simpler question:

What payload is valid today?

It doesn't need to predict the future, to represent the perfect domain model. It only needs to describe the contract between a client and a server. That realization pushed me toward JSON Schema.

Why JSON Schema Felt Different

JSON Schema starts from a completely different assumption. It doesn't care about entities, DTOs and about object hierarchies. It only describes data.

For example:

{
  "type": "object",
  "required": ["customerId"],
  "properties": {
    "customerId": {
      "type": "string"
    },
    "amount": {
      "type": "number"
    }
  }
}

That's it. A contract - nothing more, nothing less. The schema says what is allowed. The application decides what to do with it.

Contract First, Model Later

The biggest shift for me was psychological. I stopped pretending I already knew the final model. Instead, I accepted that the contract would evolve. The schema could evolve with it. When the business changed requirements, I updated the contract.

not an entire object graph.
not a DTO hierarchy.
not a collection of serializer groups.

Just the contract.

Over time, stable patterns emerged. Only then did it make sense to extract real domain concepts.

This Is Why I Built My Symfony Bundle

Eventually I wanted to use JSON Schema validation directly inside Symfony applications. Not as documentation or as generated code.

As a runtime contract.

I wanted to take a schema, validate incoming payloads, and know immediately whether the request matched the agreement between the client and the server. That idea eventually became the bundle I've been working on. But the bundle itself is not the important part. The important part is the lesson that led to it.

Final Thoughts

I still use DTOs. I still use validation constraints. I still think they are excellent tools. But I no longer start with them.

When requirements are unstable and the business is still discovering its own processes, I start with the contract. For me, that contract is often a JSON Schema.

Not because it's more elegant - because it reflects reality better.

p.s. and I strongly suspect that 95% of businesses in the world operate under this kind of entropy, and some of the readers here are either in it right now or have experienced it before. Tell me how you deal with it — how do you fight this entropy?

The Multi-Scenario Docker Pattern: how to build a reproducible Docker environment for any conditions

David Evdoshchenko — Thu, 04 Jun 2026 12:09:52 +0000

We had CI passing while production kept breaking.

The application ran inside a highly restricted government network, where accessing production sometimes required physical presence in a ministry office in another country.

If something went wrong, debugging was rarely direct. In many cases it meant traveling on-site, passing security checks, and accessing internal workstations just to inspect logs or confirm behavior.

When that wasn’t possible, we were forced into guesswork: comparing environments, reproducing issues locally, and assuming configuration drift.

This is where we first encountered a structural problem: environment drift was no longer theoretical — it was operational reality.

At some point, we asked for a full specification of the production runtime (PHP version, extensions, OS packages, configuration).

We containerized the system and standardized delivery as a fully built Docker image matching production exactly.

From that point on, the real problem became clear: keeping development, CI, and production environments from silently diverging.

The Principle: one runtime, many scenarios

This pattern is built on a simple idea:

one runtime + multiple deployment scenarios

The Dockerfile and the base environment must be singular. Differences are only allowed at the scenario level. When all scenarios share one runtime and one set of common configurations, divergence between environments becomes explicit rather than accidental.

A scenario is not just a compose file. It is a self-contained unit for launching an environment, consisting of:

docker-compose.yml
.env
Makefile
devcontainer.json
additional scripts

Project Structure

my-app/
├── .devcontainer/
│   ├── _configs/              # shared runtime configurations
│   ├── _scripts/              # shared entrypoint scripts
│   ├── _data/                 # auxiliary binary dependencies
│   ├── scenario-mapped/       # local development (bind mount)
│   │   ├── docker-compose.yml
│   │   ├── devcontainer.json
│   │   ├── Makefile
│   │   └── .env
│   ├── scenario-embedded/     # deploy image (code inside the image)
│   │   ├── docker-compose.yml
│   │   ├── devcontainer.json
│   │   ├── Makefile
│   │   └── .env
│   ├── Dockerfile.app
│   ├── Dockerfile.database
│   └── Dockerfile.*
├── .env                       # base application configuration
└── ...

Execution Flow

Different scenarios share the same runtime and the same set of common resources. Scenarios do not create different systems — they only switch the way the same system is launched.

Working Example

All files and scenarios shown in this article are available in a separate repository:

https://github.com/outcomer/multi-scenario-docker-pattern

The repository contains a fully working example with the directory structure, Dockerfiles, docker-compose, Makefile, and Dev Container support.

How It Works

One base runtime

All scenarios use the same set of Dockerfiles. For example, Dockerfile.app might contain:

PHP runtime;
extensions;
Composer;
system dependencies;
base web server configuration.

This layer does not depend on any scenario.

Scenarios differ only in how they launch

Scenarios define: how code gets into the container, which environment variables are used, which tools are enabled.

scenario-mapped

Local development: code is mounted via bind mount, changes are reflected instantly, fast dev cycle, convenient for debugging.

scenario-embedded

Production / CI:

code is copied inside the image;
the container does not depend on the host;
the environment is reproducible anywhere.

Why This Matters

The key idea of the pattern:

consistency is achieved not by team discipline, but by project structure

All scenarios use one runtime and one set of configurations from _configs. This means:

differences become explicit;
runtime versions do not drift silently;
changes are automatically applied to all scenarios.

Note: this does not make drift impossible, but it makes it visible and controllable.

Why Not Docker Compose Profiles

Docker Compose Profiles allow enabling and disabling services within a single compose file. For simple cases this is enough. However, profiles solve only one problem — managing the set of services.

In this approach, a scenario is a broader concept. It includes not just a compose file, but also:

.env;
Makefile;
devcontainer.json;
additional scripts;
environment launch rules.

A scenario is a complete environment, not just a service toggle.

Why Separate Scenario Directories

The typical path of project evolution often looks like this:

docker-compose.yml
    ↓
docker-compose.dev.yml
    ↓
docker-compose.prod.yml
    ↓
docker-compose.staging.yml

Over time this becomes a system of overrides:

docker compose \
  -f docker-compose.yml \
  -f docker-compose.override.yml \
  -f docker-compose.staging.yml \
  up

Understanding what will actually end up in the final configuration becomes increasingly difficult. In the scenario approach, launching looks like this:

cd .devcontainer/scenario-mapped
make up

cd .devcontainer/scenario-embedded
make deploy

A scenario becomes a physical object in the repository, not a combination of flags and files.

CI Is Just Another Scenario

An interesting side effect of this approach is that CI stops being a separate world. Instead of special logic inside GitHub Actions or GitLab CI, the pipeline can use the same scenario as the rest of the environments. Local development, CI, and production start using the same launch model. The fewer differences between these environments, the less likely you are to get surprises after deployment.

Podman Support

The pattern is not tied to Docker Engine. Since scenarios describe the way of launching rather than a specific container engine, the same set of scenarios can be used with both Docker and Podman through a compatible interface. Differences remain at the level of the launch environment, not the project architecture.

Practical Usage

Local development:

cd .devcontainer/scenario-mapped
make up

Deploy:

cd .devcontainer/scenario-embedded
make deploy

Makefile Scenario Example

A full Makefile typically contains dozens of commands. To understand the pattern, it is enough to see the core idea:

deploy:
    @$(MAKE) build
    @$(MAKE) migrations-check
    @$(MAKE) up
    @$(MAKE) migrations-run
    @$(MAKE) healthcheck

The scenario encapsulates the knowledge of exactly how a launch or deployment should happen. The user only needs to call one command.

What the Pattern Guarantees

The pattern provides:

a single runtime for all scenarios;
no hidden differences between dev and prod;
explicit separation of launch scenarios;
isolation of dev tools from production;
centralized configuration through a shared layer.

Limitations

The pattern does not eliminate the need for architectural discipline. It is still important to:

not add scenario-specific logic to the shared runtime;
not duplicate configurations outside _configs;
not mix dev and production behavior inside a Dockerfile.

Summary

Most problems in Docker projects do not appear because of containers — they appear because of multiple nearly identical ways of launching the same application. The Multi-Scenario Docker Pattern addresses exactly this problem: instead of several gradually diverging environments, you get one runtime and several explicit scenarios for using it.

This pattern emerged from a real production constraint, not a theoretical design exercise.

DON'T CHANGE THE ENVIRONMENT — CHANGE THE SCENARIO

Working Example

All files and scenarios shown in this article are available in a separate repository:

https://github.com/outcomer/multi-scenario-docker-pattern

The repository contains a fully working example with the directory structure, Dockerfiles, docker-compose, Makefile, and Dev Container support.

What’s your go-to pattern for keeping Docker behavior consistent across environments (e.g. dev, CI, deploy, others)? I’d love to hear what has actually worked for you in the comments.

I got tired of describing the same request 3 times in Symfony

David Evdoshchenko — Fri, 29 May 2026 09:43:05 +0000

When building Symfony APIs, I kept duplicating the same request contract:

validation rules in a DTO
OpenAPI schema (often separately)
mapping / glue code around it

After enough endpoints, the API layer started feeling heavier than the business logic.

Here’s a tiny example (validation in a DTO):

class CreateUserRequest
{
    #[Assert\NotBlank]
    #[Assert\Email]
    public string $email;
}

The same email then needs to exist again in OpenAPI docs - and the two drift over time.

So I built a small Symfony bundle to reduce that duplication.

Instead of describing the request multiple times, I keep a single JSON Schema:

{
  "type": "object",
  "required": ["email"],
  "properties": {
    "email": {
      "type": "string",
      "format": "email"
    }
  }
}

That schema becomes the source of truth for:

request validation
request mapping
OpenAPI generation

Basic usage:

#[MapRequest('schemas/user-create.json')]
UserCreateDto $user

It's not trying to replace Symfony (or API Platform). The goal is to adopt it gradually and write less boilerplate while keeping request contracts explicit.

Project: https://github.com/outcomer/symfony-json-schema-validation
Docs: https://outcomer.github.io/symfony-json-schema-validation/

What part do you duplicate the most in Symfony APIs: validation, OpenAPI, or mapping?

I had to build my own Symfony validation bundle because no existing one fits my requirements

David Evdoshchenko — Wed, 11 Mar 2026 22:02:22 +0000

Long story short
The Problem
The Idea
The Solution
Quick Examples
- Example 1
- Example 2
What's the result?
The Full Story

Long story short

I created a bundle for request validation with JSON Schema because no existing "schema-first" validator fit my requirements. Now I just attach a JSON file to a route and get everything at once: validation, DTO mapping, and OpenAPI documentation from a single source of truth.

The Problem

Most validation solutions that can generate API documentation from code (in the Symfony world I mostly mean FOSRestBundle and API Platform) assume that your business logic is:

Well defined and relatively stable
Close to a classic CRUD model (or CRUD with small deviations)
Exposed via clean, REST-style endpoints that you fully control

In other words, they assume your application defines the contract and the outside world adapts to it.

But in many real projects it is the opposite: the API contract is defined somewhere else (legacy frontend, external systems, partners), and you have to adapt to that contract. That is where problems start.

Here is a simplified example. The API expects this payload:

{
  "type": "company",
  "user": {
    "name": "John",
    "email": "john@example.com",
    "company": {
      "name": "Acme"
    }
  }
}

With the following rules:

If type = "company" then user.company.name is required
If type = "person" then user.company must be absent

Is this the most elegant API design? Probably not. But imagine a company with 2000 people and a frontend written years ago that sends exactly this structure. You cannot just redesign everything because you do not like the shape of the JSON.

Now, what does the "ideal" Symfony validation setup suggest here?

class UserDto
{
    #[Assert\NotBlank]
    public string $name;

    #[Assert\Valid]
    public ?CompanyDto $company;
}

This does not express the conditional logic "company.name is required when type = company". To implement this you usually end up with one of the following:

Custom constraint with its own validator
Manual validation logic in the controller or a service
Custom normalizer / denormalizer with additional checks

Then another question appears: how do you forbid extra properties that are not defined in UserDto? For a long time you simply could not. In newer Symfony versions you can write something like:

#[MapRequestPayload(
    serializationContext: ['allow_extra_attributes' => false]
)]

#[MapQueryString(
    serializationContext: ['allow_extra_attributes' => false]
)]

Whether this works for query parameters depends on the exact types and context. For headers this approach does not work at all.

You might ask: why be so strict? Why not just ignore extra parameters? Because in real life this often leads to subtle bugs. A typical scenario: you had a query parameter offset and later renamed it to page for consistency with other APIs. Some client code still sends offset. If you ignore unknown parameters, the request "works", but returns the wrong page. You then spend time debugging something that could have been caught immediately.

With strict validation the client would get a clear error about an unknown parameter, and the problem would be visible right away.

My personal view is that even though an API has no visual UI, it still has UX. Clients should receive clear, precise error messages, not a generic "Provided data is incorrect". Detailed validation errors are also in the interest of the backend team: fewer support tickets, less time spent guessing what went wrong on the client side.

The Idea

The kind of validation I needed has actually existed for years, just not in the form of typical Symfony validators. I am talking about the JSON Schema standard:

https://json-schema.org/specification

JSON Schema is a declarative language for defining structure and constraints for JSON data

It is designed exactly for problems like the ones above (and much more complex ones):

Conditional rules based on other fields
Nested, deeply structured data
Strict control over allowed and forbidden properties

So the idea was simple: instead of forcing my API contract into DTO classes and annotations, let Symfony validate incoming requests against a JSON Schema that fully describes the contract.

In other words, make Symfony request validation schema-first, with JSON Schema as the single source of truth.

The Solution

The good news was that I did not need to implement JSON Schema myself. There was already a solid PHP implementation:

https://opis.io/json-schema/

The library takes a valid JSON Schema and any input data, validates the data against the schema and either:

returns the data (when everything is valid), or
returns a structured list of validation errors.

From there, the rest was mostly integration work:

Make it convenient to plug this validation into a Symfony project
Wire it into the request lifecycle
Provide a way to map validated data into DTOs when needed
Integrate with Nelmio so that OpenAPI documentation is generated from the same schemas

Below I will show a couple of short examples. In the "The Full Story" section I describe how I removed duplication between validation attributes and documentation, and how the bundle ended up solving both validation and API specification generation from a single source of truth: the JSON Schema files.

Quick Examples

Example 1
Example 2

The schema

{
    "$schema": "https://json-schema.org/draft-07/schema#",
    "type": "object",
    "properties": {
        "query": {
            "type": "object",
            "properties": {},
            "additionalProperties": true
        },
        "headers": {
            "type": "object",
            "properties": {
                "authorization": {
                    "type": "string",
                    "description": "Bearer token for authentication",
                    "pattern": "^Bearer .+",
                    "example": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ6..."
                },
                "x-api-version": {
                    "type": "string",
                    "description": "API version",
                    "enum": ["v1", "v2"],
                    "example": "v1"
                },
                "content-type": {
                    "type": "string",
                    "description": "Request content type",
                    "enum": ["application/json"],
                    "example": "application/json"
                }
            },
            "additionalProperties": true
        },
        "body": {
            "type": "object",
            "properties": {
                "name": {
                    "type": "string",
                    "minLength": 3,
                    "maxLength": 100,
                    "description": "User's full name",
                    "example": "Jane Smith"
                },
                "email": {
                    "type": "string",
                    "format": "email",
                    "description": "User's email address",
                    "example": "john.doe@example.com"
                },
                "age": {
                    "type": "integer",
                    "minimum": 21,
                    "maximum": 100,
                    "description": "User's age (optional)",
                    "example": 30
                }
            },
            "required": ["name", "email"],
            "additionalProperties": false
        }
    }
}

Example 1: validation using the built-in request object

#[OA\Post(
    operationId: 'validateUser',
    summary: 'Validate user',
)]
#[Route('/user', name: '_example_validation_user', methods: ['POST'])]
public function validateUser(#[MapRequest('./user-create.json')] ValidatedRequest $request): JsonResponse
{
    $payload = $request->getPayload();
    $body    = $payload->getBody();

    return $this->json([
        'success' => true,
        'message' => 'User data is valid',
        'data'    => [
            'name'  => $body->name,
            'email' => $body->email,
            'age'   => $body->age ?? null,
        ],
        'example' => 'This uses ValidatedRequest (standard way)',
    ], 200);
}

Example 2: validation using a custom DTO (via ValidatedDtoInterface)

#[OA\Post(
    operationId: 'createProfile',
    summary: 'Create profile',
)]
#[Route('/profile', name: '_example_validation_profile', methods: ['POST'])]
public function createProfile(#[MapRequest('./user-create.json')] UserApiDtoRequest $profile): JsonResponse
{
    return $this->json([
        'success' => true,
        'message' => 'Profile created successfully',
        'profile' => [
            'name'  => $profile->name,
            'email' => $profile->email,
            'age'   => $profile->age,
        ],
        'note'    => sprintf('This demonstrates DTO auto-injection: MapRequestResolver calls %s::fromPayload() automatically', UserApiDtoRequest::class),
    ], 201);
}

What's the result?

Focused solution: instead of reinventing the wheel, the bundle fills a specific gap that existing Symfony tools do not cover well (schema-first request validation).
Less duplication: you no longer have to mirror the same rules in DTO constraints, controllers and OpenAPI annotations.
Automatic sync: Nelmio builds documentation from the same JSON Schema files that are used for validation, so your docs always match the real behavior.
Contract-centric design: the entire API contract lives in clean JSON files rather than being scattered across PHP attributes and PHP classes.

If you were looking for a way to validate requests without creating a large number of redundant DTO classes and annotations, this bundle is designed for that use case:

The Full Story

This article is the short, focused version of the story: what the bundle does and how to start using it. If you want the long version with all the scars and details, I wrote a separate, much bigger post.

In that post I go through:

how the bundle was born in a very messy real project, not in a greenfield demo
why classic DTO + Assertions validation did not survive 500+ routes
how JSON Schema became the single contract language for backend, frontend and docs
how the bundle glues Symfony, Opis JSON Schema and Nelmio together

You can read the full story here (starting from The Full Story section):

https://outcomer.hashnode.dev/symfony-bundle-that-validates-anything-and-everything#the-full-story

I built a Symfony bundle that validates anything and everything.

David Evdoshchenko — Sun, 08 Mar 2026 13:49:08 +0000

Long story short

I created a bundle for request validation via JSON Schema because I was fed up with the lack of a simple "schema-first" validator. Now, I just attach a JSON file to a route, and everything - validation, DTO mapping, and OpenAPI documentation - works out of the box.

Feel free to ask me whatever relevant to topic via comments here;

The Pain Point

I didn't set out to build my own bundle. I had a simple task: validate an incoming request against specific conditions.
Sounds basic, right? But when I looked for a solution, I found that the modern Symfony world is stuck in one specific pattern:

create a DTOs;
write a ton of assertions (Annotations/Attributes);
if the structure is complex or dynamic-suffer and write custom normalizers;

I searched everywhere but couldn't find a straightforward way to say: "Here is my JSON, here is my schema, just check them and give me an object." Instead, I was forced to create mountains of boilerplate that I didn't need.

Why DTO + Assertions isn't always the answer

The classic approach with assertions in PHP classes works fine for simple forms or strictly structured data. But as soon as you deal with deep nesting or requirements that don't play well with normalization - it's much easier to define the requirements once in the JSON Schema standard. Otherwise, you end up duplicating logic - firstly in code, then in docs.

I wanted flexibility. I wanted to use a standard that everyone understands - from frontend developers to QA engineers.

Solution

How I solved it: I built a bundle that makes JSON Schema a "first-class citizen" in Symfony. Now, instead of describing validation rules in PHP code, I simply point to a schema.

The bundle allows you to validate data either into a built-in DTO (which always contains validated path, query, headers, and body) or into your own custom class, provided it implements the ValidatedDtoInterface.

Example 1: Validation into the built-in ValidatedRequest

#[OA\Post(
    operationId: 'validateUser',
    summary: 'Validate user',
)]
#[Route('/user', name: '_example_validation_user', methods: ['POST'])]
public function validateUser(#[MapRequest('./user-create.json')] ValidatedRequest $request): JsonResponse
{
    $payload = $request->getPayload();
    $body    = $payload->getBody();

    return $this->json([
        'success' => true,
        'message' => 'User data is valid',
        'data'    => [
            'name'  => $body->name,
            'email' => $body->email,
            'age'   => $body->age ?? null,
        ],
        'example' => 'This uses ValidatedRequest (standard way)',
    ], 200);
}

Example 2: Validation into your own DTO (via ValidatedDtoInterface)

#[OA\Post(
    operationId: 'createProfile',
    summary: 'Create profile',
)]
#[Route('/profile', name: '_example_validation_profile', methods: ['POST'])]
public function createProfile(#[MapRequest('./user-create.json')] UserApiDtoRequest $profile): JsonResponse
{
    return $this->json([
        'success' => true,
        'message' => 'Profile created successfully',
        'profile' => [
            'name'  => $profile->name,
            'email' => $profile->email,
            'age'   => $profile->age,
        ],
        'note'    => sprintf('This demonstrates DTO auto-injection: MapRequestResolver calls %1$s::fromPayload() automatically', UserApiDtoRequest::class),
    ], 201);
}

What's the result?

I didn't "reinvent the wheel"; I simply filled a gap in the ecosystem;
No more duplicate work: No more writing endless #[Assert\NotBlank], #[Assert\Type("string")], etc;
Automatic Sync: Nelmio picks up the schema from the same file - your documentation never lies;
Contract-Centric: The entire API contract lives in clean JSON files rather than being scattered across PHP attributes;

If you, like me, were looking for a way to validate requests like a human being without creating dozens of redundant classes - here is the solution:

I had to build my own Symfony validation bundle because no existing one fits my requirements.

David Evdoshchenko — Thu, 05 Mar 2026 19:53:54 +0000

UPDATE: I have completely rewritten this guide to focus on a more pragmatic approach.

My original article discussed the challenges of Symfony/OpenAPI validation, but since then, I've built a dedicated tool that solves this by using JSON Schema as the single source of truth.

You can find the improved, "no-boilerplate" version of this article here: https://dev.to/outcomer/i-built-a-symfony-bundle-that-validates-anything-and-everything-4nah

DEV Community: David Evdoshchenko

I Stopped Following API Validation Best Practices. Here's Why.

The Assumption Behind Most API Design

The Reality I Kept Seeing

The Endless Refactoring Cycle

The Moment I Changed My Mind

Why JSON Schema Felt Different

Contract First, Model Later

This Is Why I Built My Symfony Bundle

Final Thoughts

The Multi-Scenario Docker Pattern: how to build a reproducible Docker environment for any conditions

The Principle: one runtime, many scenarios

Project Structure

Execution Flow

Working Example

How It Works

One base runtime

Scenarios differ only in how they launch

scenario-mapped

scenario-embedded

Why This Matters

Why Not Docker Compose Profiles

Why Separate Scenario Directories

CI Is Just Another Scenario

Podman Support

Practical Usage

Makefile Scenario Example

What the Pattern Guarantees

Limitations

Summary

Working Example

I got tired of describing the same request 3 times in Symfony

I had to build my own Symfony validation bundle because no existing one fits my requirements

Contents

Long story short

The Problem

The Idea

The Solution

Quick Examples

Example 1: validation using the built-in request object

Example 2: validation using a custom DTO (via ValidatedDtoInterface)

What's the result?

The Full Story

I built a Symfony bundle that validates anything and everything.

Long story short

The Pain Point

Why DTO + Assertions isn't always the answer

Solution

Example 1: Validation into the built-in ValidatedRequest

Example 2: Validation into your own DTO (via ValidatedDtoInterface)

What's the result?

I had to build my own Symfony validation bundle because no existing one fits my requirements.