January 18, 2019January 18, 2019 by Kévin Dunglas

API Platform 2.4: MongoDB, Elasticsearch, Mercure, OpenAPI v3, CQRS with Symfony Messenger, HTTP/2 Push, improved React apps and more!

API Platform, PHP, Programmation, Symfony
API Platform, CQRS, Elasticearch, Mercure, MongoDB, OpenAPI, React, ReactAdmin, Symfony, Vue.js
Leave a comment

I’m pleased to announce the immediate availability of API Platform 2.4 beta! This new version is a huge one, that comes with a large set of new features.

For newcomers, API Platform is a full-stack framework to develop in a breath high quality API-driven projects. Among other (lower level) libraries, API Platform provides:

a modular and fully-featured API library built on top of the Symfony components
a beautiful admin interface dynamically generated from the API specification, built using React and React Admin
a client generator to scaffold React/Redux, React Native and Vue.js apps from the API spec

API Platform supports modern REST formats (JSON-LD/Hydra, JSONAPI, OpenAPI, HAL…) as well as GraphQL.

To create your initial project, you just have to describe the public structures of the data to expose through the API. API Platform will take care of exposing the web API and bootstrapping the clients to consume it: get started with API Platform.

Version 2.4 introduces a lot of very interesting new features. Here is the curated list:

Read and write support for MongoDB, the reference document database, including a lot of useful filters
Read support for Elasticsearch, the open source search and analytics engine, including filters for advanced search
Automatic “push” of updated resources from the server to the clients using the brand new Mercure protocol
Integration with the Symfony Messenger component to easily implement the CQRS pattern and to handle messages asynchronously (using brokers such as RabbitMQ, Apache Kafka, Amazon SQS or Google PubSub)
Ability to leverage the “Server Push” feature of HTTP/2 to preemptively send the relations of a requested resource to the client
Automatic availability of list filters in the React-based admin when a corresponding one is available API-side
Full compatibility with the version 3 of the OpenAPI specification format (formerly known as Swagger), and integration of the beautiful ReDoc documentation generator
Improved DTOs support
Per resource configuration of HTTP cache headers
Ability to easily use the Sunset HTTP header to advertise the removal date of deprecated endpoints

The full changelog is available on GitHub.

Let’s dive into these new features!

MongoDB support

MongoDB is one of the most popular NoSQL database. Native support for MongoDB was the most requested, and the most awaited API Platform feature! Sam Van der Borght started the work in March 2016. In July 2017 the Pull Request has been ported to API Platform v2 by Pablo Godinez helped by Hamza Amrouche (API Platform Core Team), Alexandre Delplace and others. Finally, since August 2018 Alan Poulain (API Platform Core Team and author of the GraphQL subsystem) produced a huge effort to finish and polish the patch.

With 114 commits and 234 files changed over almost 3 years. This is one of the biggest contributions to the project.

The MongoDB integration relies on Doctrine MongoDB ODM 2.0 (currently in beta). To enable this feature, just install and configure DoctrineMongoDBBundle. API Platform will autodetect it. Then, create a class mapped with MongoDB, and mark it as an API resource:

namespace App\Document;

use ApiPlatform\Core\Annotation\ApiResource;
use Doctrine\ODM\MongoDB\Mapping\Annotations as ODM;

/**
 * @ApiResource
 * @ODM\Document
 */
class Book
{
    /**
     * @ODM\Id(strategy="INCREMENT", type="integer")
     */
    public $id;

    /**
     * @ODM\Field(type="string")
     */
    public $title;
}

namespace App\Document;

use ApiPlatform\Core\Annotation\ApiResource;

use Doctrine\ODM\MongoDB\Mapping\Annotations as ODM;

/**

* @ApiResource

* @ODM\Document

class Book

{

/**

* @ODM\Id(strategy="INCREMENT", type="integer")

public $id;

/**

* @ODM\Field(type="string")

public $title;

}

The support for MongoDB leverages the flexibility of API Platform: it has been implemented as a data provider and a data persister. Relations, pagination as well as boolean, date, numeric, order, range and search filters are also supported!

A big thanks to all contributors of this amazing feature, and to Andreas Braun, the maintainer of Doctrine MongoDB ODM, for the in-depth reviews!

Elasticsearch support

Elasticsearch is another very popular open-source data store. It allows to perform full-text searches and advanced analyzes on very large datasets. Orange has sponsored the development of an Elasticsearch data provider for API Platform, as well as some interesting search filters. The implementation has been realized by Baptiste Meyer (API Platform Core Team). Thanks to Orange, this feature is now available for everybody in API Platform 2.4.

To enable and configure the Elasticsearch support, refer to the official documentation. Then, a simple resource class corresponding to an Elasticsearch index is enough to benefit from the full power of API Platform:

namespace App\Model;

use ApiPlatform\Core\Annotation\ApiProperty;
use ApiPlatform\Core\Annotation\ApiFilter;
use ApiPlatform\Core\Annotation\ApiResource;
use ApiPlatform\Core\Bridge\Elasticsearch\DataProvider\Filter\MatchFilter;

/**
 * @ApiResource
 */
class Tweet
{
    /**
     * @ApiProperty(identifier=true)
     *
     * @var string
     */
    public $id;

    /**
     * @var User
     */
    public $author;

    /**
     * @var \DateTimeInterface
     */
    public $date;

    /**
     * @ApiFilter(MatchFilter::class)
     *
     * @var string
     */
    public $message;
}

namespace App\Model;

use ApiPlatform\Core\Annotation\ApiProperty;

use ApiPlatform\Core\Annotation\ApiFilter;

use ApiPlatform\Core\Annotation\ApiResource;

use ApiPlatform\Core\Bridge\Elasticsearch\DataProvider\Filter\MatchFilter;

/**

* @ApiResource

class Tweet

{

/**

* @ApiProperty(identifier=true)

* @var string

public $id;

/**

* @var User

public $author;

/**

* @var \DateTimeInterface

public $date;

/**

* @ApiFilter(MatchFilter::class)

* @var string

public $message;

}

Then, you can use an URL such as /tweets?message=foo to search using Elasticsearch.

Keep in mind that it’s your responsibility to populate your Elastic index. To do so, you can use Logstash, a custom data persister or any other mechanism that fits for your project (such as an ETL).

Baptiste also took this opportunity to improve the code handling the pagination. It is now a generic class used by all native data providers (Doctrine ORM, MongoDB and Elasticsearch), that you can reuse in your own.

Read and improve the Elasticsearch related documentation.

Real time update of client with Mercure

Mercure is a brand new protocol built on top of HTTP/2 and Server-sent Events (SSE). It’s a modern and high-level alternative to WebSocket (WebSocket is not compatible with HTTP/2). Mercure is especially useful to publish updates of resources served through web APIs in real time. It is natively supported by modern browsers (no required library nor SDK) and is very useful to update reactive web and mobile apps.

In version 2.4, I added Mercure support to the server component of API Platform and to the React and React Native app generators. The Docker Compose setup provided with API Platform has also been updated to provide a Mercure hub.

Configuring the framework to automatically dispatch updates to the currently connected clients is straightforward:

namespace App\Entity;

use ApiPlatform\Core\Annotation\ApiResource;

/**
 * @ApiResource(mercure=true)
 */
class Book
{
    // ...
}

namespace App\Entity;

use ApiPlatform\Core\Annotation\ApiResource;

/**

* @ApiResource(mercure=true)

class Book

{

// ...

}

Thanks to the auto-discoverability capabilities of Mercure, the generated clients will automatically subscribe to updates, and render them when received:

Read and improve the Mercure subsystem documentation.

CQRS and async message handling with Symfony Messenger

Messenger is a new Symfony component created by Samuel Roze (Symfony and API Platform Core Team). It allows to dispatch messages using message queues (RabbitMQ, Kafka, Amazon SQS, Google PubSub…) and to handle them asynchronously. It provides a message bus that is very useful to implement the CQRS design pattern.

In API Platform 2.4, I added a convenient way to leverage the capabilities of Messenger. This new feature is particularly useful to create service-oriented (RPC-like) endpoints:

namespace App\Entity;

use ApiPlatform\Core\Annotation\ApiResource;
use Symfony\Component\Validator\Constraints as Assert;

/**
 * @ApiResource(
 *     messenger=true,
 *     collectionOperations={
 *         "post"={"status"=202}
 *     },
 *     itemOperations={},
 *     outputClass=false
 * )
 */
class ResetPasswordRequest
{
    /**
     * @var string
     *
     * @Assert\NotBlank
     */
    public $username;
}

namespace App\Entity;

use ApiPlatform\Core\Annotation\ApiResource;

use Symfony\Component\Validator\Constraints as Assert;

/**

* @ApiResource(

* messenger=true,

* collectionOperations={

* "post"={"status"=202}

* },

* itemOperations={},

* outputClass=false

* )

class ResetPasswordRequest

{

/**

* @var string

* @Assert\NotBlank

public $username;

}

Thanks to the new messenger attribute, this object will automatically be dispatched to the bus. It can then be handled (synchronously or asynchronously) by a message handler:

namespace App\Handler;

use App\Entity\ResetPasswordRequest;
use Symfony\Component\Messenger\Handler\MessageHandlerInterface;

class ResetPasswordRequestHandler implements MessageHandlerInterface
{
    public function __invoke(ResetPasswordRequest $forgotPassword)
    {
        // do something with the resource
    }
}

namespace App\Handler;

use App\Entity\ResetPasswordRequest;

use Symfony\Component\Messenger\Handler\MessageHandlerInterface;

class ResetPasswordRequestHandler implements MessageHandlerInterface

{

public function __invoke(ResetPasswordRequest $forgotPassword)

{

// do something with the resource

}

That’s all you need to use Messenger!

Read and improve the Messenger subsystem documentation.

Server Push

HTTP/2 allows a server to pre-emptively send (or “push”) responses (along with corresponding “promised” requests) to a client in association with a previous client-initiated request. This can be useful when the server knows the client will need to have those responses available in order to fully process the response to the original request.
– RFC 7540

This is capability is especially useful for REST APIs performance: it allows the server to instantly push the relations of the current resource that will be needed by the client, even before the client knows that it will have to issue an extra HTTP request.

API Platform 2.4 makes it very easy to push relations using HTTP/2:

namespace App\Entity;

use ApiPlatform\Core\Annotation\ApiProperty;
use ApiPlatform\Core\Annotation\ApiResource;

/**
 * @ApiResource
 */
class Book
{
    /**
     * @ApiProperty(push=true)
     *
     * @var Author
     */
    public $author;
}

namespace App\Entity;

use ApiPlatform\Core\Annotation\ApiProperty;

use ApiPlatform\Core\Annotation\ApiResource;

/**

* @ApiResource

class Book

{

/**

* @ApiProperty(push=true)

* @var Author

public $author;

}

Thanks to the push attribute, if the client asks for /books/1 the web server will directly send both the requested book resource and the related author (e.g. /authors/12) to the client.

For best performance, this feature should be used in conjunction with the built-in HTTP cache invalidation system (based on Varnish).

Read and improve the HTTP/2 Server Push subsystem documentation.

Filters detection in API Platform Admin

Jean-François Thuillier and Arnaud Oisel patched API Platform Admin and the underlying API Doc Parser JavaScript library to automatically detect and use filters exposed by the API spec (Hydra or OpenAPI). A video is worth thousand words:

The only code that you need to get such UI is the following:

import React from 'react';
import { HydraAdmin } from '@api-platform/admin';

export default () => &lt;HydraAdmin entrypoint="https://api.example.com"/>;

import React from 'react';

import { HydraAdmin } from '@api-platform/admin';

export default () => <HydraAdmin entrypoint="https://api.example.com"/>;

The UI is built client-side dynamically by parsing the API spec. Awesome isn’t it?

Jean-François also added some convenient helpers to help customizing the admin, and Laury Sorriaux fixed a long standing limitation: it’s now possible to use the admin even with API not served at the root of the domain (such as /api).

Read and improve the docs of API Platform Admin.

OpenAPI v3 and ReDoc

API Platform 2.4 now fully support the new version of the OpenAPI (formerly Swagger) specification format (v3). It also leverages new features introduced by this version such as links.

To retrieve the OpenAPI specification of the API in version, use the following url: /docs.json?spec_version=3.

You can also dump the specification in JSON or in YAML format:

bin/console api:openapi:export --spec-version=3 # JSON
bin/console api:openapi:export --spec-version=3 --yaml # YAML

Also, in addition to Swagger UI, we added support for ReDoc, a beautiful, human-readable, API docs generator written in React:

OpenAPI v3 support has been contributed by Anthony Grassiot (API Platform Core Team). ReDoc integration has been contributed by Grégoire Hébert. A big thanks to them!

Read and improve the OpenAPI related documentation.

Improved DTO support

Handling Data Transfer Objects was known to be difficult with API Platform. Back in October, the API Platform and the Sylius teams worked together to improve the API of the popular e-commerce solution… using API Platform (stay tuned!). During this workshop Antoine Bluchet and I worked on a new way to handle DTOs with API Platform:

namespace App\Entity;

use ApiPlatform\Core\Annotation\ApiResource;
use App\Dto\BookInput;
use App\Dto\BookOutput;

/**
 * @ApiResource(
 *   inputClass=BookInput::class,
 *   outputClass=BookOutput::class
 * )
 */
final class Book
{
  // ...
}

namespace App\Entity;

use ApiPlatform\Core\Annotation\ApiResource;

use App\Dto\BookInput;

use App\Dto\BookOutput;

/**

* @ApiResource(

* inputClass=BookInput::class,

* outputClass=BookOutput::class

* )

final class Book

{

// ...

}

The new input_class and output_class attributes allow to use specific classes respectively for the writeable and the readable representation of the resource.

As demonstrated in the example using Symfony Messenger, it’s also possible to set these new attributes to false to hint that the operation will take no inputs or no outputs.

These new attributes are automatically taken into account by all API Platform subsystems, including GraphQL, Hydra and OpenAPI.

Read and improve the DTO related documentation.

Cache HTTP headers

A convenient way has been to configure the HTTP cache per resource has been added by Daniel West:

use ApiPlatform\Core\Annotation\ApiResource;

/**
 * @ApiResource(cacheHeaders={"max_age"=60, "shared_max_age"=120})
 */
class Book
{
    // ...
}

use ApiPlatform\Core\Annotation\ApiResource;

/**

* @ApiResource(cacheHeaders={"max_age"=60, "shared_max_age"=120})

class Book

{

// ...

}

With this config, API Platform will automatically generate the following Cache-Control HTTP header: Cache-Control: max-age=60, public, s-maxage=120. Thanks Daniel!

Read and improve the HTTP cache headers documentation.

Sunset HTTP header

The Sunset HTTP response header field indicates that a URI is likely to become unresponsive at a specified point in the future.
– draft-wilde-sunset-header Internet Draft

This header plays well with the deprecation mechanism available since API Platform 2.3. Thanks to a nice contribution of Thomas Blank, it’s now easy to set this header using API Platform:

namespace App\Entity;

/**
 * @ApiResource(itemOperations={
 *     "get"={
 *         "deprecation_reason"="Retrieve a Book instead",
 *         "sunset"="01/01/2020"
 *     }
 * })
 */
class Parchment
{
    // ...
}

namespace App\Entity;

/**

* @ApiResource(itemOperations={

* "get"={

* "deprecation_reason"="Retrieve a Book instead",

* "sunset"="01/01/2020"

* }

* })

class Parchment

{

// ...

}

Read and improve the documentation related to API evolution.

Improved client generator

API Platform 2.4 is shipped with an improved version of the React and Vue.js client generators:

Relations are now always handled properly
HTML number fields as well as lists (arrays) are converted to the appropriate JSON type when sent to the API
API not server at the root of the domain (such /api) are now supported (thanks to Fabien Kovacic)

Download and promote API Platform

API Platform 2.4 is available for download on GitHub. While you are here, if you like the project, help us making it popular by starring it on GitHub!

December 7, 2018December 7, 2018 by Kévin Dunglas

[SymfonyCon slides] Progressively enhance your Symfony 4 app using Vue, API Platform, Mercure and Panther

API Platform, PHP, Programmation, Symfony
API Platform, Mercure, Symfony, VueJS
4 Comments

Progressively enhance your Symfony 4 app using Vue, API Platform, Mercure and Panther from Les-Tilleuls.coop

Thanks to the new capabilities of the web platform (web components, Progressive Web Apps…) and the rise of modern JS libraries (Vue, React, Angular) almost all modern Symfony applications must leverage the frontend ecosystem.
Symfony 4 embed many gems that make it easy to integrate modern JavaScript within the framework, including the first component entirely written in JS: Webpack Encore.

In Symfony 4.2, another component that is super convenient for apps containing JS code has been released: Panther, a PHP library compatible with BrowserKit, that drives real web browsers to create end-to-end (E2E) tests with ease.
During this talk, I’ll show you how to cleanly integrate modern JavaScript code with Symfony and Twig and how to test such applications using Panther.

The examples will use VueJS, because it’s probably the easiest JS framework to get started with as a PHP developer, but all the tips and tricks will be applicable with other libraries such as React or Angular.

Finally, we’ll add some real time capabilities to our app using Mercure.rocks

November 28, 2018December 7, 2018 by Kévin Dunglas

NPM dependency hell: comparison with Symfony, Laravel and API Platform

English, JavaScript & HTML5, PHP, Symfony
dependencies, Javascript, NPM, Packagist, Security, Symfony
7 Comments

You may have noticed the recent fuss about the compromise of event-stream, a popular NPM package:

An NPM package with 2,000,000 weekly downloads had malicious code injected into it. No one knows what the malicious code does yet. https://t.co/V4rdenu7Bm
— Gary Bernhardt (@garybernhardt) November 26, 2018

event-stream is a transitive dependency of many popular JavaScript projects including Vue, Angular, Gatsby and VSCode (some of them are using a version that isn’t affected by the attack).

This attack raised, again, the problem of the JS dependency cascade: when you install a major project, it comes with hundreds of tiny libraries, sometimes not maintained, and sometimes coming from untrusted sources.

Some claimed that the problem wasn’t specific to the JavaScript ecosystem, and that projects in other languages such as Rails and Symfony were also suffering from a similar dependency hell.
A Twitter poll created by Rafael Dohms highlights that most developers believe that it’s only a matter of luck if this issue has affected the JavaScript ecosystem, and not the PHP one:

So in light of the NPM malicious code issue that came up this week. We have never seen anything similar in PHP/composer, why? (Poll)
— Rafael Dohms (@rdohms) November 27, 2018

Regarding Symfony, as a maintainer I have the feeling that the Symfony Core Team (carefully) adds dependencies only when strictly necessary. However I had no metrics to prove it. So I checked. Then I compared with other PHP frameworks I’m interested in: Laravel and API Platform.

Symfony

When installing Symfony 4.1 using the official skeleton, only 20 packages are downloaded (19 when excluding dev dependencies). 16 are directly maintained by the Symfony project, and the 4 others are interfaces from the PHP Framework Interoperability Group:

$ composer create-project symfony/skeleton nb-deps 
$ composer info | wc -l 
20 
$ composer info | cut -d/ -f1 | uniq
 psr 
symfony

$ composer create-project symfony/skeleton nb-deps 

$ composer info | wc -l 

$ composer info | cut -d/ -f1 | uniq

 psr 

symfony

Even when installing the website skeleton, that comes with all features provided by the framework and third party (trusted) packages such as the Doctrine ORM, the Twig templating library or Swift Mailer, only 94 packages (75 when excluding dev dependencies), from 17 different organisations (14 without dev deps) are installed:

$ composer create-project symfony/website-skeleton nb-deps
 $ composer info | wc -l 
94 
$ composer info | cut -d/ -f1 | uniq 
doctrine
 easycorp
 egulias 
facebook
 fig
jdorn
 monolog
 nikic 
ocramius
 phpdocumentor 
psr 
sensio
swiftmailer
 symfony 
twig
 webmozart 
zendframework

$ composer create-project symfony/website-skeleton nb-deps

 $ composer info | wc -l 

$ composer info | cut -d/ -f1 | uniq 

doctrine

 easycorp

 egulias 

facebook

 fig

jdorn

 monolog

 nikic 

ocramius

 phpdocumentor 

psr 

sensio

swiftmailer

 symfony 

twig

 webmozart 

zendframework

Among these vendors, 7 are directly maintained by members (or former members) of the Symfony Core Team (easycorp, monolog, sensio, swiftmailer, symfony, twig, webmozart) and 2 are from the FIG. All these few libraries, except maybe jdorn/sql-formatter, are actively maintained, by prominent and well known members of the PHP community.

API Platform

A minimal installation of the server part (the one written in PHP) of the API Platform framework contains only 27 packages (26 without dev deps) from 5 vendors.

$ composer create-project symfony/skeleton nb-deps
 $ composer require api-platform/core
 $ composer info | wc -l
 27
 $ composer info | cut -d/ -f1 | uniq 
api-platform 
doctrine 
psr 
symfony
 willdurand

$ composer create-project symfony/skeleton nb-deps

 $ composer require api-platform/core

 $ composer info | wc -l

 $ composer info | cut -d/ -f1 | uniq 

api-platform 

doctrine 

psr 

symfony

 willdurand

When installing the API pack, that provides all features you can expect from an advanced web API (hypermedia support, automatic persistence with the Doctrine ORM support, automatic generation of human-readable documentation, CORS support, authorisation rules…), 57 packages (56 without dev deps) from 10 vendors are shipped.

$ composer create-project symfony/skeleton nb-deps
 $ composer require api
 $ composer info | wc -l
 57 
$ composer info | cut -d/ -f1 | uniq
api-platform
 doctrine 
jdorn 
nelmio
 phpdocumentor
 psr 
symfony 
twig 
webmozart 
willdurand

$ composer create-project symfony/skeleton nb-deps

 $ composer require api

 $ composer info | wc -l

$ composer info | cut -d/ -f1 | uniq

api-platform

 doctrine 

jdorn 

nelmio

 phpdocumentor

 psr 

symfony 

twig 

webmozart 

willdurand

On the other hand, the API Platform distribution comes with (optional) frontend tools: an admin and a Progressive Web Apps and mobile apps generator. They are built-on top of React, so even if the JavaScript libraries directly maintained by the API Platform team depend of just a few carefully selected libraries… these dependencies are typical JavaScript ones, and come with hundreds of dependencies (see after).

Laravel

The default installation of Laravel (that is somewhat similar in term of features to the Symfony website skeleton) comes with 72 packages (39 when excluding dev deps) from 35 vendors (21 when excluding dev deps).

$ laravel new nb-deps
 $ composer info | wc -l 72 
$ composer info | cut -d/ -f1 | uniq
dnoegel
doctrine
dragonmantank
egulias
erusev
fideloper
jakub-onderka
laravel
league
monolog
nesbot
nikic
opis
paragonie
psr
psy
ramsey
swiftmailer
symfony
tijsverkoyen
vlucas

$ laravel new nb-deps

 $ composer info | wc -l 72 

$ composer info | cut -d/ -f1 | uniq

dnoegel

doctrine

dragonmantank

egulias

erusev

fideloper

jakub-onderka

laravel

league

monolog

nesbot

nikic

opis

paragonie

psr

psy

ramsey

swiftmailer

symfony

tijsverkoyen

vlucas

The number of maintainers you have to trust when using Laravel is just a bit larger than when using Symfony, but again it’s still a bunch of people that are well known in the PHP community, and who may fit in a single room.

In comparison, a default installation of React using Create React App – that is more similar to the minimal Symfony skeleton than to fully-featured frameworks such as the Symfony website skeleton or Laravel – comes with 809 packages, most of them being maintained by different teams or individuals.

Another main difference is that most JS libraries are distributed as compiled and minified builds. Therefore it’s very difficult to guarantee that what is shipped and executed behaves exactly the same way than the code in the sources. In PHP, the source of the libraries are used directly, without intermediate obfuscation. PHP builds are easy to reproduce, it helps a lot when auditing.

Of course, it doesn’t mean that major PHP frameworks are immune to this kind of attacks and – as any IT project – they also have their own security issues. However, the amount of third party code installed and the chain of trust you have to rely on is more under control than in the JS world.

By the way, you’d better actively monitor the security vulnerabilities that may affect your PHP projects.

October 26, 2018October 26, 2018 by Kévin Dunglas

HTTP/2: speed up your apps and dispatch real time updates (Symfony and API Platform’s features announcement)

API Platform, PHP, Symfony
API Platform, HTTP/2, Mercure, Push, Symfony, websocket
Leave a comment

HTTP/2 can improve the loading time of webpages up to 2 times. Did you know that it’s very easy to optimize your Symfony applications to leverage the advanced features of this new protocol?

This talk also contains the announcement of 3 new PHP packages:

Agenda:

a historically contextualized presentation of the different versions of the HTTP protocol;
a state of the protocol support in the PHP ecosystem;
a guide explaining how to serve your PHP and Symfony apps with h2, using Nginx, Apache and Docker;
many code samples showing how to use h2 to improve the loading time of your assets and APIs using the WebLink component and Twig
examples of how to take advantage of the protocol using the curl and Guzzle clients
the Mercure Protocol
Mercure x Symfony
Mercure x API Platform

HTTP/2: speed up your apps and dispatch real time updates (Symfony and API Platform's features announcement) from Les-Tilleuls.coop

September 28, 2018 by Kévin Dunglas

Panther: test your Symfony apps with real web browsers (SymfonyLive London slides)

English, JavaScript & HTML5, PHP, Programmation, Symfony
browser-testing, Chrome, ChromeDriver, E2E, e2e-testing, JavaScipt, Panther, Selenium, Symfony, testing
Leave a comment

Today, Panther reached 1,000 stars on GitHub!
To celebrate, I unveiled a set of new features during my talk at SymfonyLive, including some brand new database testing helpers inspired from Laravel. Check this out:

Panther: test your Symfony apps with real web browsers from Les-Tilleuls.coop

From a few lines of jQuery to modern React/Vue… PWA, Symfony apps always contain JavaScript code. Unfortunately, the SF functional test helper and the Goutte web scrapping lib aren’t able to execute JS code. It means that they cannot assert on client-side generated HTML, test if an element is visible or not, deal with alert boxes or detect if a bug occurs only with a specific browser.

Panther is a brand new e2e testing and web scrapping library written in PHP that drives real browsers thanks to the WebDriver protocol from the W3C. It implements the exact same API than the BrowserKit component. It means than existing SF tests and Goutte scripts work without modification… but this time JS will be executed! The tool also brings new capabilities including taking screenshots, or executing custom JS in the execution context of the web page. To install Panther you only have one command to run, and it doesn’t need any dependency to install Panther. Let’s meet the feline!

September 24, 2018 by Kévin Dunglas

Upcoming conferences and workshops

API Platform, JavaScript & HTML5, PHP, Programmation, Symfony
API Platform, conferences, Javascript, Panther, PHP, Sylius, Symfony
Leave a comment

I’ll speak at several conferences until the end of 2018.

The topics will be varied: Panther, modern JavaScript, HTTP/2 and a brand new project to be announced (teasing: it’s written in Go, and it will be very helpful for serverless architectures!).

See you at:

Symfony Live London (September, 27th): Building API-driven apps with API Platform (full day workshop)
SymfonyLive London (September, 28th): Panther, test your Symfony apps with real web browsers
HacktoberFest & Sylius Week @ Les-Tilleuls.coop (Lille, October, 6th): surprise talk + workshop!
Cooperative creative agencies’ 23rd national congress (Lille, October 11th): Building mobile and web applications with interoperability in mind
SymfonyLive Berlin (October, 24th): Building API-driven apps with API Platform (full day workshop)
Forum PHP (Paris, October, 26th): Boost your apps with HTTP/2
SymfonyCon Lisbon (December, 4th & 5th): Building API-driven apps with API Platform (full day workshop)
SymfonyCon Lisbon (December, 7th): Integrate (Vue)JS components in a Symfony app, add E2E tests with Panther

I’ll also be available to chat, and I’ll carry a lot of API Platform goodies. Don’t hesitate to get in touch!

September 12, 2018 by Kévin Dunglas

Introducing Symfony Panther: a Browser Testing and Web Scraping Library for PHP

API Platform, JavaScript & HTML5, PHP, Symfony
API Platform, Panther, PHP, Selenium, Symfony, VueJS, WebDriver
1 Comment

Today, an introduction blog post to Panther was published on the Symfony blog! Panther is a new browser testing and web scraping library I contributed to the Symfony project,
In the blog post, I showcase how to use Symfony, API Platform and VueJS together to create a small but modern app, and how to test it on Panther:

Introducing Symfony Panther: a Browser Testing and Web Scrapping Library for PHP https://t.co/65shBzDgnV #symfony

— Symfony (@symfony) September 12, 2018

Symfony published a tutorial explaining how to use @symfony, @ApiPlatform, @vuejs and Panther (a new E2E testing tool) all together! https://t.co/lQRj24YeYk

— API Platform (@ApiPlatform) September 12, 2018

July 6, 2018August 6, 2018 by Kévin Dunglas

API Platform 2.3: Major Perf Improvement, API evolution/deprecation, Better Dev Tools and Much More!

Today, the API Platform framework has reached 3k stars on GitHub, and it makes us very proud! To celebrate, I’ve just tagged the 2.3 version, that comes with a lot of amazing new features. Let’s discover them!

For newcomers, API Platform is a modern open source framework for API-driven projects. It allows, in just a few minutes, to expose hypermedia and GraphQL APIs. It also provides client-side tools leveraging the capabilities of auto-discoverable APIs: the admin interface and the React and Vue.js Progressive Web App generator. Finally, API Platform has been designed from the ground up as a Cloud Native solution that can run locally with the built-in Docker setup and be deployed instantly on a Kubernetes cluster (Heroku is also supported).

40% faster than the previous version!

We’re committed to continuously improving the performance of API Platform. In version 2.1, we’ve added an amazing invalidation-based cache mechanism. When enabled, HTTP responses are generated only one time then stored and served by a reverse caching proxy. When a resource is modified, all responses including or referencing it are automatically removed from the cache.

In version 2.3, Ben Davies has done an excellent job at profiling and patching the core component. Moreover, we’ve worked closely with the Symfony team to dramatically improve the performance of the Symfony Serializer component (one of the most important pieces of software used by API Platform).

With all these optimizations put together, in the scenario of a cache miss, API Platform-based apps are now more than 40% faster in version 2.3 compared to version 2.2 (Blackfire comparison):

Upgrading from Symfony 4.0 to 4.1 makes @ApiPlatform 41% faster 😲! Benchmark: https://t.co/dHkvge90SI pic.twitter.com/kEcQI0KpVn

— Kévin Dunglas (@dunglas) May 31, 2018

A big thanks to Ben and to Nicolas Grekas from Blackfire.io for making it happen!

Support for API evolution (aka deprecating fields and resources)

A growing best practice is to use the evolution strategy for web APIs. Creating new versions of the API, of or its endpoints requires modifying all clients to upgrade, even the ones not impacted by the changes. On the other hand, this strategy (also known as versionless APIs) consists of deprecating the fields, resources types or operations that will be removed at some point. Most modern API formats including GraphQL, OpenAPI and Hydra are able to support this strategy.

In API Platform 2.3, we’ve introduced a new attribute to mark deprecated resource classes, operations and properties. All documentation formats generated by API Platform and having support for this feature will then automatically take it into account.

Here is how to deprecate an entire resource:

<?php

namespace App\Entity;

use ApiPlatform\Core\Annotation\ApiResource;

/**
 * @ApiResource(deprecationReason="Create a Book instead")
 */
class Parchment
{
    // ...
}

<?php

namespace App\Entity;

use ApiPlatform\Core\Annotation\ApiResource;

/**

* @ApiResource(deprecationReason="Create a Book instead")

class Parchment

{

// ...

}

As you can see, to deprecate a resource, we just have to explain what the client should do to upgrade in a dedicated attribute. You can also use this new deprecationReason attribute on any operation.

The deprecation will automatically be taken into account by clients supporting the previously mentioned format. Here is how it renders for OpenAPI in the built-in Swagger UI shipped with the framework:

And now in the built-in version of GraphiQL (for GraphQL APIs):

It’s also possible to deprecate a single field:

<?php

namespace App\Entity;

use ApiPlatform\Core\Annotation\ApiProperty;
use ApiPlatform\Core\Annotation\ApiResource;

/**
 * @ApiResource
 */
class Review
{
    // ...

    /**
     * @ApiProperty(deprecationReason="Use the rating property instead")
     */
    public $letter;
}

<?php

namespace App\Entity;

use ApiPlatform\Core\Annotation\ApiProperty;

use ApiPlatform\Core\Annotation\ApiResource;

/**

* @ApiResource

class Review

{

// ...

/**

* @ApiProperty(deprecationReason="Use the rating property instead")

public $letter;

}

All our client-side tools have been updated to ignore deprecated fields, operations and resources by default. The api-doc-parser library (which supports Hydra, and OpenAPI in the latest version) also support this new feature.

Dedicated Profiler Panel and Web Debug Toolbar Integration

Symfony comes with a nice set of development tools, including the Profiler, and it is compatible with API Platform! To install it, execute composer req profiler. Thanks to the contributions of Julien Deniau and Anthony Grassiot, the Web Debug Toolbar now displays an icon featuring our nice spider Webby that is linked to a new profiler panel dedicated to API Platform:

Shorter Attributes Syntax

Defining attributes using annotations can become verbose pretty quickly. As alternatives to annotations, for complex configurations API Platform also supports the XML and YAML formats. However, in version 2.3, Baptiste Meyer added a nicer and shorter syntax to define attributes on the @ApiResource and @ApiProperty annotations:

// Before
/**
 * @ApiResource(
 *     attributes={
 *         "validation_groups"={"bar"},
 *         "normalization_context"={"groups": {"book:read"}}
 *     }
 * )
 */
class Book
{
    // ...
}

// Now
/**
 * @ApiResource(
 *     validationGroups={"bar"},
 *     normalizationContext={"groups": {"book:read"}}
 * )
 */
class Book
{
    // ...
}

// Before

/**

* @ApiResource(

* attributes={

* "validation_groups"={"bar"},

* "normalization_context"={"groups": {"book:read"}}

* }

* )

class Book

{

// ...

}

// Now

/**

* @ApiResource(

* validationGroups={"bar"},

* normalizationContext={"groups": {"book:read"}}

* )

class Book

{

// ...

}

Of course the “old” syntax is still valid, but the new shortcuts allow a better discoverability and enable autocompletion in IDEs (if you are a PHPStorm user, install the PHP Annotations plugin to benefit from this new feature).

Revamped Admin

In version 2.3, a lot of love has been given to the API Platform Admin Component. This JavaScript library, maintained by Morgan Auchedé, dynamically constructs a UI for any API supporting Hydra or OpenAPI.

It uses React, and was built on top of the Admin On Rest library. But as you may know, Admin On Rest has been deprecated and Marmelab, the company behind the tool, has released a replacement called React Admin. React Admin comes with an updated fancy interface and it also fixes some design issues.

So we’ve patched API Platform Admin to use the new kid on the block, and we’ve taken this opportunity to also fix a well known annoying issue on our side: the Admin component wasn’t able to deal with embedded relations. This isn’t the case anymore. What’s even better, the Admin is now smart enough to reuse the data already downloaded as embedded relation instead of triggering a new HTTP request. It allows to dramatically improve the performance of the admin!

We’ve also added support for new features introduced by React Admin, including bulk delete.

Other Features

Of course, this new version also includes a lot of new features that are less visible but also very useful. Here is the curated list of some interesting changes:

Make resource class’s constructor parameters writable
Add support for interface as a resource
Throw an exception if a required filter isn’t set
Allow to specify the message when access is denied using the access_control_message attribute
Add a new option to include null results when using the date filter
Allow data persisters to return a new instance instead of mutating the existing one
Add a new attribute to configure specific formats per resources or operations
Add an --output option to the api:swagger:export command
Drop support for PHP 7.0
Upgrade Swagger UI and GraphiQL
GraphQL: Add a totalCount field in GraphQL paginated collections
JSONAPI: Allow inclusion of related resources

It is also worth mentioning that Teoh Han Hui has modernized the Docker setup we provide to leverage the new capabilities of this containerization technology.

As usual, thank you very much to all the developers who’ve contributed these new features, bug fixes, and the related documentation entries. You’re the most important part of the project: the community.

June 18, 2018June 18, 2018 by Kévin Dunglas

API Platform: A Framework for API-driven Projects (DevTalks Bucharest slides)

API Platform, English, Symfony
API, API Platform, GraphQL, JSON-LD, Kubernetes, React, REST, Symfony
1 Comment

Here the slide deck I presented during DevTalks Bucharest 2018.

It covers the main features of the API Platform framework: we will install the framework, design an API data model as a set of tiny plain old PHP classes and learn how to get:

A fully featured dev environment with Symfony Flex and React containers, HTTP/2 and HTTPS support and a cache proxy
Pagination, data validation, access control, relation embedding, filters and error handling
Support for modern REST API formats: JSON-LD/Hydra, OpenAPI/Swagger, JSONAPI, HAL, JSON…
GraphQL support
An API responding in a just few milliseconds thanks to the builtin invalidation based cache mechanism
A dynamically created Material Design admin interface (a la Sonata / EasyAdmin – but 100% client-side) built with React
Client apps skeletons: React/Redux, React Native, Vue.js, Angular…

Finally, we’ll see ho to deploy the project in 1 command on Google Container Engine or any cloud with a Kubernetes.

This is an updated version of the talk I did during the SymfonyLive London 2017 conference, demonstrating the latest features of API Platform, and adapted to target a broader, non-Symfony/PHP audience.

API Platform: A Framework for API-driven Projects from Les-Tilleuls.coop

May 17, 2018 by Kévin Dunglas

Mastering the Symfony Serializer (PHP Tour slides)

API Platform, English, PHP, Programmation, Symfony
PHP, Serializer, Symfony
Leave a comment

The Symfony Serializer Component exists since the very beginning of Symfony 2. Years after years, it gained a lot of new features useful to transform various data formats to PHP structures and the opposite. It is also a foundation block of API Platform and a first-class citizen in FOSRest.

Let’s dive into this component. We will cover the basic concepts behind the serialization process: normalization, denormalization, encoding and decoding.

Then we will discover all the little known features of the component: JSON, XML and CSV support, file handling with “data:” URIs, serialization groups, attributes names conversion, trees support, updating existing objects, dealing with circular references.

Finally we will learn how to create custom normalizers and encoders; and how to modify the behavior of the builtin ones using composition.

Kévin Dunglas

Software architect and API expert

Category / Programmation

API Platform 2.4: MongoDB, Elasticsearch, Mercure, OpenAPI v3, CQRS with Symfony Messenger, HTTP/2 Push, improved React apps and more!

MongoDB support

Elasticsearch support

Real time update of client with Mercure

CQRS and async message handling with Symfony Messenger

Server Push

Filters detection in API Platform Admin

OpenAPI v3 and ReDoc

Improved DTO support

Cache HTTP headers

Sunset HTTP header

Improved client generator

Download and promote API Platform

[SymfonyCon slides] Progressively enhance your Symfony 4 app using Vue, API Platform, Mercure and Panther

NPM dependency hell: comparison with Symfony, Laravel and API Platform

Symfony

API Platform

Laravel

HTTP/2: speed up your apps and dispatch real time updates (Symfony and API Platform’s features announcement)

Panther: test your Symfony apps with real web browsers (SymfonyLive London slides)

Upcoming conferences and workshops

Introducing Symfony Panther: a Browser Testing and Web Scraping Library for PHP

API Platform 2.3: Major Perf Improvement, API evolution/deprecation, Better Dev Tools and Much More!

40% faster than the previous version!

Support for API evolution (aka deprecating fields and resources)

Dedicated Profiler Panel and Web Debug Toolbar Integration

Shorter Attributes Syntax

Revamped Admin

Other Features

API Platform: A Framework for API-driven Projects (DevTalks Bucharest slides)

Mastering the Symfony Serializer (PHP Tour slides)

MongoDB support

Elasticsearch support

Real time update of client with Mercure

CQRS and async message handling with Symfony Messenger

Server Push

Filters detection in API Platform Admin

OpenAPI v3 and ReDoc

Improved DTO support

Cache HTTP headers

Sunset HTTP header

Improved client generator

Download and promote API Platform

Partager :

Partager :

Symfony

API Platform

Laravel

Partager :

Partager :

Partager :

Partager :

Partager :

40% faster than the previous version!

Support for API evolution (aka deprecating fields and resources)

Dedicated Profiler Panel and Web Debug Toolbar Integration

Shorter Attributes Syntax

Revamped Admin

Other Features

Partager :

Partager :

Partager :