I am a PHP/Symfony developer with over 9 years of experience in web development. Currently at SensioLabs, I have had the opportunity to work on various projects for demanding sectors: banks, public services, e-commerce and French press.

My specialization in Symfony (certified Expert on versions 6 and 7) allows me to work on complex architectures, critical migrations and large-scale technical overhauls. I particularly enjoy technical challenges that go beyond the usual scope: Domain-Driven Design, AWS Lambda deployments, integrations with technologies like ElasticSearch, Redis or RabbitMQ.

My journey

My experience has been built around ambitious technical projects. I have notably participated in the multi-year overhaul of a major French bank's intranet, developed DDD backend applications hosted on AWS Lambda for a major press publisher, and supported the progressive migration of critical platforms for public services.

This diversity of contexts has allowed me to develop solid technical expertise, but also an ability to adapt to complex environments and specific business constraints. Whether it's modernizing legacy systems, designing robust APIs or optimizing performance on high-traffic applications, I enjoy taking on technical challenges that require creativity and rigor.

My vision of development

I believe that code quality and collaboration are the foundations of a job well done. Each project is an opportunity to learn, share and improve my practices. I attach particular importance to technical design freedom, which allows proposing solutions adapted to real needs rather than standardized responses.

Mutual aid between developers and knowledge sharing are an integral part of my way of working. It is in this spirit that I regularly share my thoughts and feedback through technical articles on this site. My goal is to contribute to a technical community where everyone can progress and flourish.

When working with Git, it's common to use .gitignore to exclude files and directories. But sometimes, even well-intentioned rules can lead to unexpected behavior—especially when dealing with nested directories. In this post, I'll walk through a real-world example of how a .gitignore rule intended to keep a project clean ended up hiding important files, and how we fixed it.

The Setup

I wanted to keep the .tools/ directory clean, tracking only composer.json, composer.lock, and the .gitignore file itself. My initial .tools/.gitignore looked like this:

*
!.gitignore
!composer.json
!composer.lock

Goal: Track only composer.json, composer.lock, and .gitignore in .tools/ and its subdirectories, ignoring everything else.

The Problem

After pushing this change, a colleague reported that their composer.lock file in .tools/rector/ was being ignored. We used the following command to debug:

$ git check-ignore -v .tools/rector/composer.lock
.tools/.gitignore:1:*     .tools/rector/composer.lock

Root Cause

Git's rule: "It is not possible to re-include a file if a parent directory of that file is excluded."

The * pattern ignores both files and directories, which means Git never even looks inside .tools/rector/—so the whitelist rules for composer.json and composer.lock never apply.

The Solution

After debugging, we updated the .gitignore to explicitly allow directory traversal and re-include the necessary files:

# Ignore all files and directories at this level
*

# But allow Git to inspect subdirectories
!*/

# Explicitly ignore vendor directories
vendor

# Whitelist composer.json in any subdirectory
!*/composer.json

# Whitelist composer.lock in any subdirectory
!*/composer.lock

# Always keep this .gitignore file
!.gitignore

Key Takeaways

• Git's Directory Traversal: When you use * to ignore everything, Git won't look inside directories unless you explicitly allow it with !*/.
• Testing Your Rules: Always test your .gitignore with git check-ignore -v <file> and git status to ensure the expected files are tracked.
• Order Matters: Place general exclusions first, then re-include specific files or directories.
• Common Pitfalls: Remember to re-exclude directories like vendor after whitelisting, or they'll be included in your repository.

Conclusion

Debugging .gitignore issues can be tricky, but understanding how Git evaluates directory traversal and pattern matching makes it much easier. Always test your rules with nested directories before committing, and don't hesitate to use git check-ignore to verify your setup.

Table of contents :

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:

1. List the events - Start by identifying all the significant events that happen in your business domain
2. Organize the events - Arrange these events in a chronological or logical order
3. Set up the commands - Identify what actions trigger each event
4. Set up the actors - Determine who or what initiates each command
5. Green post-its - Add the data necessary for users to make decisions
6. Add external systems - Include third-party systems that interact with your domain
7. 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:

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:

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

Table of contents :

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:

1. Represent the API based on business needs - Focus on what the business actually does
2. Translate into entities and workflows - Convert business processes into technical implementations
3. Write only the necessary code - Keep it simple initially
4. Then optimize and refactor - Improve performance and code quality
5. Iterate - Continuously improve based on feedback
6. 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

1. Decoration of API Platform provider - Use the decorator pattern to wrap existing providers with feature flag logic
2. 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:

1. Downloading the source code.
2. Compiling it with phpize and make.
3. Adding a line to php.ini to enable it.
4. 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?

1. To react properly to a precise issue:

   • Retrying a token.
   • Handling distributed system failures.
   • Fixing configuration issues.

2. 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:

1. Errors that belong to your domain: you own them, so enrich them with context.
2. Errors that don’t belong to your domain but still happen: wrap them with a code and enrich them.
3. 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

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

Disclaimer

We are the 10th of July 2025 now and this article is outdated due to the merge of the Pull Request https://github.com/doctrine/migrations/issues/1406 and so running bin/console doctrine:migrations:up-to-date shall now take care of schema_filter configuration.

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 :wink:) 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

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

Advantages

1. Testing that your migrations does not fail
2. 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!

TL;DR: You just want the code (I perfectly understand that 😉)? Scroll to the piece of code.

What was my need regarding HTTP calls?

I needed to have a quick idea of how the application cache system I’ve placed on an HTTP endpoint was performing, and I wanted it to be quick and simple.

With my notions of Shell and basic knowledge of Curl (a small gift from a colleague: you can find a Curl cheatsheet here), I knew that I could easily run a hundred times the same HTTP call and get the total time as a result.

This solution is a simple short solution that fits my needs which was to locally test my HTTP endpoint. If you plan to do real performance/load testing on real servers like staging or production ones then you shall take a look at tools like (https://jmeter.apache.org/)[Apache JMeter], (https://gatling.io/)[Gatling], or other similar tools.

How Curl helped me test my HTTP call?

So I opened my terminal and ran:

for i in {1..100}; do curl 'https://some-domain/some-uri/some-path?cache=false' \
-H 'cache-control: no-cache' \
-H 'pragma: no-cache' \
--compressed \
--insecure -s -o /dev/null -w "%{time_total}s\n";
done

# Which printed :
0.057703s
0.067895s
0.063033s
0.062455s
0.074864s
...

For some explanations, I copied the request sent by my browser as a Curl request (this could be easily done on most browsers see (https://quickref.me/curl)[here]) and wrapped it in a for loop which is running that HTTP call a hundred times.

The only change I made to the Curl request was to add the options -s for a quiet output, -o /dev/null to avoid having the response body printed and the most important one -w "%{time_total}s\n" which allows me to format Curl’s output to return the total time. You can have a full list of available “Write out variables” (https://everything.curl.dev/usingcurl/verbose/writeout.html#available-write-out-variables)[here].

And that’s it 🎉 ! You can have a quick performance idea only with the tools you may already use.

I hope you’ll find it helpful!

Please feel free to leave your comments or questions below.

Short Introduction

You may not know what is Postman, so I'll describe it to you. You may use any IDE (like PHPStorm, VSCode,…) to help you during the development phase of your project with things like autocompletion, test runs, debugging, and so on.

Postman is quite the same as an IDE but designed especially to create APIs calls. It's a lot more pleasant to use than the plain old curl command. Learn more about Postman by visiting their website https://www.postman.com/.

What about JSON Web Tokens (shortened to JWT in the rest of this article)? JWT is an open-source industry standard that defines a self-contained (i.e. information are held by the token) way for securely transmitting information between parties as a JSON object. In our case, they'll be used to give us access to an API. Learn more about JSON Web Tokens by visiting their website https://jwt.io/.

The journey to this magical world

In the begining, was the manual request

As a Web Developer, I'm used to call APIs (mine or third party APIs) that requires a JWT, and I usually test them using Postman. For many months, or maybe years, calling an endpoint on those kinds of APIs led me to manually apply the following workflow:

1. Get a token through a saved request attached to my Postman collection (basically authenticating toward my API)
2. Copy the token string
3. Create an "Authorization" header
4. Paste the token string as a "Bearer" token as value for my "Authorization" header (header example: "Authorization:Bearer pastedTokenString")
5. Finally, request my endpoint

This workflow also had me to update manually the JWT token when it has expired. By the time, I got a bit smarter by using Postman's environment variables in order to have the right token string stored in the proper environment (like having a JWT for the staging environment and one for the production).

But some months ago I was wondering if, as lazy as I am, there was a better way to make it? I also heard legends about some dev who calls his API calls without worrying about Authentication. So why not me?

Then was the automatic request

So like any good (or not 😛) developer, my journey has started on… (already guessed it 😉?) Stack Overflow!

I found this article there, and even if it was not the right solution, it gave me a clearer idea of where to search. In fact, and to be honest, I was searching for a piece of code that I could quickly copy and paste eyes closed 😅.

So I continued my quest, and I found Utkarsha Baksh's medium article "Using Postman Pre-request Script to Automatically Set Token" which has a perfect (and not too long) step by step tutorial. It details how to make a simple automatic login request before calling the desired API endpoint using small Postman's pre-request script. If you are new to that "pre-request script" concept, really shall read this article or take a look at Postman's documentation.

Amazing plus, there's a piece of code! So I copy/pasted it, followed the steps, adapted it to my use cases, and it worked 🎊 🎉 🪩!

I never got back on it until… I lost this pre-request script because of a Postman reinstallation and not having a paid version 🫣 😩.

This leads us to this day (2022/12/12 😉) where I was again doing the same manual routine and remembered that good old time when it was automatic.

Finally was the consecration

So another time, I packed my bag and got again on that journey to that wonderful land. The trip was a lot faster that time 😅 and I found a new piece of code that looked more detailed and more respectful of JWT's refresh mechanism by not always authenticating toward the API when the token is still valid (I mean not expired).

This code could be found there: https://gist.github.com/Glideh/0f24b8973bb7d79ae8124fa160966df1

The only cons I've found using it directly is that it was not taking advantage of the JWT's refresh token. So I copy/pasted it and made some changes to allow an automatic refresh of the token.

The code

To get a full tutorial on how to define a the following code as a Postman's pre-request script read Utkarsha Baksh's medium article: "Using Postman Pre-request Script to Automatically Set Token"

/**
 * fill in the blanks
 */
const TOKEN_ENV_VAR_NAME = 'token_client'
const LOGIN_URL = pm.environment.get("host") + "/api/v2/authenticate"
const LOGIN_BODY={
    "app_id": pm.environment.get("app_id"),
    "app_secret": pm.environment.get("app_secret")
}

const REFRESH_TOKEN_ENV_VAR_NAME = 'refresh_token_client'
const REFRESH_URL = pm.environment.get("host") + "/api/v2/authenticate/refresh"
const REFRESH_BODY={
    "refreshToken": pm.environment.get(REFRESH_TOKEN_ENV_VAR_NAME)
}

function isExpiredToken() {
    const jwt = pm.environment.get(TOKEN_ENV_VAR_NAME)
    const payload = JSON.parse(atob(jwt.split('.')[1]));
    // Expiration timestamp (in seconds) is located in the `exp` key
    const millisecBeforeExpiration = (payload.exp * 1000) - (new Date()).getTime();
    if (millisecBeforeExpiration <= 0) {
        console.log("Token is expired");
        return true;
    }

    console.log(`Token is still valid ! Expiring in ${millisecBeforeExpiration / 1000} seconds`);
    return false;
}

function tokensExists() {
    const token = pm.environment.get(TOKEN_ENV_VAR_NAME)
    const refreshToken = pm.environment.get(REFRESH_TOKEN_ENV_VAR_NAME)
    if (!token) {
        console.log("Token not found");
        return false;
    }

    if (!refreshToken) {
        console.log("Refresh token not found");
        return false;
    }

    return true;
}

function login() {
    console.log("Authenticating")
    const body = JSON.stringify(LOGIN_BODY);
    const request = {
        url: LOGIN_URL,
        method: "POST",
        header: {
            "Content-Type": "application/json",
            "Accept": "application/json",
        },
        body,
    };

    pm.sendRequest(request, (err, res) => {
        if (err || res.code !== 200) {
            console.log("Login failed:");
            console.log(err);
            console.log(res);

            throw new Error('Login failed, check postman\'s console for details')
        }
        pm.environment.set(TOKEN_ENV_VAR_NAME, res.json().token);
        console.log("Token saved");
        pm.environment.set(REFRESH_TOKEN_ENV_VAR_NAME, res.json().refreshToken);
        console.log("Refresh Token saved");
    });
}

function refresh() {
    console.log("Refreshing token")
    const body = JSON.stringify(REFRESH_BODY);
    const request = {
        url: REFRESH_URL,
        method: "POST",
        header: {
            "Content-Type": "application/json",
            "Accept": "application/json",
        },
        body,
    };

    pm.sendRequest(request, (err, res) => {
        if (res.code === 498) {
            console.log('Refresh token has expired or is invalid')
            login()
            return
        }
        if (err || res.code !== 200) {
            console.log("Refreshing token failed:");
            console.log(err);
            console.log(res);

            throw new Error('Refreshing token failed, check postman\'s console for details')
        }
        console.log("Token refreshed");
        pm.environment.set(TOKEN_ENV_VAR_NAME, res.json().token);
    });
}

if (tokensExists()) {
    if (!isExpiredToken()) {
        return
    }

    refresh()
} else {
    login()
}

Thanks

Postman for producing tools that ease API developer's life

Stack overflow and his community for being the developer's life-buoy

Pierre de LESPINAY for the Gist that inspired me this piece of code and the current article

SensioLabs' Team for their help and their reviews on this article