API Platform provides many features that we need and is a stable, mature and well supported project
Integrates seamlessly with Symfony
Can support multiple data providers with a default back onto Doctrine
Solves many of the issues that we have around pagination
A lot of our entities (campaigns, landing pages etc) should be able to be migrated over
Using queueing instead of cron jobs which makes it much more scaleable and allows you to prioritise etc.
Symfony Messenger will provide the queue which can have multiple transports such as Redis, RabbitMQ, Beanstalkd or just the default Doctrine database
By default you will still be able to use Mautic as it comes, out of the box, without using all the other technologies that help to scale
From Mautic 4, where we are planning to introduce support for Composer 2 and the Mautic Marketplace, users will need to be in a hosting environment where they can create and work with folders located one level above the public_html directory - in many cases this will mean that the lower end shared hosting environments will not be supported - this will also be the case for Mautic Next Generation.
Alan gave an overview of how we are envisioning the architecture from a proof of concept perspective:
React front end - Allows you to roll your own front end and pull in the default components and also your own components
App that pulls in sections of Mautic through components
These are our thoughts - need POC for the front end to confirm
API Platform - pretty straightforward but we will need a basic POC around that as well with a Symfony 5 application with API Platform with the data persisters and data provider interfaces to implement for something simple - maybe something like the Assets bundle
Acquia will have resources to dedicate into Q2, Q1 will mostly be working up the POCs
The challenge is going to be the front-end experience as we do not have many Javascript/React developers
Nico Grienauer asked if we could look at the naming conventions that we will use going forward (plugins, bundles, addons, contacts/leads/segments etc) - as this is a good opportunity to make changes
Alan Hartless also raised that we need to think carefully what we are going to do for feature parity and the migration path, and how we support third party plugin providers/hosting providers
Nico Grienauer raised that we really have to think carefully about how we are going to communicate this - especially if it will launch with less features
Alan Hartless said that if we do an MVP then we should do it really well - and not make the mistakes that we made with the current Mautic by shipping features which are not well polished. We should do less features and do them really well, rather than spread the net too wide and have things not be fully polished.
Action items
POC for front end - to complete in Q1
POC for API Platform / Symfony 5 / Assets bundle - to complete in Q1
Decide what features are the ‘must have’ in the MVP and evolve from there - by end of February
Determine what skills we need from the community
Determine who in the community are interested in contributing
Break out into sub-projects which we can chunk down and assign to folk
Decisions
We will create a POC for the React front-end and use the assets bundle as a POC for the back end