Copy of Mautic Next Generation 2020-12-14 Meeting notes

Outline of history and how we got to where we are now

@Alan Hartless

• Mautic was originally built for the smaller instances - it was not built with scale in mind

• There is a lot of code used for many purposes, the way Doctrine manages data, is a real challenge for scale

  • The Mautic 3 process showed us the scale of the problem that faces us - we would be spending years trying to address this issue by refactoring

Review of Marchitecture plans

@Alan Hartless

• 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

• Open

  

  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.