DEV Community: SensioLabs

API Platform Con 2025 - Day 2

Thérage Kévin — Wed, 24 Sep 2025 08:00:19 +0000

I had the opportunity to attend the API Platform Con 2025 thanks to SensioLabs and here is what I learned through the talks I viewed.

How LLMs are changing the way we should build APIs (Fabien Potentier)

Slides of this talk are available : https://speakerdeck.com/fabpot/how-ai-agents-are-changing-the-way-we-should-build-apis

Fabien Potentier shared insights about how Large Language Models are fundamentally changing the way we need to think about API design. As he mentioned, this is a world that changes so fast that some assertions might already be outdated.

Agents ?

LLMs are evolving beyond simple text generation into autonomous agents. According to Anthropic's definition, an agent is an LLM using tools in a loop. These LLMs are self-directed - they can reason about things, they can plan, and have memory.

An AI agent is kind of a mix between a machine and a human, combining the computational power of machines with human-like reasoning capabilities.

Who can consume your app ?

Back in the days, the consumers were clearly defined:

Website:

Human users only

CLI tools:

Only for developers

API:

Only for machines
Semi-private (to decouple frontend) or public

Nowadays, APIs are mostly used to expose data, but AI agents have changed the game completely. They are able to interact with all three interfaces:

Websites can be scraped by AI - agents can navigate and extract information from web interfaces
CLI tools can be used through MCP servers - providing structured tool access
APIs - LLMs (e.g., in chatbots) are often wrappers on top of APIs. Furthermore, LLMs can also write API calls directly.

But all three have different expectations, and this creates new challenges.

The Challenge: APIs for Humans vs. Machines vs. AI Agents

APIs are optimized for machines, but when something breaks, you need a human in the loop. However, AI agents are autonomous but, like humans, they need help and guidance.

Take HTTP status codes as an example. They provide information about problems, but AI agents need more context.
HTTP responses can provide context about errors, but responses provided by APIs might not be up-to-date or accurate, causing LLMs to get stuck.

Here is a common workflow pattern followed by LLM : Thought → Action → Observation.
Without guidance provided via prompts, it can loop over the same problem, encountering the same Observation after performing the same Action—potentially forever.
LLMs will try to guess and self-correct, which is probably bad for two reasons:

Costly - more API calls and processing
Time loss - inefficient problem resolution
Resource greedy - GPU time and electricity are consumed without solving the problem

Tip: The fewer round trips you have with an LLM, the more "deterministic" it becomes, even though LLMs are inherently not deterministic.

Best Practices for LLM-Friendly APIs

Everything that is valid for LLMs is also valid for humans.

Error Messages

Be precise with your error messages: "Bad date format. Use 'YYYY-MM-DD'."
Benefits:

Fewer tokens consumed
Smaller context window usage
Faster resolution

Consistent Naming

Use the same naming pattern everywhere. For example, use user_id consistently across all endpoints.
Benefits:

Predictable patterns
LLMs like consistency
Easier to understand and use

Documentation

Fix examples and remove outdated content
Fewer problems and hallucinations
Consider using llms.txt files - documentation specifically formatted for LLMs in Markdown

Performance Considerations

AI agents are slow, so reducing the number of requests provides a significant performance boost.

Intent-First API Design

Design your APIs to capture and preserve user intent rather than just exposing CRUD operations.

Testing Challenges

Testing AI agents is super difficult because:

LLMs are not deterministic
You need to set temperature to 0 for more consistent results
Use concise prompts
Ultimately, you need a human to judge the quality of actions performed by the LLM, making automated testing complex

Technical Considerations

Tokens vs. Text

Understanding tokenization is crucial. Tools like tiktokenizer.vercel.app help visualize how text is tokenized:

Language matters: English costs less in tokens than French or Japanese for example
Unique IDs are problematic: UUIDs are bad for tokenizers, ULIDs are better
Shorter is not always better in terms of token efficiency
Date formats matter for token consumption
JSON is not the best format for LLMs - Markdown is better and uses fewer tokens

More tokens require more money and create larger context windows, which negatively impact AI agent response times and relevance.

Security and Credentials

AI agents are bad at dealing with credentials. The solution is to use MCP (Model Context Protocol) servers that:

Handle credentials securely
Provide tools to AI agents
Give limited scope permissions to MCP actions
Act as a secure intermediary between the LLM and your APIs

Log Everything

Given the complexity and unpredictability of AI agent interactions, comprehensive logging becomes essential for debugging and improving the system.

The New Experience: AX (AI Experience)

Fabien introduced the concept of AX (AI Experience) alongside the familiar UX (User Experience) and DX (Developer Experience). This represents a new dimension of API design focused on how well your API works with AI agents.

Key aspects of good AX include:

Up-to-date documentation and examples (avoiding outdated examples that could mislead the LLM)
Using llms.txt files with all useful documentation for the LLM in Markdown format
Clear, consistent error messages
Intent-preserving API design
Efficient token usage

The fascinating aspect is that many improvements for AX also benefit traditional DX, making APIs better for both human developers and AI agents.

Build a decoupled application with API Platform and Vue.js (Nathan de Pachtere)

Nathan de Pachtere shared his experience building decoupled applications using API Platform for the backend and Vue.js for the frontend. His insights covered the differences between headless and decoupled approaches, practical implementation strategies, and the benefits of monorepo architecture.

Headless

Headless architecture involves creating a business-focused API that anyone can use independently. Think of the GitHub API - it's designed as a standalone service that provides all the functionality needed to interact with GitHub's features, completely independent of any specific frontend implementation.

The goal is to create business logic and provide an API that everyone can utilize for their own purposes.

Decoupled

Decoupled architecture is similar but more focused. You provide a frontend that relies specifically on your API, creating what's essentially a backend-for-frontend pattern. The API doesn't seem to be made for independent use outside of the specific application - it's tailored to serve the frontend's exact needs.

Why Choose This Approach?

Advantages

Separation of responsibilities - Clear boundaries between frontend and backend concerns
Team management - Enables specialist teams to work independently on their expertise areas
Capitalization - Reusable components and logic across different projects
Future-proofing - AI might be the interface used in the future, making an API-first approach valuable

Disadvantages

Complexity - More complex setup for existing projects that need to be refactored

Headless Implementation

using API Platform

The process follows a business-driven approach:

Represent the API based on business needs - Focus on what the business actually does
Translate into entities and workflows - Convert business processes into technical implementations
Write only the necessary code - Keep it simple initially
Then optimize and refactor - Improve performance and code quality
Iterate - Continuously improve based on feedback
Go beyond CRUD - Implement meaningful business operations, not just basic data manipulation

Providing API Keys

For machine-to-machine authentication:

Create a simple interface for creating/deleting configurable keys with specific permissions
Consider external identity providers like Keycloak or Zitadel for more advanced use cases
Important principle: Don't mix human users with machine users - they have different needs and security requirements

Nathan emphasized making tests simple and easy to implement, integrating them naturally into the development workflow rather than treating them as an afterthought.

Deprecation Strategy

When evolving your API:

Deprecate endpoints, resources, and properties gradually
Give consumers time to adapt to changes
Communicate changes clearly before removing functionality

This approach maintains backward compatibility while allowing the API to evolve.

Decoupled Implementation

using Vue.js

Nathan chose Vue.js for several reasons:

Independent and community-driven - Not controlled by a single corporation
Composition API (Vue 3) - Promotes code reusability and better organization
Excellent Developer Experience - Great tooling and development workflow
Top performance - Fast and efficient (until the next framework comes along, as he joked)

API Connection

For connecting the Vue.js frontend to the API Platform backend:

Code Generation

Use openapi-ts.dev to generate TypeScript types and composables from your OpenAPI specification. This ensures type safety and reduces manual work.

Important principle: Don't use the generated types directly as base objects in your frontend. Create your own models to maintain proper decoupling between frontend and backend representations.

HTTP Client and State Management

Tanstack Query - For efficient data fetching and caching
TypeScript throughout - Ensures type safety across the application
VS Code for Vue.js development - Better integration compared to JetBrains IDEs for Vue.js work

High-Level SDKs

Provide high-level SDKs to facilitate API integration, making it easier for developers to work with your API.

Version Management

Polyrepo vs Monorepo

Monorepo doesn't mean monolith - this is a crucial distinction:

Monorepo = Multiple separate projects in a single repository
Monolith = Single application handling everything

Monorepo Benefits

The goal is to simplify the workflow:

Unified way of thinking about code - Consistent patterns across projects
Consistency - Shared tooling and configurations
Facilitates sharing - Easy code and component reuse
More efficient teamwork - Simplified collaboration and dependency management

Tooling

Nathan recommended moonrepo.dev as an open-source tool for managing monorepos. You can find more information at monorepo.tools.

Real-World Example

Nathan shared their experience with enormous benefits:

Code generalization - Reusable patterns and components
Functionality sharing - Common libraries across projects
Technology-based organization - Projects use shared libraries organized by technology stack

You can see a practical example of this approach in the Lychen project (lychen.fr), which demonstrates a well-structured monorepo with clear separation between backend, frontend, and shared tools.

The Lychen project shows how to organize a monorepo with:

Backend (API Platform/PHP)
Frontend (Vue.js/TypeScript)
Shared tooling (Moonrepo, Docker, testing tools)
Clear technology boundaries while maintaining efficient code sharing

Jean-Beru presents: Fun with flags (Hubert Lenoir)

Slides of this talk are available : https://jean-beru.github.io/2025_09_apiplatformcon_fun_with_flags

Jean-Beru (Hubert Lenoir) presented the fascinating world of feature flags and their practical implementation. As Uncle Ben said in Spider-Man: "With great power comes great responsibility" - and feature flags are indeed a powerful tool that requires careful consideration.

What are Feature Flags?

Feature flags (also known as feature flipping or feature toggles) are a software development technique that allows you to turn features on or off without deploying new code. They act as conditional statements in your code that determine whether a particular feature should be enabled or disabled for specific users, environments, or conditions.

Types of Feature Flags

Release Flags

Mainly used to test new features in production environments safely.

Continuous development - Even if a feature is not ready, you can continue developing and deploying (not ready = disabled)
Safe deployment - Deploy code with features turned off, then enable them when ready
Gradual rollout - Enable features for small groups before full release

Experiment Flags

Used to compare different versions of your application.

A/B testing - Compare different implementations or user experiences
Must be followed by metrics - Track performance and user behavior
Partial enablement - Enable for specific percentages (e.g., 20% of users)

This approach allows data-driven decisions about which features or implementations work best for your users.

Permission Flags

Control access to features based on user permissions or subscription levels.

Blocking access based on permissions - For example, paid features only available to premium subscribers
Role-based feature access - Different features for different user types
Subscription tiers - Enable advanced features for higher-tier customers

Operational Flags

Security belt and kill switch functionality.

Allow disabling cumbersome features - Quickly turn off resource-intensive features during high load
Emergency response - Disable problematic features without deployment
Performance management - Control system load by toggling expensive operations

For more detailed information about feature flag patterns, Martin Fowler has an excellent article at https://martinfowler.com/articles/feature-toggles.html.

Implementation

There are many feature flag providers available in the market, but the implementation doesn't necessarily need to use Symfony's Security component.

Why Not Security Component?

Restricted to current user context - Limitations when flags need to work across different user contexts
Authentication timing issues - Authentication happens after routing, which can lead to unwanted forbidden error codes
Flexibility needs - Custom implementations can better integrate with existing providers like Unleash

Requirements for a Good Implementation

A solid feature flag system should provide:

Simplicity - Easy to implement and use
Integrated debugging - Clear visibility into which flags are active
Multiple sources - Ability to switch between different flag providers
Various provider support - Work with different feature flag services
Cacheable - Performance optimization through caching mechanisms

Symfony Integration

There's a work-in-progress FeatureFlag component for Symfony (PR #53213). This component aims to provide native support for feature flags within the Symfony ecosystem.

With API Platform

Feature flags can be easily tested via a separated bundle: ajgarlag/feature-flag-bundle.

Implementation Steps

Decoration of API Platform provider - Use the decorator pattern to wrap existing providers with feature flag logic
Use FeatureFlag WIP component interface - Integrate with the upcoming Symfony FeatureFlag component

Example with GitLab Provider

GitLab provides a feature flag service that uses Unleash in the background. This integration allows you to:

Manage flags through GitLab UI - Familiar interface for teams already using GitLab
Leverage Unleash capabilities - Powerful feature flag engine under the hood
Integrate with CI/CD pipelines - Automatic flag management as part of deployment process

Profiler Integration

The implementation includes Symfony Profiler integration, providing:

Debug information - See which flags are active during development
Performance insights - Monitor the impact of feature flag checks
Development workflow - Easy testing and debugging of flag behavior

Advantages

Implementing feature flags brings several significant benefits:

Deploy Continuously

Decouple deployment from release - Deploy code safely with features disabled
Reduce deployment risk - Lower chance of breaking production
Faster iteration cycles - More frequent, smaller deployments

Progressive Testing

A/B testing capabilities - Compare different approaches with real users
Gradual rollouts - Start with small user groups and expand
Data-driven decisions - Make choices based on actual usage metrics

Quick Turn Off

No redeployment needed - Instantly disable problematic features
Emergency response - Rapid reaction to production issues
Business continuity - Keep core functionality working while fixing problems

Separate Code from Feature Release

Independent timelines - Development and business release schedules can differ
Marketing coordination - Align feature releases with marketing campaigns
Stakeholder management - Give business teams control over when features go live

Feature flags represent a powerful paradigm shift in how we think about software deployment and release management, enabling more flexible, safer, and data-driven development practices.

PIE : The next Big Thing (Alexandre Daubois)

Extensions ?

Extensions are like composer packages, but written in C, C++, Rust, and now Go.

They live at a lower level, which makes them much faster than pure PHP code.

Frameworks like Phalcon are themselves shipped as extensions.

Installing a third-party lib

Traditionally, installing an extension is much more painful than a composer install.

It usually involves:

Downloading the source code.
Compiling it with phpize and make.
Adding a line to php.ini to enable it.
Restarting PHP-FPM or Apache to load it.

This workflow makes extensions harder to distribute and standardize compared to Composer packages.

PECL

Clunky and outdated.
Slow to install.
Lacks proper security (no package signing).
Not officially backed by PHP, and some in the community want to phase it out.

docker-php-extension-installer

A widely used community project that simplifies extension installation inside Docker images.

Instead of writing complex apt-get + phpize + make commands, you just add:

COPY --from=ghcr.io/mlocati/php-extension-installer /usr/bin/install-php-extensions /usr/local/bin/

RUN install-php-extensions xdebug redis

This is great, but still not perfect—it remains Docker-specific and doesn’t integrate with Composer or Packagist.

Project to replace PECL

The pie-design repository defines the foundations of PIE, a new way to install extensions as easily as PHP packages.

Started in March 2024.
Version 1 released in June 2025.
PIE is distributed as a single phar file: just download it and use it.
All extension metadata is stored in Packagist.

Command options

pie install ext-xdebug → installs an extension and updates php.ini.
pie uninstall ext-redis → removes an extension.
pie update → upgrades to the latest available version.
pie search redis → searches for extensions in Packagist.
Running pie without arguments reads extensions from composer.json and installs them.

Other features:

Add repositories via Composer, VCS, or local paths.
Automatic php.ini update.
Support for GH_TOKEN to install from private repositories.
OS compatibility restrictions.
Symfony CLI integration: symfony pie install.

The future of extensions

PIE is the theoretical replacement for PECL.

An RFC vote was held, closing on September 20, 2025.

Almost everyone voted yes, which means PIE is now the official successor to PECL.

Make your devs happy by normalizing your API errors (Clément Herreman)

Errors are not just bugs. They’re an opportunity to give users autonomy through clear feedback.

What is an error?

An error is any behavior—intentional or not—that prevents the user from completing their task.

Why normalize errors?

To react properly to a precise issue:
- Retrying a token.
- Handling distributed system failures.
- Fixing configuration issues.
To present errors consistently:
- Clear and understandable messages for end-users.
- Precise identification to ease support.
- Keeping some details vague for security reasons.

How?

Errors can be classified into three categories:

Errors that belong to your domain: you own them, so enrich them with context.
Errors that don’t belong to your domain but still happen: wrap them with a code and enrich them.
Rare/unexpected errors: keep the default JSON output.

RFC 7807: Problem Details for HTTP APIs

This RFC defines a standard JSON structure for errors:

type: unique machine-readable code.
title: short, human-readable summary.
detail: contextual explanation of this particular error.
instance: URL to the error catalog.
...: any custom fields you want.

Example HTTP response

HTTP/1.1 401 Unauthorized
Content-Type: application/problem+json

{
  "type": "https://example.com/errors/authentication_failed",
  "title": "Authentication failed",
  "detail": "Your token has expired. Please request a new one.",
  "instance": "/login"
}

API Platform

API Platform provides a ready-to-use ApiPlatform\Problem\Error class to implement RFC 7807.

Organizing errors

Keep only business exceptions in the domain layer.
Wrap infrastructure errors before sending them to the client.

Documenting errors

Errors can be declared as attributes on operations, making them explicit in the API docs.

Improvements: RFC 9457

RFC 9457 is essentially the same as RFC 7807, with some additions:

A registry of errors via schema.org.
A mechanism for returning multiple errors at once (though strongly discouraged).

As Clément highlighted: RFC 9457 doesn’t bring much practical value, and some of its suggestions are even discouraged in the spec.

Symfony and Dependency Injection: From past to future (Imen Ezzine)

Dependency Injection (DI) is the “D” in SOLID, and it has been a cornerstone of Symfony’s design for nearly two decades.

This talk explored its history, evolution, and what’s next.

The early days

2007 – Symfony 1

Services instantiated directly, often via sfContext() (a singleton).
Hard to test, rigid, tightly coupled.
No real container.

Symfony 2 and the paradigm shift

2011 – Symfony 2

Introduction of a central container.
Services configured via YAML and parameters.
Dependencies injected as constructor arguments.
Autowiring introduced in Symfony 2.8.

2015 – API Platform v1

Heavy reliance on autowiring (then experimental).

2016 – API Platform v2

@ApiResource annotation magic powered by the DI component.
Data persisters and providers had to be tagged manually.

2017 – Symfony 3.3 / API Platform 2.2

Autowiring + autoconfigure.
Manual tagging mostly eliminated (providers/persisters automatically wired).
Symfony 3.4: services private by default.

Symfony 5 to Symfony 7

2021 – Symfony 5.3

DI powered by attributes → much less YAML.
#[When] attribute for conditional services.

Symfony 6.0 – 6.3

New attributes for corner cases.
#[Autowire] attribute for precise service injection.
Support for env vars and parameters via attributes.
#[AsAlias] to alias services.

2022 – API Platform 3.0

New state processors and providers replace older persister/provider pattern.

2023 – Symfony 7

#[AutoconfigureTag] → automatic tagging (used in API Platform filters).
TaggedIterator → inject multiple tagged services.
AutowireIterator → autowire all classes implementing an interface.

Symfony 7.1 – 7.3

#[AutowireMethodOf] to autowire a single method.
#[WhenNot] for conditional services.
when parameter in #[AsAlias].

Takeaways

Over 20 years, DI in Symfony evolved from:

Manual instantiation →
Manual configuration →
Automatic configuration through attributes.

This journey has made Symfony projects more testable, maintainable, and developer-friendly while reducing boilerplate.

Credits

Cover image by Nicolas Detrez

API Platform Con 2025 - Day 1

Thérage Kévin — Wed, 24 Sep 2025 07:52:30 +0000

I had the opportunity to attend the API Platform Con 2025 thanks to SensioLabs and here is what I learned through the talks I viewed.

Enhance your API Platform APIs with Go thanks to FrankenPHP (Kévin Dunglas)

Slides of this talk are available : https://dunglas.dev/2025/09/the-best-of-both-worlds-go-powered-grpc-for-your-php-and-api-platform-apps/

API Platform is celebrating its 10th anniversary this year, having been created on January 20, 2015. Originally a Symfony bundle, it is now usable with Laravel or even without any framework. With over 14,000 stars on GitHub and 921 code and documentation contributors, API Platform has become an essential tool for creating APIs.

Kevin highlighted that it has also been the starting point for many related projects such as Mercure and FrankenPHP, and many Symfony components were first developed for API Platform.

He also paid tribute to Ryan Weaver, a key contributor, and encouraged attendees to support his family through the GoFundMe "In memory of Ryan Weaver: For his son Beckett".

One Model, Many API Architecture Types

With API Platform, you can use the same DTO, the same code, and the same PHP class to generate different output formats with just a few configuration changes.

Here are some of the supported formats:

Hydra
OpenAPI
HAL
JSON:API
GraphQL
Mercure (SSE support)

This approach eliminates code duplication across different API format requirements.

Why gRPC is missing in API Platform

Currently, gRPC is not supported by API Platform. Here's why:

gRPC does not follow REST principles.
It is different from GraphQL.
It uses Protobuf (a binary format) instead of JSON for the output format.

Most of the time, in classic gRPC architecture, PHP is not a candidate.

However, gRPC has several advantages:

Fast and efficient
Strongly typed
Language agnostic: a code generator allows generating data structures in many languages.

Use cases for gRPC include:

Microservices
Internet of Things (IoT)
Critical components where performance is essential

How gRPC Works

gRPC operates on HTTP/2 and uses Protocol Buffer .proto files to define service contracts. These definitions enable automatic code generation across multiple programming languages. The binary serialization format provides more efficient data transmission than JSON, while HTTP/2's multiplexing supports high-performance communication.

Moreover, the official gRPC documentation recommends using non-PHP languages for gRPC servers due to PHP-FPM's request lifecycle limitations.

gRPC with FrankenPHP

Thankfully, FrankenPHP offers a way to write extensions in Go that can be exposed in PHP, making it possible to use gRPC with API Platform. The FrankenPHP gRPC extension is available on GitHub and is testable. It uses the Go gRPC server and is designed to be used with or without API Platform.

For more information on configuration and usage of this extension, please refer to the GitHub repository documentation.

Testing can be done with gRPCui. It is important to note that this solution is still experimental.

Extend Caddy Web Server with Your Favorite Language (Sylvain Combraque)

Caddy is a modern, fast, and easy-to-use web server that simplifies the process of serving websites and web applications. It is known for its automatic HTTPS configuration and simple syntax. Matt Holt, the creator of Caddy, has made significant contributions to the web server landscape with Caddy's unique features and ease of use.

Extending Caddy

Using xcaddy Build

Extending Caddy can be done using the xcaddy build tool, which allows you to customize and extend Caddy with plugins written in Go. This tool provides a straightforward way to add new functionalities to Caddy.

Using WebUI from Caddy Website

Caddy also offers a WebUI that can be accessed from the Caddy website. This interface provides an easy way to manage and configure your Caddy web server.

Extending Caddy with Go

For more detailed information on how to extend Caddy with Go, you can refer to the official documentation.

Using Interpreter

While using interpreters to extend Caddy has its advantages, there are also some drawbacks:

You need one interpreter per language.
New versions of the language require new interpreters.
Each interpreter is maintained separately.
You may need to re-implement types.

WASM x WASI x darkweak/wazemmes for Caddy Extension in Any Language

WebAssembly (WASM) is a binary instruction format that promises to enable programs to run at near-native speed on the web. The promise of "build once, run everywhere" makes WASM an attractive option for extending Caddy. However, the current documentation is not user-friendly, and there are some bugs to be aware of.

WebAssembly System Interface (WASI) is a system interface designed to allow WebAssembly modules to interact with the operating system in a secure and portable way. This combination of WASM and WASI allows developers to write code in their preferred language and compile it to WASM for execution in a browser or server environment.

For more information on using WASM and WASI in Caddy, you can check out the darkweak/wazemmes repository on GitHub.

Mercure, SSE, API Platform and an LLM Elevate a Chat(bot) (Mathieu Santostefano)

Slides of this talk are available : https://welcomattic.github.io/slides-real-time-ai-chatbot-with-mercure/1

Origin of the Subject

The initial customer need was to create paid expert chat exchanges. The first version used an API + React, but lacked message history. Mercure was chosen for secure message distribution to customers via JWT.

Evolved needs:

Assist experts with an AI assistant
Allow AI to handle the first part of the conversation
Allow experts to take over when needed

Toolbox

Mercure - Real-time Exchanges

Architecture:

Server => Hub => Client
Client => Hub => Client

SSE

Server-Sent Events (SSE) is a technology that allows a server to send real-time updates to a client via a persistent HTTP connection. The client listens to a stream of events sent by the server.

API Platform

LLM

Data generation and intelligent responses

Symfony Messenger

Asynchronous process management

Symfony AI

Equivalent to Mailer/Notifier but for AI providers:

Platform: unified interface for all AI providers
Agent: agentic AI creation
Store: data storage abstraction
MCP SDK: now officially supported by Anthropic
AI Bundle: full integration with Symfony
MCP Bundle: additional components

Implementation

Technical flow:
User => message => Mercure (Storage) <= Symfony SSE client => Symfony Messenger => Mistral => Mercure => AI response => User

Secure private chat via JWT (JSON Web Tokens) - an open standard for securely exchanging data between parties.

Sending a message to Mercure

fetch(this.hubURL, {
    method: 'POST',
    credentials: 'include', // Send JWT cookie
    body: new URLSearchParams({
        topic: topic,
        data: JSON.stringify(
            new MercureUpdateData(
                conversationId,
                msg,
            ),
        ),
        private: 'on' // restrict message to subscribed clients
    })
});

Connecting to Mercure

const eventSource = new EventSource('/sse-endpoint');
eventSource.onmessage = (event) => {
  console.log('New event received: ', event.data);
};

Symfony SSE Client

Built-in EventSourceHttpClient:

use Symfony\Component\HttpClient\Chunk\ServerSentEvent;
use Symfony\Component\HttpClient\EventSourceHttpClient;
use Symfony\Component\HttpClient\HttpClient;

$eventSourceClient = new EventSourceHttpClient(HttpClient::create());

$connection = $eventSourceClient->connect("YOUR-MERCURE-URL");

while (true) {
    foreach ($eventSourceClient->stream($connection, 2) as $r => $chunk) {
        if ($chunk->isTimeout()) continue; // Keep the connection alive.
        if ($chunk->isLast()) return; // Connection closed by server.
        if ($chunk instanceof ServerSentEvent) $this->processSSE($chunk);
    }
}

Dispatching messages with Messenger

use Symfony\Component\HttpClient\Chunk\ServerSentEvent;

function processSSE(ServerSentEvent $event): void
{
    $data = $event->getArrayData();

    // do some checks before asking LLM
    if (!$this->shouldProcessWithAi($data)) {
        return;
    }

    // Dispacth message to ask LLM
    $this->messageBus->dispatch(
        new ProcessAiResponseMessage(
            conversationId: $data['conversationId'],
            userMessage: $data['message'],
            sseMessageId: $event->getId(),
            timestamp: $data['timestamp']
        ),
    );
}

Symfony AI Configuration

YAML configuration of AI bundle with Mistral

ai:
    platform:
        mistral:
            api_key: '%env(MISTRAL_API_KEY)%'

    agent:
        default:
            platform: 'symfony_ai.platform.mistral'
            model:
                class: 'Symfony\AI\Platform\Bridge\Mistral\Mistral'
                name: !php/const Symfony\AI\Platform\Bridge\Mistral\Mistral::MISTRAL_LARGE

Handler Example

// Symfony AI Bundle code example
use Symfony\AI\Agent\AgentInterface;
use Symfony\AI\Agent\Chat;
use Symfony\AI\Platform\Message\Message;
use Symfony\AI\Platform\Message\MessageBag;
use Symfony\AI\Store\StoreInterface;

class MessageHandler
{
    public function __construct(
        private readonly AgentInterface $agent,
        private readonly StoreInterface $messageStore,
    ) {
    }

    public function __invoke(ProcessAiResponseMessage $message)
    {
        $chat = new Chat($this->agent, $this->messageStore, "UNIQUE_ID_TO_PROMPT");
        $messages = $this->messageStore->load("UNIQUE_ID_TO_PROMPT");

        if ($messages->count() === 0) {
            // retrieve system prompt from somewhere ...

            // Programmatic System prompt injection
            $chat->initiate(new MessageBag(
                Message::forSystem("SYSTEM_PROMPT_INJECTION"),
            ));
        }

        $llmAnswer = $chat->submit(Message::ofUser($message->userMessage));

        // do something with the answer
    }
}

In his final words Mathieu dedicated his talk in memory of Ryan Weaver, whose contributions continue to inspire the Symfony community. He also thanked Christopher Hertel for the Symfony AI initiative.

How API Platform 4.2 is Redefining API Development (Antoine Bluchet)

Slides of this talk are available : https://soyuka.me/api-platform-4-2-redefining-api-development/

Looking back at version 4.0:

610 commits
~200,000 lines of code
291 issues opened
230 issues closed

What's New in 4.2

Key features of this release:

FrankenPHP integration
State Options
Query parameters enhancements
Performance improvements
Laravel compatibility
PHP File Metadata

Metadata Enhancements

Metadata from PHP Files

New metadata system allows extracting API configuration directly from PHP files. It is not documented yet (AFAIK) but you can see the related PR of Loïc Frémont https://github.com/api-platform/core/pull/7017.

Metadata Mutator

A new way to programmatically modify metadata:

More flexible configuration
Runtime adjustments
Cleaner architecture

From API Filter to Parameters

API Filter Retrospective

The #[ApiFilter] attribute was doing a lot of things in the background, such as:

Declare services with filter tags
Generate documentation
Apply database operations
Work with multiple properties

This was confusing and also not respecting Single Responsibility Principle. That's the reason why API Platform maintainers have decided to rework that to Parameters.

Filter Documentation Improvements

Now documentations are generated separately. This can be done with two new interfaces

JsonSchemaFilterInterface
OpenApiParameterFilter

Filtering System

Now Filter are independent through a new FilterInterface with:

Simplified apply() method
No constructor requirements
Dependency-free design

Parameter System

The #[ApiFilter] attribute will leave his place to a new property of Operations attributes called parameters

New Filter Types

Free text search capabilities
URI variable provider

JSON Schema Enhancements

Some improvements were made on JSON Schema generation. Those changes could imply a backward compatibility break for tools using the former JSON Schema.

Improvements

Schema mutualization
30% smaller OpenAPI specification files
Reduced I/O operations

A new tool is now recommended : pb33f.io as it is more feature-rich and better maintained than Swagger UI.

Performance

Performance benchmarks comparing Nginx vs FrankenPHP:

More benchmarks available at soyuka.github.io/sylius-benchmarks/

JSON Streamer improvements:

~32.4% better request/second performance
Configurable via settings

State Options

New features for querying subresources:

More efficient data loading
Entity class magic (RIP Ryan)

Data Mapping

New mapping capabilities:

Database to API representation mapping
Symfony ObjectMapper integration
Better data transformation

Debugging

Profiling tools are back!

Backward Compatibility

Many new features added
No deprecations in this version
Parameters system is no longer experimental

Looking Ahead to API Platform 5.0

Planned changes:

#[ApiFilter] deprecation (migration script coming soon)
More JSON Streamer usage
Object Mapper feature requests
Community-driven improvements

Design pattern the treasure is in the vendor (Smaïne Milianni)

Slides of this talk are available : https://ismail1432.github.io/conferences/2025/apip_con/index.html

In this talk Smaïne made a tour on Design Pattern that are commonly used without any knowledge that they are in the vendors we use on a daily basis. He also showcased small and comprehensible code PHP snippets explaining some of them.

Among them were :

The Strategy Pattern
The Adapter Pattern
The Factory Pattern
The Builder Pattern
The Proxy Pattern
The Observer Pattern
The Event Dispatcher Pattern
The Decorator Pattern
The Facade Pattern
The Template Pattern
The Chain of Responsibility Pattern

Smaïne also ended with a shoutout to Ryan Weaver.

What if we do Event Storming in our API Platform projects ? (Gregory Planchat)

Event Storming

Event Storming is a collaborative workshop technique that brings together both users and developers in the same room. This methodology shines a light on misunderstandings that often exist between business stakeholders and technical teams.

The beauty of Event Storming lies in its simplicity: it uses physical post-it notes to encourage different team members to exchange ideas, see each other, share knowledge, meet face-to-face, and confront their understanding of the business domain.

Preparation

The Event Storming process follows a structured approach with several key steps:

List the events - Start by identifying all the significant events that happen in your business domain
Organize the events - Arrange these events in a chronological or logical order
Set up the commands - Identify what actions trigger each event
Set up the actors - Determine who or what initiates each command
Green post-its - Add the data necessary for users to make decisions
Add external systems - Include third-party systems that interact with your domain
Aggregates - Group related events and commands into cohesive business concepts

The team mentioned that they conducted multiple sessions "until no one had any more questions, whether from the technical team or the business team." It's a self-documenting process that can be repeated as the business evolves.

Advantages

Event Storming brings several concrete benefits to development teams:

Process documentation - The workshop naturally creates living documentation of your business processes
Facilitated onboarding - New team members can quickly understand the domain by looking at the Event Storming artifacts
Reveals uncertainties - Hidden assumptions and unclear requirements surface during the collaborative sessions

With API Platform

The Anemic Model Problem

Most applications suffer from what's called the anemic model anti-pattern, where:

Business logic is scattered across numerous services
Loss of user intention tracking
Entities become mere data containers with getters and setters

Typically, when you want to modify information in your entity, you call a setter method. This often happens across multiple services and classes, hence the "business logic disseminated in numerous services" problem.

The intention is essential for third-party systems to understand what actually happened in your application.

Rich Models

The alternative approach uses rich domain models that:

Require significant cost - More complex to implement initially
Require detailed application understanding - Team needs deep domain knowledge
Guarantee consistency over time - Business rules are enforced at the model level
Apply business constraints - Validation logic lives where it belongs
Centralize business logic - Everything related to a concept lives in one or two classes
The model guarantees integrity - Invalid states become impossible

With a rich model, all changes happen within the entity itself, keeping the business logic centralized and coherent.

The CRUD Problem

Traditional CRUD operations are:

Limited to 4 operations (Create, Read, Update, Delete)
SQL-centric thinking
Tools like PostgREST generate REST APIs automatically but provide little business value

To do better, we can leverage the power of API Platform's State Providers and State Processors.

But how do we preserve intention in our application?

The solution follows this flow:
Repository → EventBus → Event → Handler

Model Modification

The team implemented a pattern with three key methods in their entities:

recordThat() - Records that an event occurred (e.g., "a deployment was launched")
apply() - Applies the modifications related to the event (e.g., updates the deployment date)
releaseEvents() - A cleanup step that happens during the save process, just before persist/flush, then dispatches events throughout the application

This approach ensures that every business action is captured as a meaningful event, preserving the user's intention and providing a clear audit trail of what happened in the system.

Results

The team reported several concrete improvements after implementing this approach:

An API and codebase that better resembled the company's business domain
User intention was preserved throughout the application lifecycle
Better understanding of actions performed in the application, both for developers and business stakeholders

Scaling Databases (Tobias Petry)

Tobias Petry shared insights on database scaling strategies. His talk highlighted why scalability issues usually originate at the database level and walked through the most common solutions, their advantages, and their pitfalls.

Solutions

There is no silver bullet: every application has its own constraints. Still, several well-known strategies exist:

Find and fix slow queries

Before considering infrastructure, always check the basics. Tools like mysqlexplain.com can help detect inefficient queries and suggest improvements.
Cache results

Serving cached responses drastically reduces the load on the database and avoids repeating costly operations.
Vertical scaling (bigger machines)

Sometimes the simplest option is to scale up: move the database to a more powerful server. However, this approach quickly reaches physical and financial limits.
Multi-master replication

In this setup, several servers accept both reads and writes. It improves write scalability but creates the risk of conflicts when parallel writes occur. Conflict resolution strategies can mitigate this, but complexity grows with the number of nodes.
Read replication

Here, a single primary node handles writes, while replicas serve read queries.
- Synchronous replication ensures that changes are propagated to all replicas before acknowledging the write. This guarantees consistency but adds latency, as every replica must confirm.
- Asynchronous replication acknowledges the write immediately and updates replicas later. It reduces latency but risks temporary inconsistency between nodes. In practice, most applications tolerate eventual consistency. A cache layer in front of the primary often hides replication lag. Still, studies show that 90–98% of applications encounter latency issues if relying only on replicas for reads.
Sharding

Sharding distributes data across multiple databases. This enables theoretically infinite scalability. For example, users might be split across shards based on their ID.

The challenge comes with cross-shard queries: if you need to fetch all orders of a user across multiple shops, and users and shops are sharded differently, you must query several shards and aggregate results manually. Some companies even introduce shards of shards, adding another layer of complexity.

Because of this overhead, sharding is usually reserved for very large-scale systems. For most use cases, read replication is sufficient.

In general, these strategies are designed for CRUD workloads. Analytical queries (dashboards, reports) are harder to scale with a standard relational database. Developers can explore resources like sqlfordevs.com (free course on making analytics faster) or specialized systems such as TimescaleDB.

Sounds complicated

Tobias emphasized a crucial point: scaling decisions must be made before hitting database bottlenecks. Once data is structured and scaling strategies are in place, rolling back becomes almost impossible. Database architecture is one of those areas where it is far easier to make the right decision early than to correct mistakes later.

API Platform, JsonStreamer and ESA for skyrocketing API (Mathias Arlaud)

Slides of this talk are available : https://www.canva.com/design/DAGyYPxkygw/M1RzOiv8_cMp0Pa7Mh0u4g/view

Storytelling: imagine a bookstore. A customer orders all Symfony-related books. The bookseller tries to gather them all, but it's heavy—takes time, lots of books. The second time, the same request, but the pile is so large that the bookseller collapses under the weight.

In the API world, JSON is king.

At the heart of our stack is API Platform, which relies on Symfony’s Serializer. But sometimes the Serializer is like that bookseller: it works well until the load becomes too heavy.

Serialization / Normalization in Symfony

Serialization in Symfony (and in API Platform) involves turning PHP objects into arrays or scalar values, then encoding to formats like JSON or XML. Normalization transforms the internal object graph into a neutral data structure (arrays, scalars), applying metadata such as groups or attributes. Encoding then converts that structure into the final JSON string. The reverse process (denormalization) handles input JSON → arrays → objects.

When objects or collections are small, this works fine. But with thousands of items, large graphs, deep associations, and nested arrays, memory usage and time-to-first-byte degrade. Serialization becomes a bottleneck.

Streaming as a solution

Instead of building a huge in-memory structure, streaming emits JSON pieces incrementally. You only keep in memory what’s necessary at each moment.

Symfony 7.3 introduces the JsonStreamer component for that purpose.

Some key features:

Works best with POPOs (Plain Old PHP Objects) having public properties, without complex constructors.
The #[JsonStreamable] attribute can be used on classes to mark them as streamable. This also allows pre-generation of code during cache warm-up.
Use the TypeInfo component (link) to describe types of collections and objects (e.g., Type::list(Type::object(MyDto::class))). This helps JsonStreamer guess the shape of the output JSON without loading everything in memory.

Here is a code snippet from the Symfony documentation showing basic usage:

// Example class
namespace App\Dto;

use Symfony\Component\JsonStreamer\Attribute\JsonStreamable;

#[JsonStreamable]
class User
{
    public string $name;
    public int $age;
    public string $email;
}

// In controller
use Symfony\Component\JsonStreamer\StreamWriterInterface;
use Symfony\Component\TypeInfo\Type;
use Symfony\Component\HttpFoundation\StreamedResponse;

public function retrieveUsers(StreamWriterInterface $jsonStreamWriter, UserRepository $userRepository): StreamedResponse
{
    $users = $userRepository->findAll();
    $type = Type::list(Type::object(User::class));
    $json = $jsonStreamWriter->write($users, $type);
    return new StreamedResponse($json);
}

Benchmarks & comparisons

For a dataset of 10,000 objects:

Method	Time	Memory usage / footprint (rough / relative)
Serializer (traditional)	~ 204 ms	~ 16 MB (grows with size)
JsonStreamer	~ 87 ms	~ 8 MB (much more constant)

Challenges with metadata, JSON-LD and how API Platform adapts

API Platform adds metadata, JSON-LD contexts, property metadata, etc. That adds overhead in serialization. To integrate JsonStreamer while preserving rich metadata:

They use PropertyMetadataLoader extension points to provide metadata to JsonStreamer. This lets JsonStreamer know property names, whether they're exposed, etc., without traversing the full object tree in memory.

API Platform

Use of ValueTransformers that can transform any value at runtime. But caution: heavy logic in transformers can degrade performance (they run per value).

Symfony
+1

Use of ObjectMapper to convert entities (e.g., Doctrine objects) into POPOs (DTOs) that are suitable for streaming. This helps because entities often have lazy properties, proxies, relations etc., which complicate streaming.

ESA (Edge Side APIs) pattern

Edge Side APIs refers to breaking large JSON payloads into smaller, progressive calls or chunks, often delivered from the edge / CDN to improve perceived performance, especially in high latency/slow networks. In context of this talk:

Instead of sending one huge JSON structure, partition or paginate so the client can start receiving some data quickly.

Combine with streaming so that parts of the response start being delivered early (TTFB improves).

Good user experience: user sees something quickly rather than waiting for full load.

Takeaways

Serializer works, but for large data sets it becomes inefficient.

JsonStreamer gives significant improvements in both memory usage and time to first byte.

When you have metadata layers (API Platform, JSON-LD), use the extension points provided to plug streaming without losing features.

Avoid heavy computations / transformations in runtime‐hot paths (e.g., ValueTransformers).

Design your API knowing these options early, because once core serialization path is deeply embedded, changing is hard.

Benchmarks & comparisons

For a dataset of 10,000 objects:

Method	Time	Memory usage / footprint
Serializer (traditional)	~204 ms	~16 MB (grows with size)
JsonStreamer	~87 ms	~8 MB (much more constant)

Challenges with metadata, JSON-LD and how API Platform adapts

API Platform adds metadata, JSON-LD contexts, and property metadata. That overhead makes serialization heavier. To integrate JsonStreamer while keeping these features:

Use PropertyMetadataLoader extension points to provide metadata to JsonStreamer. This tells it which properties to expose, without traversing the full object tree.
Use ValueTransformers to adjust values at runtime. But beware: heavy logic here will degrade performance, since transformers run for every value.
Use ObjectMapper to convert entities (e.g., Doctrine objects) into POPOs (DTOs) that are easier to stream.

ESA (Edge Side APIs) pattern

Edge Side APIs (ESA) refers to breaking large JSON payloads into smaller, progressive chunks, often delivered from the edge or a CDN to improve perceived performance, especially in high-latency or slow networks.

In practice:

Instead of sending one huge JSON structure, partition or paginate so the client starts receiving data earlier.
Combine with streaming so that parts of the response arrive incrementally, improving time-to-first-byte.
The user experience is better: data appears quickly instead of waiting for everything.

Takeaways

Symfony’s Serializer is fine for small to medium datasets.
JsonStreamer provides significant improvements in memory usage and TTFB.
API Platform integrates it through extension points (PropertyMetadataLoader, ValueTransformers, ObjectMapper).
Avoid heavy runtime transformations for best performance.
Design your API with these options in mind early—serialization decisions are very difficult to change later.

Credits

Cover image by Nicolas Detrez

SymfonyLive Paris 2025 : Ce qu’il faut retenir

Thérage Kévin — Wed, 02 Apr 2025 11:53:54 +0000

J’ai eu la chance d’assister au SymfonyLive Paris 2025, et voici un résumé des annonces, conférences et tendances clés à retenir !

Retrouvez les slides sur ce merveilleux dépôt (Merci Romain Gautier🙏) : https://github.com/SymfonyLive/paris-2025-talks)

Keynote : Scaling to 0 (🎤 Fabien Potencier)

🚀 Qu'est-ce qu'un projet Open Source ?

Un projet open source, ce n'est pas seulement du code. Voici la hiérarchie des priorités :

Communauté
Documentation
Code

Une communauté active et une documentation solide sont essentielles pour assurer la pérennité d’un projet OS.

Avec le temps, Symfony a intégré une nouvelle priorité : l’expérience développeur (DX). La hiérarchie évolue donc ainsi :

Communauté
Documentation
Expérience développeur (DX)
Code

🏗️ Comment créer une application Symfony simple ?

Suite aux débats dans la communauté Laravel sur la complexité d’installation et la multitude de dépendances requises pour démarrer un projet, Fabien s’est posé la question :

"Quelle est l'application Symfony la plus simple possible ?"

En réponse, Symfony propose désormais trois nouveaux points d’entrée, permettant de commencer petit et d’évoluer progressivement.

🔹 Symfony Hello

Une version "Hello world" ultra-minimaliste de Symfony, offrant la puissance du full-stack framework avec une empreinte réduite.

Échelle	Taille d'équipe	Structuration	Conventions
Fichier unique	Solo dev	Aucune	Aucune

✅ Idéal pour :

Rapidité
Flexibilité
Prototypage (PoC) minimaliste
Projets personnels non maintenus

🔹 Symfony Solo

Symfony sans Flex, offrant un contrôle total sur l’architecture.

💡 Il permet un front controller CLI & HTTP grâce au composant Runtime :

$mode = PHP_SAPI === 'cli' ? 'console' : 'http';

Échelle	Taille d'équipe	Structuration	Conventions
Petits/moyens projets	Solo dev	Aucune (personnalisable)	Aucune (liberté totale)

✅ Idéal pour :

Commencer en toute légèreté
Scalabilité progressive (scale as you go)
Applications mono-tâche
Projets personnels avancés
PoC élaborés

🔹 Symfony Team

Le framework full-stack classique, conçu pour les projets de grande envergure.

Échelle	Taille d'équipe	Structuration	Conventions
Moyens à grands projets	Équipe de devs	Standardisée	Documentées

✅ Idéal pour :

Industrialisation
Travail collaboratif
Maintenance à long terme
Projets professionnels

⚙️ Un petit teaser à propos de Symfony 8

Disparition des fichiers XML pour la configuration des routes, désormais remplacés par des fichiers PHP.

🤖 Hot Takes sur les LLMs

Les LLMs ne remplaceront pas les développeurs.
Ce sont d’excellents stagiaires : disponibles 24/7, polis… mais parfois incohérents !
Très utiles contre le syndrome de la page blanche.
Claude s’avère particulièrement efficace pour la génération de code et de documentation.
Possibilité d’utiliser les LLMs pour :
- Mise à jour automatique du code (avec prudence).
- Documentation des PRs pour améliorer la revue de code.

Symfony ObjectMapper Component (🎤 Antoine Bluchet)

Après une partie d'historique sur l'arrivée du composant dans Symfony. Antoine a démarré par présenter le ce qui existait dans les autres langages et en PHP.

🏗️ Object Mapping dans d'autres languages

Spring : jackson
.Net : automapper
Java :
- modelmapper
- Java Map Struct
Ruby : Ruby Object Mapper (ROM)

🛠️ Etat du mapping en d'objet en PHP

Valinor : offre du mapping et bien plus (ce qui n'est pas une bonne chose selon Antoine)
Automapper (JoliCode) : Fonctionne sur le principe de génération de classe PHP pour mapper les objets
MicroMapper (SymfonyCasts) : version simpliste.
et bien d'autres

🎯 Mapping vs Hydratation

Hydratation : remplir un objet avec des données.
Mapping : transformer un objet en un autre objet.

💡 Contrairement au serializer, le mapping en PHP permet une meilleure séparation des responsabilités et une meilleure intégration avec Symfony.

Le composant

Le composant offre une approche simple via des attributs permettant de faire un mapping rapide via des attributs.

vous pouvez retrouver la Pull-Request ici

Exemple :

use Symfony\Component\ObjectMapper\ObjectMapper;
use Symfony\Component\ObjectMapper\Attributes\Map;

// This maps class `A` to class `B`.
#[Map(B::class)]
class A
{
    // This maps A::foo to B::bar.
    #[Map(target: 'bar')]
    public string $foo;

    // This calls ucfirst on A::transform
    #[Map(transform: 'ucfirst')]
    public string $name;

    // This doesn't map A::bar if it's value is falsy.
    #[Map(if: 'boolval')]
    public bool $bar = false;
}

$mapper = new ObjectMapper();
$mapper->map(new A);

PostgreSQL pour vos besoins NoSQL (🎤 David Buchmann)

Après une brève introduction et un rappel sur le fait que le NoSQL n'est pas clairement défini alternant entre base de donnée non-relationnel et le fait qu'une base de donnée relationnel permette aussi de stocker des élements sans relation, il a fait le tours des fonctionnalité de PostGreSQL et de MySQL (ce qui a été une petite surprise compte tenu du titre) permettant de stocker et de requête du JSON.

🔍 Type de colonne JSON vs JSONb

En PostGreSQL deux types de colonnes son proposés JSON et JSONb avec leurs avantages et leurs incovénients.

	Avantages	Inconvénients
JSON	Préserve l'ordre des clés dans l'objet	stocké sous forme de chaîne de caractères aucune optimisation des caractères répétés accepte du JSON invalide (garde les clés dupliquées)
JSONb	format binaire optimisé Performant pour les requêtes	Aucune mention faite

En dehors de cas d'utilisation non standard, il est préférable d'utiliser JSONB.

⚙️ Opérateurs utiles

Soit le JSON suivant :

{"author": "David"}

-> : extrait une information JSON. ie : renvoie "David"
->> : extrait une donnée native tout en etant 2.5 fois plus rapide. ie : renvoie David

L'opérateur -> existe aussi pour MySQL mais il faut préciser le JSONPath :
->'$.author'

Ajouter un index sur un champ json

Il est possible d'ajouter un index sur un champ JSON via l'instruction

CREATE INDEX name ON json_column ((json_column->>'author'));

Ce qui améliore le temps de requête considérablement.

Générer une colonne à partir d'une propriété JSON

Il est possible d'extraire et de générer une colonne à partir d'une propriété JSON via l'instruction

CREATE TABLE foo (
    # ...
    author VAR_CHAR(255) generated always as (json_column->>'author') stored,
    # ...
);

l'extraction d'une date est compliqué est nécessite de passer par une procédure stockée.

Fonctions utiles

contient :
- json_column @> '{"author": "David"}'
la clé existe :
- json_column ? 'author'
- jsonb_exists(json_column, 'author')
au moins une clé existe :
- json_column ?| array['author', 'it_does_not_exists']
- jsonb_exists_any(json_column, array['author', 'it_does_not_exists'])
toutes les clé existent :
- json_column ?& array['author', 'it_does_not_exists']
- jsonb_exists_all(json_column, array['author', 'it_does_not_exists'])

Passkeys pour une authentification fluide et sécurisée (🎤 Rémi Janot)

🔐 Problèmes des mots de passe

Créés dans les années 60, ils sont devenus vulnérables.
Brute-force, phishing, réutilisation…
HaveIBeenPwned révèle l’ampleur des fuites de données.

🔑 2FA / MFA

Réside sur 3 piliers :

Ce que l'on sait (mot de passe).
Ce que l'on a (téléphone, clé de sécurité).
Ce que l'on est (empreinte digitale, reconnaissance faciale).

🌍 WebAuthn

API JS, supportée par 96 % des navigateurs.
S'appuie sur les 3 piliers du 2FA / MFA

💻 Démonstration

La démonstration d'un intégration d'un système d'authentification WebAuthn a ensuite été présentée par Rémi avec une explication étape par étape de ce qui était transmis au serveur (payload JSON, request/response).

Retrouvez le dépôt du projet de démonstration ici

Symfony UX : Points forts de 2024 et perspectives d’avenir (🎤 Simon André)

5 ans après : où en est Symfony UX ?

👨‍💻 Symfony UX core team

Officialisation de la core team Symfony UX avec pour membres :

Ryan Weaver
Kévin Bond
Hugo Alliaume
Simon André
Mathéo Daninos

📌 Adoption

Utilisé par Symfony, EasyAdmin, PrestaShop, Sylius, SensioLabs, et même le ministère de l’Intérieur.

📊 Quelques chiffres

2022 → 800 000 téléchargements
2023 → 4 000 000 téléchargements
2024 → 1 500 000 téléchargements

Les packages UX les plus populaires :

95 000/semaine : Twig Component.
50 000/semaine : UX Icons.
40 000/semaine : Live Component.

🔮 UX en 2025

Typony Express : Création d'un jeu https://zty.pe/ entièrement avec Symfony UX comme une expérimentation et avec une documentation.
Refonte du site UX.
Un UX Bundle unique pour simplifier l’écosystème et l'ajout de nouveau "modules" UX.
UX v3 prévu pour l’été 2025.
Symfony 8 : retour à une synchronisation des versions.

Rôles & Permissions : Marque blanche et Feature Flipping (🎤 Florian Bogey)

Florian nous as montré comment Rôle et Permissions peuvent être utilisé de concert pour permettre la mise en place d'un marque blanche et d'un mécanisme de feature flag/flipping/toggle/whatever you may call something that activate or not a feature on your website.

🎭 Rôles vs Permissions

Rôle : catégorie utilisateur statique.
Permission : règle métier dynamique.

Symfony gère les permission via les Voters.
Il est possible de cumuler les attributs #[IsGranted()] pour différencier contrôles d'accès par les rôles des contrôles d'accès par permissions.

Exemple :

use Symfony\Component\Security\Http\Attribute\IsGranted;

final class FooController {

    #[Route('/foo/{id}', name: 'foo')]
    #[IsGranted('ROLE_ADMIN')]
    #[IsGranted('foo_voter', 'id')]
    public function __invoke(int $id): Response
    {
        // ...
    }
}

🗳 Voter

Les voters peuvent être configurés selon 4 stratégies :

Affirmative (par défaut) : Au moins un voter autorise l'action.
Consensus : nécessite de voter qui autorise l'action que de voter qui ne l'interdise.
Unanime : autorise l'action si aucun voter ne l'a interdite.
Priority : renvoie la décision du premier voter qui ne s'est pas abstenu en s'appuyant sur la priorité définie dans les services.

🏢 Gestion de clients exigeants

Deux besoins principaux :

Marque blanche → Identité visuelle, branding personnalisé.
Feature Flipping → Activer/désactiver des fonctionnalités par client.

💮 Marque blanche

Définition : La marque blanche est un modèle commercial qui permet à une entreprise de vendre des produits ou des services conçus par une autre entreprise sous sa propre marque.

Afin de pouvoir avoir une application "Multi-tenant" (comprendre un seul code source pour plusieurs marques/clients différents), Florian nous as expliqué qu'il était nécessaire que chaque dispose de sont propre fichier d'environnement.

C'est rendu possible grâce

l'ajout d'une variable d'environnement côté serveur web (SetEnv apache et set nginx)
une légère modification du front controller (le fichier public/index.php) de Symfony afin d'ajouter la logique permettant le chargement du bon fichier DotEnv.

(new DotEnv())->loadEnv(sprintf('%s/.env.%s', dirname(__DIR__), $context['APP_SOME_NAME']));

une extension TWIG pour transmettre les variables d'environnement nécessaire a TWIG.

🔄 Feature Flipping

Définition : Permettre d'activer/désactiver une fonctionnalité ou des partie d'une application sous certaines conditions.

Après une présentation de plusieurs alternative et bundle permettant un feature flipping, Florian a présenté la solution maison qu'ils ont mis en place chez GL Events (retrouver les slides de Florian ici.

Async avec Messenger, AMQP et Mercure

🔄 Rappel sur Messenger

Permet d’exécuter des tâches asynchrones.
Transports disponibles : sync, in-memory, AMQP…
Messages stockés dans une queue.
Gestion avec un superviseur (systemd, supervisord).

💡 Conseil : Pour les imports async, ne stockez pas les fichiers en BDD/queue, mais sur un disque partagé.

📡 Donner du feedback en temps réel (exemple : import)

❌ Mauvaises solutions

XHR Polling : inefficace.
WebSockets : complexe et lourd à maintenir.

✅ Solution moderne : Mercure

Surcouche à SSE (Server-Sent Events).
Full duplex et optimisé pour les updates en temps réel.
Installation via Composer.
Connexion JS via new EventSource() présent nativement dans les navigateurs.

🔐 Sécurité

Authentification JWT intégrée.
Publisher authentifié.
Subscriber anonyme ou non.

Symfony UX + Turbo + SSE

{{ turbo_stream_listen('csv:' ~ importId) }}

Permet de recevoir des mises à jour sans écrire une ligne de JS !

Atteindre la qualité d’une SPA avec HTMX et Twig

🌍 HTMX : une alternative aux SPA

Créé par Carson Gross en 2020.
50 KB, plus léger que jQuery.

🛠️ Fonctions principales

hx-get / hx-post : appels Ajax.
hx-trigger : changement d’événement (once, throttle, revealed…).
hx-target : où afficher la réponse Ajax.
hx-swap : méthode d’insertion (innerHTML, outerHTML, delete…).
hx-boost : transforme tous les liens en requêtes AJAX.

📌 Twig et animations CSS

Utilisation de renderBlock() pour ne rendre qu’un bloc spécifique d’un template.
Morphing des éléments via un ID conservé.

Du Lego de composants pour un bundle Gotenberg

📜 Génération de PDF en Symfony

Utilisation du bundle Gotenberg.
Permet de convertir HTML en PDF facilement.
Exemples et démonstrations disponibles sur Medium.

Symfony & Doctrine Migrations: Validation in CI

Thérage Kévin — Thu, 05 Sep 2024 10:13:59 +0000

I had the opportunity to work on a project with a team that was relatively new to Doctrine migrations. To help them get used to it, and to discard the possibility of having pull (or merge) requests with changes to doctrine entities without generating a migration.

Here is how I did it. I hope you'll enjoy it!

How Doctrine Migrations works

When generating the migration, Doctrine will make a delta between its mapping and the current schema of the database. With this delta in "mind" (dare I say 😉) it will generate a migration file with two main methods :

up applies the SQL commands to fill the gap between the current database schema and its mapping. Used to deploy changes in the schema of your database.
down allows to revert the migration with the SQL commands needed to "negate" the changes made in the up method. Used to roll back changes in the schema of your database.

The magic trick

There is currently no way to easily check if a migration has not been generated. Having this code merged could lead to a database schema being out of sync with your entity mapping and so resulting in a server error.

The keywords in the above description are migration files. I'll use the fact that, running the command bin/console doctrine:migration:diff will result in a newly generated file and will fail if there are no changes to apply.

Knowing the list of existing files before the execution of that command, and then running it, can let me know that there are changes that were not committed to a migration file in this pull (or merge) request.

Steps to do

Create your database
Run your existing migrations
Then run the step to check for missing changes (see below)

Advantages

Testing that your migrations does not fail
Ensure database schema consistency with Doctrine's mapping

You want the code snippet right!?

Here is the bash code :

#!/bin/bash

set -e
set -o pipefail

# run doctrine migration diff to check if there is a new migration file generated and check last exit code
if [[ -z $(bin/console doctrine:migrations:diff -n --quiet) ]]; then
    echo "Error ! bin/console doctrine:migration:diff found a new migration which must not be the case.";
    # cat last file (should be the newly generated one)
    cat $(ls -Art migrations/*.php | tail -n 1);
    # remove that file (just in case to comply with my paranoïac side)
    rm -f $(ls -Art migrations/*.php | tail -n 1);
    exit 1;
else
    exit 0;
fi

And that's it! You can now ensure that each pull (or merge) request has working migrations, with no pending changes left out of the migrations!

Ok but why not use `bin/console doctrine:schema:validate`?

The reason was that the project we were working on was using doctrine's schema_filter configuration to filter out some tables we did not want to deal with (project-related inconvenience).

The problem with bin/console doctrine:schema:validate was that it did not take care of the configuration, and so was dumping changes (trying to delete all the "normally" filtered out tables) not related to what we wanted.

A colleague told me that this is a known issue that might be fixed soon (https://github.com/doctrine/migrations/issues/1406).

Thank you for reading this article and please leave your comments if you have any questions!

Credits

Cover image: Unsplash by Ethan Weil

How to transform Component Development with Storybook and Symfony UX ?

Matheo Daninos — Mon, 17 Jun 2024 14:17:39 +0000

Hey everyone! I am so excited about this article because what I'm going to show you here has been my dream since I first heard about Symfony UX! I will demonstrate a setup that makes me incredibly productive, but most importantly, brings me a lot of joy.

As you know, I love working with components (TwigComponent/LiveComponent), and I also adore Storybook! In my last article, I showed you how to use Storybook to share your components with your team. Today, we're going to dive even deeper. Storybook has been a game changer for me primarily because it provides the best environment to work with components. Components are visual and interactive, and Storybook offers a fantastic playground to view, interact with, and test your components. It helps you create beautiful, interactive, fun, and robust components. So, let’s see how this works!

Working in isolation

If you remember from my first article, we discussed the four main rules of component architecture. One of these rules is independence. Your components should not depend on the context of the page; you should be able to move your component from one page to another without any issues.

The great thing about using Storybook is that it enforces this rule. Storybook operates by isolating each component, allowing you to test them one by one in complete isolation. This ensures that if your component works in Storybook, it will work seamlessly on all your pages.

Hot Reload

So when I am working on a new component, the first thing I do is create a story. A really basic one that just gives me the environment to start building.



import Alert from '../templates/components/Alert.html.twig';
import { twig } from '@sensiolabs/storybook-symfony-webpack5';

export default {
  component: (args) => ({
    components: {Alert},
    template: twig`
      <twig:Alert>
        {{ message }}
      </twig:Alert>
  `
  }),
}

export const Default = {}

Then I can just focus on creating my component. With hot reload, I get quick feedback, which makes things really comfortable for a visual component like an alert.

No need to press F5 anymore or try your component on random pages. Just write a story for your Storybook, and you will have a nice development environment.

Interactions

When working on a new feature, one of the most frustrating aspects can be having to interact with your component to access the part you want to test. For example, I have a small form here, and I want to see how it looks when the entered email is invalid.

Doing this manually can be a huge waste of time, especially for larger components. That's why I don’t do that anymore! With Storybook, you can automate your interactions to reach the exact state you want to test

How can I do that ?

First, I set up my Default story:



import Email from '../templates/components/Email.html.twig';
import { twig } from '@sensiolabs/storybook-symfony-webpack5';

export default {
  component: (args) => ({
    component: {Email},
    template: twig`
        <twig:Email/>
    `,
  })
}


export const Default = {}

Then, I add a new story called ‘WrongEmail’:



import Email from '../templates/components/Email.html.twig';
import { twig } from '@sensiolabs/storybook-symfony-webpack5';
import {userEvent, waitFor, within, expect, fn} from "@storybook/test";

...

export const Default = {}

export const WrongEmail = {
  play: async () => {
      ...
  }
}

In this story, I define a play function. This function contains snippets of code executed after the story renders, allowing you to interact with your components and test scenarios that would otherwise require manual intervention.

The play function looks like this:



import {userEvent, waitFor, within, expect, fn} from "@storybook/test";

play: async ({canvasElement}) => {
    const canvas = within(canvasElement);

    await userEvent.type(canvas.getByLabelText('Email'), 'wrongemail');
    await userEvent.type(canvas.getByLabelText('FirstName'), 'Kobe');
    await userEvent.type(canvas.getByLabelText('LastName'), 'Bryant');

    await userEvent.click(canvas.getByRole('button'));
  }

Storybook provides a wrapper around https://testing-library.com/.

If you are not familiar with this library, it is widely used in the JS community, very robust, and has a strong community around it, making it easy to find good resources.

So, if we get back to our play function, we see that we define an argument canvasElement. This canvasElement represents the canvas where our story is rendered.

Then we do the following:



const canvas = within(canvasElement);

Here, we wrap our canvas in an object to enable better assertions later.



await userEvent.type(canvas.getByLabelText('Email'), 'wrongemail');

This line simulates the user typing ‘wrongemail’ in the input with the label Email.

We do the same thing for the first name and last name:



await userEvent.type(canvas.getByLabelText('FirstName'), 'Kobe');
await userEvent.type(canvas.getByLabelText('LastName'), 'Bryant');

Then we click on the submit button:



await userEvent.click(canvas.getByRole('button'));

And just like this, Storybook will perform the interactions for me, so I no longer need to do all these steps by hand.

You can also easily debug what happens using the interaction panel and go back to previous steps.

I just love this feature—it saves me so much time. Components are visual and interactive, and having an environment that lets me see and interact with my components easily is a real game changer.

And you know what? We can do even more! We can use Storybook to test our components!

Testing

I have a component, RadioList, that displays a list of radios and a search bar. When the user types into the search bar, the component updates the list of radios accordingly.

I know the content of my database, so I want to ensure that when I type "90," four radios are displayed.

We already know how to do this by writing a play function and adding an assertion at the end.



import {twig} from "@sensiolabs/storybook-symfony-webpack5";
import {userEvent, waitFor, within, expect} from "@storybook/test";

export default {
  component: (args) => ({
    template: twig`
      <twig:RadioList />
    `
  }),
}

export const Default = {
};

export const Play = {
  play: async ({ canvasElement }) => {
    const canvas = within(canvasElement);

    await userEvent.type(canvas.getByRole('searchbox'), '90');

    await waitFor(() => {
      expect(canvas.queryAllByRole('listbox')).toHaveLength(4)
    });
  },
}

And just like that, I have a real test that fully tests my LiveComponent from PHP to JavaScript!

I can see that my test is working by checking the interaction panel. I now have a green "Pass" indicator.

We can go even further and run all our tests at once by running:



npm run test-storybook

What's interesting is that even simple stories with no interaction are tests. Storybook checks that all your components are rendered correctly. This is just a test runner, so you can completely run all your tests in your CI.

By leveraging Storybook for testing, you ensure a seamless and efficient development process, catching issues early and maintaining high-quality components.

Leveraging Storybook has transformed the way I develop and test components. From working in isolation to hot reloading, automating interactions, and writing comprehensive tests, Storybook provides a development environment that boosts productivity and fun. Although we still rely on Node.js, it’s not a big deal since Storybook is only used in your development environment and not deployed to production.

Components are often visual elements of your application, and maintaining a visual development approach greatly enhances the process. Storybook ensures that your components are robust, interactive, and beautifully designed. I hope you enjoyed this article and found it helpful. See you soon!

How to use the new Symfony Maker command to work with GitHub Webhooks

Maelan Le Borgne — Fri, 31 May 2024 07:14:51 +0000

Recently I've been working on a tool that would gather some open-source contribution metrics from our teams. We mostly focus on contributions on GitHub, so I started studying the API to see how I could get the relevant data I needed to process. If I wanted to get fresh data on a regular basis, I would have sent requests periodically. But polling API endpoints is not ideal, especially when the services you are accessing can come to you instead !

Enter Webhooks !

Webhooks are a pretty common way for services from the outside world to communicate with your own application. It is quite similar to the event subscriber in its design :

A remote service declares a list of steps in its lifecycle (for github: an issue has been opened, a comment has been made on a PR, ...), and for each of theses steps it will dispatch an event containing relevant data.
You can subscribe to any of these events, and you'll get notified when they are dispatched.

The main difference with your local event based system resides in the transport : events are sent over the network to a custom endpoint where you implement your own logic to handle the events.

Nowadays, Webhooks are widely used for a lot of different purposes (getting information on a mail delivery, get notified of the steps of a payment process, ...), and the process to create a webhook is somehow always the same :

Expose an endpoint.
Check if the request should be processed.
Check if the request if authorized and well formed.
Process the request.

To make things easier for developers, Symfony released the Webhook and RemoteEvent components in Symfony 6.3. The Webhook component focuses on making the creation of endpoint and validation of request easy, while RemoteEvent is about making the event's payload transit on Messenger and be handled by a RemoteEventConsumer, where your logic will live.

To install these components, run :



$ composer require symfony/webhook

How does this work ?

Okay, now we've installed the component, where should we start ?

First of all, let's set up our webhook so that we can effectively handle the requests that will be sent to us by GitHub.

At the time of writing, the component's documentation isn't fully released yet, so it may be a little bit confusing at first. But don't sweat : to make your life easier, a new Maker command was introduced !

To create a new Webhook, run :



$ symfony console make:webhook

The maker will ask you for the webhook name. It will be used to generate the webhook url (https://example.com/webhook/the_name_goes_here). Let’s call it “github”.

Next you'll be asked you for the RequestMatchers to use. For GitHub, we know that the events are sent via POST requests and the format is JSON, so we'll add MethodRequestMatcher and IsJsonRequestMatcher.

Now we can see that the command added some config to config/packages/webhook.yaml and created two files in our project source dir : src/Webhook/GithubRequestParser.php and src/RemoteEvent/GithubWebhookConsumer.
Hooray 🎉 ! Now we have some basis to work on.

Tweaking the code

Let's dive into the generated class src/Webhook/GithubRequestParser.php and see what changes we have to make to fit our needs.



<?php
// src/Webhook/GithubRequestParser.php
namespace App\Webhook;

use Symfony\Component\HttpFoundation\ChainRequestMatcher;
use Symfony\Component\HttpFoundation\Exception\JsonException;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\RequestMatcher\IsJsonRequestMatcher;
use Symfony\Component\HttpFoundation\RequestMatcher\MethodRequestMatcher;
use Symfony\Component\HttpFoundation\RequestMatcherInterface;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\RemoteEvent\RemoteEvent;
use Symfony\Component\Webhook\Client\AbstractRequestParser;
use Symfony\Component\Webhook\Exception\RejectWebhookException;

final class GithubRequestParser extends AbstractRequestParser
{
    protected function getRequestMatcher(): RequestMatcherInterface
    {
        return new ChainRequestMatcher([
            new IsJsonRequestMatcher(),
            new MethodRequestMatcher('POST'),
        ]);
    }

    /**
     * @throws JsonException
     */
    protected function doParse(
        Request $request,
        #[\SensitiveParameter] string $secret
    ): ?RemoteEvent
    {
        // TODO: Adapt or replace the content of this method to fit your need.

        // Validate the request against $secret.
        $authToken = $request->headers->get('X-Authentication-Token');
        if ($authToken !== $secret) {
            throw new RejectWebhookException(Response::HTTP_UNAUTHORIZED, 'Invalid authentication token.');
        }

        // Validate the request payload.
        if (!$request->getPayload()->has('name')
            || !$request->getPayload()->has('id')) {
            throw new RejectWebhookException(Response::HTTP_BAD_REQUEST, 'Request payload does not contain required fields.');
        }

        // Parse the request payload and return a RemoteEvent object.
        $payload = $request->getPayload()->all();

        return new RemoteEvent(
            $payload['name'],
            $payload['id'],
            $payload,
        );
    }
}

We can see that the RequestMatchers previously selected were added to a ChainRequestMatcher. We don't have anything else to do in this method 🥳.

Now in the doParse method, we see that three main steps are hinted by the comments :

Validating the request against the secret.
Check the request is well formed (mandatory fields are present, the expected format is respected ...).
Returning a remote event holding the payload.

GitHub has an interesting documentation on request validation, with some snippets in Ruby, JavaScript, Python ... but no PHP 😢. No worries, I made the translation for you :



$signature = $request->headers->get('X-Hub-Signature-256');  
if (!is_string($signature)  
    || !str_starts_with($signature, 'sha256=')  
    || !hash_equals('sha256='.hash_hmac('sha256', $request->getContent(), $secret), $signature)) {  
    throw new RejectWebhookException(Response::HTTP_UNAUTHORIZED, 'Invalid authentication token.');  
}

Now, for the validation : we're expecting a variety of events to knock at our webhook's door, so we won't be too strict on format validation.

To create a RemoteEvent we'll need a name (action) and an id. That will be our minimum requirements :



if (!$request->getPayload()->has('action') || !$request->getPayload()->has('number')) {  
    throw new RejectWebhookException(Response::HTTP_BAD_REQUEST, 'Request payload does not contain required fields.');  
}

Then all that's left to do is to create and return a RemoteEvent :



$payload = $request->getPayload()->all();  

return new RemoteEvent(  
    $payload['action'],  
    $payload['number'],  
    $payload,  
);

This event will be passed over to Messenger, that in turn will pass it to your GithubWebhookEventConsumer (thanks to the #[AsRemoteEventConsumer('github')] attribute on the class).



<?php
// src/RemoteEvent/GithubWebhookConsumer.php
namespace App\RemoteEvent;

use Symfony\Component\RemoteEvent\Attribute\AsRemoteEventConsumer;
use Symfony\Component\RemoteEvent\Consumer\ConsumerInterface;
use Symfony\Component\RemoteEvent\RemoteEvent;

#[AsRemoteEventConsumer('github')]
final class GithubWebhookConsumer implements ConsumerInterface
{
    public function __construct()
    {
    }

    public function consume(RemoteEvent $event): void
    {
        // Implement your own logic here
    }
}

Here is where you'll put your custom logic : mapping to DTO, persisting to database, ... whatever fits your needs.

Finally, head to config/packages/webhook.yaml and set up a secret (a random string of text with high entropy). This being sensitive data, it should be referenced here but stored in an environment variable (see Symfony documentation).



# config/packages/webhook.yaml

framework:

  webhook:

    routing:

      github:

        service: App\Webhook\GithubRequestParser

        secret: '%env(GITHUB_WEBHOOK_SECRET)%'

Call me back

Now that we're ready to handle requests, all we need to do is ask GitHub to send us some.
The official documentation is really good so we won't detail the process here. You'll need the endpoint url (https://example.com/webhook/github) and your secret. Just be aware that you can only create webhooks for resources that you own. If you want to be notified on actions performed on a repository you don't own, you'll have to ask the owner to set it up for you. If this is not an option, you'll have to rely on good old API polling.

Going further

Is that even useful ?

You may be tempted to say that all we've done is exposing an endpoint to process a request, and that it could have been done without the webhook component.
And you would be right : you can achieve the same result with a custom controller.

But let's see the benefits of doing it the way we did :

A single conf file with minimal and simple configuration for all our exposed endpoints.
A clean implementation of AbstractRequestParser to handle request authorization, validation and event dispatching.
Any service can be turned into a remote event consumer just by using #[AsRemoteEventConsumer] and ConsumerInterface.
A seamless integration with Symfony Messenger, Notifier, Mailer (and more to come).
All of the above was done by running a single command and writing less than 10 lines of code 🤯.

What's next ?

You may want to take a look at Github's Best practices for using webhooks .
That could make you want to :

Add an IpsRequestMatcher to check if the request is sent from one of GitHub's official IPs.
Use an async transport to reduce the request process time.
Handle re-deliveries
...

You may even want to contribute to Symfony by improving the component or the maker, creating a Bridge to spare some trouble to future developers, ... It's all up to you to make Symfony even better !

Tips : Local webhooks

When developing, you may want to receive requests to test your code. You'll need a webhook proxy for this. I would suggest using smee.io :

Start a new channel.
Copy the link to the "Payload URL" in the GitHub webhook configuration form.
Download the smee client on your local machine.
Run smee -u https://smee.io/thispartisrandom --port 8000 --path /webhhok/github *

*For a Symfony application running on localhost:8000

Accessing the smee url from your browser will allow you to visualize webhooks deliveries : headers, payload, ... and you'll be able to replay them.
You can take advantage of this and copy the payloads and headers to create fixtures to test your webhooks !

How to share your TwigComponent with your team ?

Matheo Daninos — Wed, 15 May 2024 20:40:21 +0000

Quick Reminders

This article follows my previous one. If you haven't read it yet, you can do so here: Symfony Can Help You Fall in Love with Your Front-End Team.

To give you context, we are developing a small application that lets you listen to various live radio stations.

We've adopted the principles from Component Architecture and, naturally, after designing various components of differing sizes and complexity, we are beginning to establish what is known as a design system.

Overwhelmed by All These Components?

It's common to feel overwhelmed as the number of components grows. In a team setting, or when developing new features, it's crucial to know what components are already available. When we create a new component, we want to share it immediately with our teammates.

So, how do we manage this?

Documenting everything? Yes, but it's time-consuming, and let's face it, we're developers—we tend to be a bit lazy.

But here’s some good news: there’s already a solution in the JavaScript world called Storybook!

What is Storybook?

Storybook is an exceptional tool for documenting components. It's specifically designed for this purpose, but it offers much more. It allows us to build components in isolation, test them, and mock them to see how they appear in different states or create specific end-to-end scenarios for each component, among many other features! And if you're still not convinced, just look at how beautiful your documentation can look with Storybook:

Here you can see an example of how I documented our Alert component. This documentation helps my teammates understand how to use the component and the different variations available.

Integrating Storybook with Symfony

Thanks to contributions from the community, you can now use the StorybookBundle for Symfony, developed by my friend Nicolas (not Grekas). I’m very excited about this release—not only because it involved a lot of work, but also because this bundle demonstrates that Symfony can match any front-end framework in capabilities.

To get started, install the bundle with Composer:



**composer require sensiolabs/storybook-bundle**

Then you can use the init command to configure everything for you.



bin/console storybook:init

Don’t run away! We gonna use npm but just to run the storybook. This will not have any impact to your project. And the bundle have an integration with AssetMapper, npm is just to start the storybook.



npm install

And to finish



npm run storybook

And just like that you are fully set up! You can go to: http://localhost:6006/ (it can be something else if your port is not available) to admire your storybook.

Write your first story

Let's get started! The first thing we want to do is show our Alert component in our Storybook.



import Alert from '../templates/components/Alert.html.twig';
import { twig } from '@sensiolabs/storybook-symfony-webpack5';

export default {
  component: (args) => ({
    components: {Alert},
    template: twig`
      <twig:Alert color="{{ color }}" size="{{ size }}" position="{{ position }}">
        {{ message }}
      </twig:Alert>
  `
  }),
  argTypes: {
    color: {
      options: ['blue', 'red', 'green'],
      control: {type: 'radio'},
    },
    size: {
      options: ['lg', 'md', 'sm'],
      control: {type: 'radio'},
    },
    position: {
      options: ['top-left', 'top-right', 'bottom-left', 'bottom-right'],
      control: {type: 'radio'},
    }
  }
}

export const Default = {
  args: {
    color: 'blue',
    size: 'sm',
    position: 'top-left',
    message: 'Hello world!'
  },
}

Let me explain what we have here:



import Alert from '../templates/components/Alert.html.twig';

We import our component template. Yes, this is Twig code, but thanks to the bundle, it works!



import { twig } from '@sensiolabs/storybook-symfony-webpack5';

Then we import a twig function that allows us to write Twig code directly in our JavaScript.



export default {
  component: (args) => ({
    components: {Alert},
    template: twig`
      <twig:Alert color="{{ color }}" size="{{ size }}" position="{{ position }}">
        {{ message }}
      </twig:Alert>
  `
  }),
  argTypes: {
    color: {
      options: ['blue', 'red', 'green'],
      control: {type: 'radio'},
    },
    size: {
      options: ['lg', 'md', 'sm'],
      control: {type: 'radio'},
    },
    position: {
      options: ['top-left', 'top-right', 'bottom-left', 'bottom-right'],
      control: {type: 'radio'},
    }
  }
}

Here is everything that is common to all stories related to our Alert component.

We have the component key that allows us to define our component, the Alert, and a template. We use the twig function, and everything inside can be any valid Twig code we want. Here, we simply render the Alert component and give this component props: color, size, and position.

Then we define some argTypes that allow us to describe the controls we want under the story.

Then we define our first story:



export const Default = {
  args: {
    color: 'blue',
    size: 'sm',
    position: 'top-left',
    message: 'Hello world!'
  },
}

And just like that, we have the following result!

You can play with the controls to test your component with different variations.

Then we can add more stories:



export const Large = {
  args: {
    color: 'blue',
    size: 'lg',
    position: 'top-left',
    message: 'Hello world!'
  },
}

export const Error = {
  args: {
    color: 'red',
    size: 'lg',
    position: 'top-left',
    message: 'Hello world!'
  },
}

export const Success = {
  args: {
    color: 'green',
    size: 'lg',
    position: 'top-right',
    message: 'Good job!'
  },
}

So now, if we look at the menu of our Storybook, we have three stories:

This is great, but we can go a bit further. Add the tags: ['autodocs'] to your export default:



export default {
  component: (args) => ({
    components: {Alert},
    template: twig`
      <twig:Alert color="{{ color }}" size="{{ size }}" position="{{ position }}">
        {{ message }}
      </twig:Alert>
  `
  }),
  ...
  tags: ['autodocs']

And just by adding this tag, Storybook creates a documentation page for us:

And if that's not crazy enough, you can create a .mdx file:



import {Canvas, Controls, Meta, Story} from "@storybook/blocks";
import * as AlertStories from "./Alert.stories";

<Meta of={AlertStories} />

# Alert

An Alert display information to the user.

<Story of={AlertStories.Default} />

Here are the properties you can use on the alert component:

<Controls of={AlertStories.Default} />

## Error

For error message you can use:

<Canvas of={AlertStories.Error} />

## Success

For success message you can use

<Story of={AlertStories.Success} />

As you can see in this .mdx file, we were able to import our stories into our documentation to make everything playable.

This is really cool! But you know what? This is only the beginning! We used Storybook to document a simple component, but Storybook can do much more. It can help with developing complex components or testing your components. We still have a lot to learn with Storybook, so stay tuned for the next article!

Thanks for reading. See you soon!

Symfony can help you fall in love with your front-end team!

Matheo Daninos — Thu, 11 Apr 2024 16:44:55 +0000

A little context

I'll place myself in the context of a Symfony application. We are a team of 8 developers: 6 dedicated backend Symfony developers and 2 frontend developers, including one who is a junior.
This shows that our team has a strong inclination towards backend development. The first thing not to do is to underestimate the frontend. Don't think that frontend development is easy; on the contrary, it requires expertise - an expertise that our backend developers lack.
Our goal, therefore, will be to take as much weight off the shoulders of our frontend developers as possible, without forcing backend developers to step out of their comfort zone.

The application I'll use for this example is as follows:

We have a set of radios, multiple pages with different radios, and if you click on any of them, then you can listen to a live stream of that radio.

Let's start working!

So, we start by making the first page and everything goes well. But as we proceed to the next one, we encounter our first problem. Our frontend developers simply reused the code from the first page on the next. They immediately encounter this error:

This is an error we're well acquainted with. We forgot to pass a variable to our Controller. Solving it is simple, but this error illustrates a deeper problem. Our frontend developer is dependent on our backend developers. Each time they make a new page, they have to ask the other developers to prepare a controller with the variables they need. We want to make our frontend independent. We aim to advance the project with as little friction between our backend and frontend devs as possible.

Component Architecture

For that, I propose that we cater to the frontend developers by using the component architecture. I won't go back over what component architecture is, but I invite you to read my article on this topic if you haven't already (https://dev.to/webmamba/how-to-integrate-component-architecture-into-symfony-4bjb).

So, we start by breaking down our page into many small components. Our list of radios will be a RadioList component composed of several Radio components. These Radio components are themselves made up of smaller components. To do all this, the frontend developer does not need us at all. They write anonymous component, component only made off a template:

RadioCard

<div
        class="
        transition ease-in-out delay-150 hover:-translate-y-1
        hover:scale-110 duration-300 aspect-square relative overflow-hidden
        rounded-lg bg-white/50 shadow-lg transition duration-300
        ease-in-out hover:shadow-2xl p-4"
>
    {% block content %}
    {% endblock %}
</div>

RadioCardImage

{% props logo, name %}

<div class="relative overflow-hidden border-slate-500/50 border rounded aspect-square">
    <div>
        <img
                class="w-full h-full object-cover self-center"
                src="{{ logo }}" alt="{{ name }}"
        />
    </div>
</div>

Radio

{% props radio %}

<twig:RadioCard>
        <twig:RadioCardBackground logo="{{ radio.logo }}" radio="{{ radio.name }}" color="{{ radio.color }}"/>
        <twig:RadioCardImage logo="{{ radio.logo }}" name="{{ radio.name }}" />
        <div class="absolute bottom-2 right-2">
                <twig:PlayerButton/>
        </div>
</twig:RadioCard>

I repeat, to make this list of components, the frontend did not need to write any PHP. They do all this work with complete autonomy.

Backend dev it's your time!

Once all these components are made to integrate our list of radios, the backend developers now only have to make a RadioList component, which has the following class:

<?php

namespace App\Twig\Components;

use App\Repository\RadioRepository;
use Symfony\UX\TwigComponent\Attribute\AsTwigComponent;

#[AsTwigComponent]
final class RadioList
{
    public ?string $filter = null;

    public function __construct(
        private readonly RadioRepository $radioRepository
    ) {}

    public function getRadios(): array
    {
        if ($this->filter === null) {
            return $this->radioRepository->findAll();
        }

        return $this->radioRepository->findByGenre($this->filter);
    }
}

But where it becomes really interesting is for the template, which will now only be this. All the work will have been pre-done by our frontend developers.

{% for radio in this.getRadios %}
    <twig:Radio :radio="radio"/>
{% endfor %}

This is great, we now have a working component able to communicate with our database, that anyone can reuse on every page. And all that while sticking to what we are good at, PHP code.

CVA

But we need to go a bit further. For example, for this site, we will need to set up an alert system. The informational alerts will be at the top left in blue, errors at the bottom in bold red, etc. We don't want a component for each variation; we want modular components.

For this in Symfony, we can use CVAs (Component Variant Attributes). Here's how it works:

{% props color, size, position %}

{% set alert = cva({
    base: 'min-w-96 absolute rounded-lg shadow-md bg-slate-200 text-white z-50',
    variants: {
        color: {
            'blue': 'bg-blue-800 shadow-blue-800',
            'red': 'bg-red-800 shadow-red-800',
            'green': 'bg-green-800 shadow-green-800',
        },
        size: {
            'sm': 'p-2 mb-2 text-sm',
            'lg': 'p-4 mb-4text-lg',
        },
        position: {
            'top-left': 'top-4 left-4',
            'top-right': 'top-4 right-4',
            'bottom-left': 'bottom-4 left-4',
            'bottom-right': 'bottom-4 right-4',
        }
    }
}) %}

<div class="{{ alert.apply({color, size, position})|tailwind_merge }}" role="alert">
    {% block content %}
    {% endblock %}
</div>

We create our Alert component. At the start of this file, we'll use the cva function. To this function, we'll pass a key array, the first key of which will be 'base' and will take as its value all the CSS classes that will be present in all variations of our components. Next, we'll define our variants. So here, variants on color, size, or position. Then, we'll apply our cva to the div of our alert.

And just like that, we've created a component with a multitude of possible variations.

So, quite naturally, we've been able to create a set of components of different sizes, with different variations, from which our developers can draw to implement new features. We have the beginnings of a design system. Working in this way allows our front-end and back-end developers to work without stepping on each other's toes, all while staying on a common codebase. Implementing a new feature is now picking between few components from our design system, we are dangerous!

Thank you for reading, see you soon for an article on how to document this design system!

How to integrate Component Architecture into Symfony?

Matheo Daninos — Fri, 15 Mar 2024 09:40:02 +0000

Miscommunication in our projects is costly. A single misunderstood User Story can result in 3 days of wasted development time. Additionally, when developers do not use the same programming language, it may be necessary to construct APIs to facilitate communication, which can also be expensive. It is important to consider why front-end developers may be hesitant to work with Twig and how this can lead to a disconnect between front-end and back-end development.

Front-end developers, like back-end developers, have their own set of habits, principles, and rules that make them feel safe, efficient, and at home.

One of the most important principles is Component Architecture, which serves as the foundation for major JavaScript frameworks such as Svelte, React, and Vue.

What is Component Architecture?

4 main rules define Component Architecture.

Composition

A page is no longer just a page, but rather a collection of small, reusable components. These components can be assembled to form a page. For example, there could be a component for the title and another for the training list. The training list component could even be composed of smaller components, such as a training card component. The goal is to create the most atomic components possible.

Independence

For a component to be infinitely reusable, it should not be aware of its context. It should function identically when placed on another page.

Properties

Our component must remain independent, but we can customize it based on the context. For instance, we can change the label of a button while keeping its appearance the same by assigning it properties. Properties are attributes that the component will adopt at creation and maintain throughout its life.

States

A component can have multiple states. For instance, a button can transition from an active state to a loading state and then to a disabled state. Typically, a state principle is used to achieve this. The difference between a state and a property is that a property remains constant throughout the lifespan of the component, while a state changes.

Does it work with Symfony?

The answer is yes!

Start by installing

composer require ux-twig-component

Then in your template folder, create a component folder. Inside the component folder, add a file named Button.html.twig.

<button class="btn btn-primary">Click me</button>

And just like that… you have created your first component! Congrats

Now, how will you use it? Let's assume you want to use it on your homepage. Open your home.html.twig template.

// the content of your template
<twig:Button/>

This way, you have successfully imported a component for the first time.

Can I include properties for this component?

Sure, you can! Simply go back to your button template and add a label property like this:

{% props label = 'Click me' %}

<button class="btn btn-primary">{{ label }}</button>

Now, our component has a label property, with a default value 'Click me'. Without this property, using the component would result in an error.

To assign a property to a component, follow these steps:

<twig:Button label="Submit"/>

How do we do composition?

If we want our component to contain an icon before our label, let's modify the template of our button.

{% props label = 'Click me' %}

<button class="btn btn-primary">
        {% block content %}
        {% endblock %}
        {{ label }}
</button>

So, I have added a block that I have named content. The term "content" is important because it corresponds to the default block.

You can now use your button in this way:

<twig:Button label="Submit">
    <twig:Icon/>
</twig:Button>

We added an Icon component to the Button component by placing it between the tags. This transfers the Icon component to the content block.

This block is a powerful tool for for precise composition. You can even create your own blocks.

{% props label = 'Click me' %}

<button class="btn btn-primary">
        {% block content %}
        {% endblock %}
        {{ label }}
        {% block after_label %}
        {% endblock %}
</button>

<twig:Button label="Submit">
    <twig:Icon/>
    <twig:block name="after_label">
            +
    </twig:block>
</twig:Button>

Note that we use the <twig:block tag to easily refer to the block of our component.

And what about the states of our component?

You have two options to manage the states of your component:

For the first option, if you want your component's CSS classes to change based on user actions, you can use Stimulus, a small JavaScript library that integrates perfectly with Symfony through the StimulusBundle. With just a few lines of JavaScript code, you can achieve your goal.
But imagine having a component with complex states that depend on the back-end. In this case, you have the option of using LiveComponents. I won't go into details, but here is what you need to remember: with very little code, you can perform complex actions on your back-end without reloading the page.

The present article is meant to give you an overview of how to use Component Architecture with Symfony. I know this article will be read mainly by back-end developers, but spread the word. It is suitable for both back-end and front-end developers. Even front-end developers can feel at home with Symfony. And you, back-end developers, you can continue to have fun while developing a quality front-end.

Thank you for reading!