[SymfonyLive Paris slides] Symfony on steroids
: Vue.js, Mercure, Panther

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

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

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

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:

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:

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:

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.

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.

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).

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.

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

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:

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!

Upcoming conferences and workshops

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:

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

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

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:

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

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:

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:

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:

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.

Be paid to improve API Platform during the Rails Girls Summer of Code

(french translation below)

API Platform (the API-driven Open Source framework I created) has been selected for the Rails Girls Summer of Code program!

The goal of the RCSOC is to improve the diversity in Open Source development. It allows groups of 2 women students to work full-time on a FOSS project (such as API Platform) during the summer. Students are paid and mentored.

Rails Girls Summer of Code is a global fellowship program for women and non-binary coders. Students receive a three-month scholarship to work on existing Open Source projects and expand their skill set.

Our worker cooperative, Les-Tilleuls.coop, will also support the program by providing money, coaches (including me) and desktops (in Lille, France):

In our company, we attempt as much as possible to support associations engaged in the fight against social inequalities, or involved in a better access to culture and respect of the environment. Since our foundation in 2011, we have always upheld diversity in Open Source. Thus, it’s no surprise that we support Rails Girls’s Summer of Code program.

If you’re interested in working 3 months with us to improve cutting-edge Open Source projects, don’t by shy, apply!


API Platform, le framework API-driven que nous développons, compte parmi les projets sélectionnés pour le Rails Girls Summer of Code de cette année !

Ce programme vise à favoriser la diversité dans le mode du logiciel libre. Il permet à des groupes de 2 étudiantes d’être payées durant l’été pour travailler (en binôme) sur des projets Open Source.

Notre SCOP Les-Tilleuls.coop participe également au programme en tant que sponsor, et va fournir des bureaux (à Euratechnologies, Lille) et des “coachs” afin d’accompagner les participantes :

Chez Les-Tilleuls.coop, nous tentons autant que possible d’accompagner des associations ou des entités engagées dans la lutte contre les inégalités sociales, l’accès à la culture, la formation, ou encore le respect de l’environnement.  Notre coopérative s’implique aussi dans une meilleure diversité dans le numérique et c’est donc avec une certaine évidence que nous apportons notre soutien au programme “Summer of Code 2018” organisé par l’association Rails Girls (RGSoC).

Si vous êtes intéressées pour travailler 3 mois sur des projets Open Source innovants, ne soyez pas timides, postulez !

API Platform 2.2: GraphQL, JSON API, React admin and PWA, Kubernetes instant deployment and many more new features


I’m glad to announce the immediate availability of API Platform 2.2 beta 1. This is a huge release that comes with a lot of exciting features including (but not limited too):

  • GraphQL and JSON API support
  • Symfony 4 / Flex integration
  • API Platform Admin integration (built with ReactJS and Admin On Rest)
  • ReactJS and Vue.js Progressive Web App generators integration (a React Native app generator is also available)
  • Revamped Docker containers for both PHP and JavaScript components, including out of the box support for HTTP2, HTTPS and a built-in invalidation-based cache mechanism using Varnish
  • The ability to deploy in seconds in any Kubernetes cluster
  • A new, super-easy, way to register filters through annotations
  • And literally dozens of developer experience, performance and quality improvements

V2.2 will definitely be the best version of API Platform, and is probably the most advanced “full-stack” solution to create API-driven projects. The paradigm shift introduced by this new version has been detailed in my talk during the SymfonyCon 2017.

It took 6 months and 483 commits from more than 60 contributors to craft this version. The documentation has also been dramatically improved, even if some work is still to do (upgrading the getting started guide and migrating all articles to the new Flex directory structure, finish to document some new features).

Thank you very much to all contributors of the project! You rock!

Let’s see more in depth all of these new features:

The New Distribution

The easiest way to get started with API Platform has always been to use the provided Docker setup. In version 2.2, the Docker configuration has been totally redesigned to fit with the new features provided by Symfony Flex and to integrate our JavaScript components.

To get started:

You get:

– An API skeleton following the Flex directory structure. Just add classes representing your public data model (see the example below) to get a working hypermedia and/or GraphQL web API.

The API is available in HTTP/2 and HTTPS thanks to the provided development proxy. It also automatically benefits from the API Platform’s built-in cache mechanism (the Varnish container is also provided). CORS headers are automatically configured. As you can see, the nice documentation is – of course – still available if you open the entrypoint in a browser.

– A ReactJS Progressive Web App skeleton with a fancy welcome page designed by Laury Sorriaux:

Execute  docker-compose exec client generate-api-platform-client to bootstrap a nice and fully-featured Progressive Web App (that can even work offline) using React, Redux and Bootstrap 4 and respecting accessibility recommendations.

To generate the PWA, the tool parses the API hypermedia description automatically generated in the Hydra format by the API component. This generator can work with any server exposing a Hydra documentation (done with API Platform or not).

The tool also has Vue.js, React Native and TypeScript skeletons thanks to the great contributions of Alain Hippolyte, Piotr Synowiec and Antoine Bluchet.

Read the full documentation of the API Platform Client Generator.

– Last but not least, a dynamically generated admin for the API is also automatically available:

Like the client generator, the API Platform Admin component also leverages the Hydra documentation to automatically guess the structure of the data exposed by the API.

Because it is built on top of React and Admin On Rest (aka React Admin), the UI is fully customizable.

Morgan Auchedé is the new maintainer of this component, and has greatly improved it since its initial release.

– In this version of API Platform, the MySQL container has been replaced by a Postgres one.

Instant Kubernetes Deployment

Kubernetes has become the most popular way to deploy, run and manage containers in production. Both Google Cloud Platform, Microsoft Azure and Amazon Web Services provide managed Kubernetes environment.

API Platform 2.2 contains a built-in Helm (the k8s package manager) chart to deploy with ease:

Your app is now up and running in a managed cluster! Read the related documentation to learn more about the Kubernetes support.

GraphQL Support

GraphQL is a query language for APIs designed by Facebook that is becoming a very popular alternative to the REST pattern. GraphQL support has been the most wanted feature for a while, it is now fully implemented!

The new GraphQL subsystem of API Platform now supports:

To enable the GraphQL support, you just have to install the GraphQL PHP library:

Then, create an API Platform entity, as usual:

Yes, both GraphQL and REST formats can be used for the same entity! Thanks to API Platform’s hypermedia support, you can even run a GraphQL request, then apply REST operations to the retrieved resources using their IRIs! The best of both worlds.

Your GraphQL API is ready! Browse https://localhost:8443/graphql :

There is a lot to say about the GraphQL support, how to use it in collaboration with REST and how to apply fine-grained configurations. I’ll write a follow-up post dedicated to it, stay tuned!

The GraphQL support is an important team work of Raoul Clais, Alan Poulain, Baptiste Meyer and myself.

JSON API Support

JSON API is a rising, well designed, hypermedia format. Unlike JSON-LD (the default format exposed by API Platform), it’s not a web standard; and it has less features but it is also simpler to learn and understand.

With API Platform 2.2, you don’t have to choose, you can have both! And even more because API Platform supports out of the box JSON-LD/Hydra, HAL, JSON API, YAML, XML, raw JSON and as we’ve seen just before, GraphQL.

To enable JSON API, add the following config:

Easy enough?

The JSON API support has been contributed by Hamza Amrouche, Hector Hurtarte and Baptiste Meyer.

Declaring API Filters Using Annotations

The API Platform filtering system is very powerful. It contains a lot of built-in filters and can easily be extended. However, until now, it wasn’t really easy to configure: it was requiring to declare services manually.

Because Symfony Flex is all about service autowiring and autoconfiguration, simplifying the filters configuration was a top priority task.

Hopefully, Antoine Bluchet created a nice way to do it using annotations:

Nothing more! You can now filter the collection of organizations by the name  property, both with REST and GraphQL!

In addition to these main features, a lot of other configuration options and various improvements have been introduced. Read the full changelogs for more information:

Help Us: Test, Star, Spread the Word!

If you have some existing API Platform projects, or if you want to give a try to the framework, please test this new version and report any problem on our GitHub issue tracker!

If you like API Platform, please tell the world and give us a star on GitHub.

Since API Platform 2.2, the Symfony Thanks command is also shipped with API Platform. Thanks to this tool, you can send a star to all the PHP libraries you use in your project (including API Platform) by simply running: docker-compose exec php composer thanks

If you want to learn API Platform, come to one of the workshops organized during these upcoming tech conferences:

[SymfonyCon] API Platform and Symfony: a Framework for API-driven Projects

Here are the slides of my talk during the Symfony Con Cluj. You can rate this talk on joind.in.

Install API Platform. Design the API data model as a set of tiny plain old PHP classes. Instantly get:

  • 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 admini interface (a la Sonata / EasyAdmin – but 100% client-side) built with React.
  • Client apps skeletons: React/Redux, React Native, Vue.js, Angular…
  • Finally, deploy in 1 command on Google Container Engine or any cloud with a Kubernetes instance with the provided Helm chart.

Yes, you just need is describing a data model, just a few line of codes to get all of that!

API Platform Admin 0.2: an admin in 1 minute for your API (React Progressive Web App)

The version 0.2 of the API Platform‘s admin component has just been released!

This nice tool allows to automatically and dynamically build a fully featured administration interface (CRUD, pagination, relations…) for any API supporting the Hydra hypermedia vocabulary (more formats supported soon, see at the end of this article). 0 line of code required!

API Platform Admin is built with React on top of the famous Admin On Rest library as a Progressive Web App.

Let’s discover the bunch of new features that this version brings.

Getting Started

Assuming that you have an API exposing a Hydra documentation, you just have to initialize the following React component to get your admin:

For instance, create a new app with Facebook’s create-react-app, replace the content of src/App.js with the previous snippet and run yarn add @api-platform/admin. You’re done!

If you get an error related to multiple versions of React being loaded, just remove the react and react-dom packages from your project’s package.json and run yarn install again.

If you don’t have a JSON-LD / Hydra API yet, here is the code of the one I’ll use in the following examples. This API has been created using the API Platform’s distribution:

Yes, you just need those two tiny PHP classes to get a hypermedia API. Learn more about the API component by reading the getting started guide. But, really, any API with a Hydra documentation will do the job regardless of the server-side programming language.

Native Support for to-Many Relations

API Platform Admin supports to-one relations since its very first release. However it was mandatory to customize the component used for to-many relations. This isn’t the case anymore. Our API documentation parser gained support for cardinalities and can now extract them if the API documentation includes OWL’s maxCardinality properties.

If no cardinality is provided, the admin will use a to-many widget by default.

Thanks to this new feature, here is how the edition screen of the Person resource looks like this:

The admin is able to guess that the Person resource is related to many Greeting ones and use the appropriate Admin On Rest component.

Detection of More Schema.org’s Types (name, url and email)

API Platform Admin is able to guess the widget to use depending of the type of a resource’s property. It supports:

  • Numbers (http://www.w3.org/2001/XMLSchema#float and http://www.w3.org/2001/XMLSchema#integer ranges)
  • Dates (http://www.w3.org/2001/XMLSchema#date and http://www.w3.org/2001/XMLSchema#dateTime ranges)
  • Booleans (http://www.w3.org/2001/XMLSchema#boolean range)
  • And of course text fields

In this new release, Admin also supports some types of the popular Schema.org vocabulary:

  • As shown in the previous screenshots (e.g. Greetings select box), if a property has the type http://schema.org/name, this property will be used instead of the ID when displaying this relation
  • If a property has the type http://schema.org/url, the URL will be clickable when displayed in the admin
  • If a property has the type http://schema.org/email, the HTML input will be of type email and a basic validation will occur (this was already working in v0.1)

Support for Read-only Resources

The version 0.1 wasn’t able to deal with read-only resource (no POST nor PUT operation). We have improved the API doc parser to support owl:equivalentClass properties. Now, if the API documentation provide those properties, the admin will be builded even if the resource is read-only (of course in this case you will only be able to browse resources, and not to edit them).

Easier and Deeper Customization

Morgan Auchedé did an excellent work to make the Admin fully and easily customizable. You can now override any generated React component by a custom one, or one from Admin On Rest, or from MUI React. You can just replace (or ad, or remove) a specific input or field. But you can also replace a whole list, a show view, a creation or edition form or a remove button.

Here is an example of full customization, courtesy of Morgan:

Ability to Support Other Formats Such as GraphQL

The parser has been designed to be able to be parse other formats such as a GraphQL schema or Swagger/Open API. The api-doc-parser library provides an intermediate representation that is populated by the specific format parser. It’s this representation that is used by the parser as well as by our React and Vue.js Progressive Web App generator.

It means that when converters from other formats than Hydra to this intermediate representation will be available (Pull Requests welcome), both tools we’ll support those formats. As you may know, the server part of API Platform now supports GraphQL. You can guess which format we’ll implement next in the api-doc-parser!