Developer platforms built with the Symfony Framework
The mass of web developers work with products that target non-technical audiences. This means everything from creating a website with WordPress to a bespoke implementation of a customer information database. The end results target either consumers or people who are expecting some kind of business results.
Catering to a market of other web developers takes it up a notch. From developers creating the Symfony components or front end technologies such as Angular 2 or React, they are all working to create something others will build on top of. This audience is often very demanding and unlike custom implementation projects, the development is done in public in an Open Source community.
Software is a rabbit hole of fingerpointing: The application developers can point the framework in use, who in turn can point their fingers at component developers, who can point their finger at the programming language, who can point the finger at the programming language that the programming language was developed in... Eventually this can boil down to a decision someone made in the 1970s regarding a CPU microarchitecture, due to the limitations at that time.
Ok, so maybe PHP sucks in some ways. But that does not change anything for the task at hand, now does it?
The Symfony Framework as a Platform
The Symfony Project has excelled in providing tooling for developers. From custom platforms like Laravel and Drupal using Symfony Components to extensible platforms built ontop of the Symfony Framework, Symfony is everywhere.
Nowadays taking shared PHP components to use is easier than ever thanks to Composer being the standard distribution method. Choosing an extensible and a stable platform remains challenging; Striking a balance between being opinionated and open enough is tough.
The position where the Symfony Full Stack Framework is at seems to be quite optimal. There are a number of complex implementations of products solving specific problem domains that are platforms in their own right:
- Akeneo: A Product Information Management (PIM) for companies managing their internal data
- API Platform: A web framework to build modern, API-first web projects
- eZ Platform: A flexible CMS/CMF for working with complex content structures
- OroCRM: An extensible Customer Relationship Management (CRM) platform
- Sylius: A comprehensive eCommerce platform
Each of these Open Source product specialize in solving their individual problems in a specific way. They share the same foundations, such as directory structure, event dispatching and form implementations. Each project adds functionality via the mechanisms offered by the Symfony Framework.
They are not tied to any specific data model or user interface, meaning that none of them really look or feel like a "Symfony Framework Application" from the outside. Simply because there is no such thing. This offers flexibility, as shoehorning a CRM and an eCommerce platform to a data model and an interface created for managing websites will lead to compromises in the long run, for example.
Conclusion
The Symfony component and the bundle model offered by the full stack framework have proven to work well for creating additional platforms that developers can and enjoy working with. This is largely due to the nature of the individual components being well thought out and bound together in an extensible way.
In the future the common technology stack exposed to the end customers is expected to move more from lower level technologies (such as JavaScript, PHP, Symfony or a specific CMS) to a collection of products that are integrated together. This is what the enterprise commercial software world has done for a long time.
Using RESTful interfaces for communicating between different products built with different technologies is commonly done, for example with Java technologies such as Camunda, Neo4j and Solr. While this is a valid approach for these cases, there are benefits in not over engineering everything to a separate microservice.
Having services from different problem domains available in your custom implementation code makes it straightforward to work with them. Currently merging two large scale project using the Symfony framework internally is not common nowadays, but can be done - as the integration of Sylius and eZ Publish proves.
In the future platform built with the Symfony Framework should invest in making them easily available to any Symfony application. Splitting out useful individual components (like the eZ Platform siteaccess functionality) help avoid a lopsided open source relationship where the other side gets a lot, but gives very little back.
It's always good to remember that other developers are the most demanding audience for a developer.