Header image

Symfony Finland
Random things on PHP, Symfony and web development

Symfony & staying relevant: React.js rendering, GraphQL and Neo4j OGM

Symfony2 just turned five years old some months ago. This is an eternity in the web world and you average technology stack has likely grown in complexity since then. In addition to the standard components in LAMP you'll likely be peddling with a number of complementary technologies.

Today it has become more important than ever for a web framework to be able to adopt to new trends and technologies. With the bundle structure in Symfony acting as first class extension points, the Symfony framework has been able to keep up with the changing world.

Through the years the Symfony framework has kept is focus of providing the essentials for structured back end web development. This minimalism and focus has enabled an ecosystem of platforms built on the framework to thrive. Rather than many CMSes and RAD frameworks, Symfony itself is not laden with a specific UI, data model or get bloated with edge case features.

This has enabled developers to pick whatever technologies they see best. Developers can enjoy the freedom of choosing UI technologies, supporting persistence engines ranging from key value storages like Redis to Document storages like MongoDB to traditional RBDMs like PostgreSQL.

Together with Docker now providing a sensible platform for handling the management of the external daemons, Symfony provides a stable base for building applications on microservice or monolithic architectures.

The stability and flexibility have enabled Symfony to take hold also in more conservative industries like travel, where the backend systems are critical. In addition to Node.js, a technology often used for data aggregations - Open Source is seeping into business critical applications in areas previously ruled by technologies such as Java and .NET.

Next let's take a few options that developers of contemporary web applications may choose to adopt in their Symfony full stack framework applications when needed.

React.js Server Side Rendering with ReactBundle

React.js is a wildly popular User Interface library written in JavaScript. It is nowadays widely used by both industry giants like Apple (for their API docs), well as popular web content publishing tools (WordPress.com for their Calypso shell) and advanced UI components like the Alloy editing tool from the Liferay project.

As a front end technology one might at first wonder what has all of this got to do with a back end technology like PHP and Symfony? The answer is that React.js components can be rendered on the server side. This increases first load performance and enables optimal SEO by providing robots a readily rendered HTML structure.

Server side rendering of React.js using PHP has been discussed on this blog before:

Both of the above articles were more of proof-of-concept type of implementations, but now there is a more mature option available for Symfony developers to do server side rendering of React. The ReactBundle from Limenius draws inspiration from the Ruby on Rails implementation and is a fully featured solution for rendering React with Symfony:

  • Prerrender server-side React components for SEO, faster page loading, and users that have disabled JavaScript.
  • Twig integration.
  • Client-side render will take the server-side rendered DOM, recognize it, and take control over it without rendering again the component until needed.
  • Error and debug management for server and client side code.
  • Simple integration with Webpack.

GraphQL APIs with the GraphQLBundle

GraphQL is a standard for creating web APIs. It is a complementary technology to REST APIs and as a standard, rather than an architectural model that REST is, it enables creation of both universal API servers and clients alike. For the client side there are many interesting options, such as Apollo:

Apollo is an incrementally-adoptable data stack that manages the flow of data between clients and backends. Based on GraphQL, it gives you a principled, unified, and scalable API for developing modern apps on top of services.

For the server side there are plenty of options again, ranging from BaaS services like Reindex to the JavaScript reference implementation and full solutions tightly coupled to a CMS, like the Drupal 8 GraphQL module. In addition GraphQL PHP libraries like the one from Youshido are available.

The Youshido GraphQL library now also comes with an integration bundle to Symfony. This enables you to integrate the existing GraphQL server library to your Symfony applications without reinventing the wheel. The library and the accompanying integration bundle come with the following high level features:

  • Full compatibility with the RFC Specification for GraphQL
  • Agile object oriented structure to architect your GraphQL Schema
  • Intuitive Type system that allows you to build your project much faster and stay consistent
  • Build-in validation for the GraphQL Schema you develop
  • Well documented classes with a lot of examples
  • Automatically created endpoint /graphql to handle requests

An Graph Database storage layer using Neo4j over PHP OGM

Data persistance is a staple in web development. A vast majority of web applications are at their core just CRUD (Create, Read, Update, Delete) applications. This is why databases of all sorts are a central concideration when architecting a web application.

Symfony itself does not dictate any specific data storage model, but it is likely used together with the Doctrine ORM (Object Relational Mapper). The Doctrine ORM handles data storage in a relational database by automatically hydrating and de-hydrating data objects to an RDMS.

In addition to traditional relational databases (such as MySQL, PostgreSQL and others), the NoSQL movement in the early 2010's resulted in a number of interesting data persistence objects. NoSQL is a wide concept that can range from key-value storages like Redis to document storages like MongoDB.

To add to the mix, popular RDBMs systems have started adopting NoSQL features with PostgreSQL and MySQL both now shipping with support for JSON field types, offering NoSQL like capabilities as well as the relational database models. They make great hybrid storages for many use cases.

As for using these various types of storages with an abstraction, there is the Doctrine ODM (Object Document Mapper) for example. It replicates the ORM functionality on a high level, allowing storage to MongoDB instead of a relational database. Doctrine ORM and ODM have similar APIs and are quick to pick up.

The Doctrine project actually offers an ODM (Object Document Mapper), which replicates the ORM functionality for MongoDB. The API and concepts are very similar to the ORM and if you've used either, the other one is quite fast to pick up.

A branch of NoSQL are Graph Databases. They allow storing content as well as relations between them. They have been around for quite a few time, but are not very common place in a lot of web development projects. The storage model and performance makes graph databases optimal for applications such as social networks.

Neo4j is currently the most popular database in the world. There is a PHP OGM (Object Graph Mapper) from GraphAware that aims to integrate Neo4j to PHP similar to ORMs and ODMs. in fact the OGM uses Doctrine Annotations and the Doctrine Collection library under the hood.

The PHP OGM is still in early stages, with a 1.0.0 release looming in the horizon at beta20. If you're interested in learning about Graph Databases and Neo4j in specific, the GraphAware Neo4j PHP OGM Documentation is a great place to start.

Written by Jani Tarvainen on Tuesday September 20, 2016
Permalink -

Leave a comment

comments powered by Disqus

« How to implement AMP (Accelerated Mobile Pages) on the eZ Platform CMS - Using CQRS/ES for Content Management Systems (CMS) »