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.
GraphQL is an increasingly popular alternative to REST architectures for building web APIs.
The query language promoted by Facebook has undeniable advantages: retrieve exactly what the client need, limitation of the number of queries, strong typing, powerful and extremely well thought out syntax…
However, it also suffers from often underestimated problems including HTTP cache, logs, security or authentication, features that are the basis of the today’s web stack. GraphQL is also a non-standard format that requires a specific parser.
In addition, modern REST-based hypermedia formats such as JSON-LD or JSON API have features very similar to those of GraphQL (and more advanced ones) while remaining compatible with the fundamentals of the web.
The API Platform framework, based on Symfony, makes it easy to create REST APIs (JSON-LD, JSON API, HAL …) just like GraphQL.
After listing the advantages and disadvantages of different formats, we will study through different cases of frequent use when it is better to use GraphQL, REST or both in addition.
I’ve been interviewed along with other cooperatives founders form all across Europa in a video series published by the #CoopLab project.
I present in depth the democratic and social-equity principles behind Les-Tilleuls.coop, a self-managed company, 100% owned by its employees, I cofounded 6 years ago.
I explain how we grew from 3 to 25 while making together every important decision – including hirings and salaries – and sharing fairly the generated profits.
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!
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 SCOPLes-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 !
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):
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.
Decompress the archive and open a terminal in the resulting directory
Run
docker-compose up
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.
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).
– 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.
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:
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!
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.
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:
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!
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:
Don’t miss the next opportunities to learn @ApiPlatform during a 1 day workshop: – « Creating and deploying API Platform apps on @platformsh » / @APIdaysGlobal – « Mastering the API Platform’s server component » / @symfony_live Paris (2 sessions) then Phantasialand
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!
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)
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:
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!
Symfony is a framework broadly recognized for its quality, reliability and ability to drive large enterprise projects. But for the last few years, Symfony has also gained many features to develop faster, and to refactor more easily. Symfony 4 offers major improvements in this area that will deeply change the way we build applications.
Let’s talk about:
Symfony 4 main concepts and new features: micro-framework by default, 12-factor app, new components …
Flex, the new and powerful Symfony installer that can also automatically install and configure libraries and bundles
Symfony 4’s new simplified (and “bundle-less”) directory structure
The autowiring (now enabled by default), which allows the automatic injection of dependencies without having to write any configuration (no more YAML and XML)
The revamped controllers mechanism
Webpack Encore, the first Symfony component ever written in JavaScript, designed to easily integrate JavaScript and CSS tools in a PHP project
The official integrations of the Doctrine (ORM), API Platform (API) and EasyAdmin libraries (admin generator)
How to easily use Symfony 4 with Docker from dev to cloud deployment with a dedicated skeleton
You’ll learn how to leverage Symfony for large projects, prototypes, small applications and even your “weekend projects”, and how to migrate from smallest to the largest.
A few months ago, I’ve contributed a new component to Symfony: WebLink. By implementing cutting edge web standards, namely HTTP/2 Server Push and W3C’s Resource Hints, it brings great opportunities to boost webapp’s performance.
Thanks to Symfony WebLink, HTTP/2 (h2) servers are able to push resources to clients before they even know that they need them (think to CSS or JavaScript files, or relations of an API resource). WebLink also enables other very efficient optimisations that work with HTTP 1:
telling the browser to fetch or to render another webpage in the background ;
init early DNS lookups, TCP handshakes or TLS negotiations
Let’s discover how easy it is to use it and the real life benefits you can expect. The WebLink components is available since Symfony 3.3 (it means you can start to use it today), but in this article I’ll use Symfony 4 to celebrate the release of its first beta yesterday!
Open https://localhost, if this nice page appears, you successfully created your first Symfony 4 project and are browsing it in HTTP/2!Let’s create a very simple homepage using the Twig templating engine. Because Symfony Flex starts as a micro framework, the first step is to install the library itself: docker-compose exec app composer req twig (run this in a new shell)
Flex is smart enough to download Twig, automatically register it into Symfony and enable Symfony features requiring the library. It also generates a base HTML5 layout in the templates/ directory (we will not use it but you should).
Clear the cache: docker-compose exec app bin/console c:c (this step will become optional when #24642 will be merged)
Refresh your browser, this nice HP should appear:
2 HTTP requests are issued by the browser, one for the homepage, and another one for Bootstrap.
But we know from the very beginning that the browser will need Bootstrap. Instead of waiting that the browser download the homepage, parse the HTML (notice “Initiator: Parser” in Chrome DevTools), encounter the reference to bootstrap.min.css and finally send a new HTTP request, we could take benefit of the HTTP/2 Push feature to directly send both resources to the browser. Let’s do it!
Install the WebLink component: docker-compose exec app composer req weblink
As for Twig, Flex will automatically download and register this component into our app.
Now, update the template to use the preload Twig helper that leverages the WebLink component:
Reload the page:As you can see (Initiator: Push), both responses have been sent directly by the server. bootstrap.min.css has started to be received before the browser even requested it!
How does it works?
The WebLink component tracks Link HTTP headers to add to the response. When using the preload() helper, a Link header with a preloadrel attribute is added to the response:
According to the Preload specification, when a HTTP/2 server detects that the original (HTTP 1) response contains this HTTP header, it will automatically trigger a push for the related file in the same HTTP/2 connection.
The Apache server provided by my Docker setup supports this feature. It’s why Bootstrap is pushed to the client! Popular proxy services and CDN including Cloudflare, Fastly and Akamai also leverage this feature. It means that you can push resources to clients and improve performance of your apps in production right now! All you need is Symfony 3.3+ and a compatible web server (the free version of Nginx doesn’t support Server Push) or CDN service.
If you want to prevent the push but let the browser preload the resource by issuing an early separate HTTP request, use the nopush attribute:
In addition to HTTP/2 Push and preloading, the WebLink component also provide some helpers to send Resource Hints to clients, the following helpers are available:
dns_prefetch: “indicate an origin that will be used to fetch required resources, and that the user agent should resolve as early as possible”
preconnect: “indicate an origin that will be used to fetch required resources. Initiating an early connection, which includes the DNS lookup, TCP handshake, and optional TLS negotiation, allows the user agent to mask the high latency costs of establishing a connection”
prefetch: “identify a resource that might be required by the next navigation, and that the user agent should fetch, such that the user agent can deliver a faster response once the resource is requested in the future”
prerender: “identify a resource that might be required by the next navigation, and that the user agent should fetch and execute, such that the user agent can deliver a faster response once the resource is requested in the future”
It is already as a standalone library by the Bolt CMS. While we’re speaking about interoperability, WebLink can deal with any link implementing PSR-13.
Thanks to Symfony WebLink, there is no excuses to not to switch to HTTP/2!
Learn more about these new features in the relevant Pull Requets: #22273 and #21478.
Your Symfony app is slow? Contact Les-Tilleuls.coop, we can help you make it fast!
