🕑 Estimated reading time: 5mn
By Marty Lamoureux, CTO & Co-Founder @ DynamicScreen
DynamicScreen is a company that created an application that allows companies to stream content on screens. Contents can exist under different formats: plain text, images, videos, facebook posts, tweets, etc. The underlying code is always pretty similar, which calls for a specific architecture.
To avoid maintaining different variants of the same product for each project or each client, the project has been subdivided in a core and components. The main objectives of the architecture would be the following:
The approach of using extensions would allow the Core codebase to remain the same without needing hacks to add features. In addition, the extensions code would be completely separated from the Core, which makes it possible to mix and match extensions across environments, projects and customers! Nevertheless, with this advantage comes two important drawbacks: compatibility between the extensions and the core and between the extensions themselves and, in Laravel, the exposition of the Core to the extensions, meaning that any extension can potentially retrieve sensitive data using the framework methods.
The system contains four main components: the application core, the extensions, an extension support and an extension kit. The extension support is responsible for handling and loading extensions while the extension kit contains common code, interfaces and abstract classes to normalize their implementation and interactions.
You will need two elements to implement such a system:
In the case of this particular extension system with Laravel, it has been decided to add an
extension directory containing the application extensions, its own
composer.json file to resolve them and a
providers.json file with the extensions to load.
Each extension stems from the Extension Kit, which contains a
boot and a
register method and some useful functions. The extensions do have access to the application core, though. The Extension Manager receives the extensions and handles the rest.
This system is portable across multiple applications and even technologies, provided it can be rendered compatible.
They are but the dependencies resolved by Composer and the autoloader are persisted on the disk and reused.
The application and its extensions are handled separately. This makes the application as independent as possible from its extensions, loaded as mere dependencies.
Multiple applications can exchange information and might not need the same extensions. The current implementation provides minimal overhead by just loading required extensions. Moreover, some extensions are client-specific and should not be exposed to other clients.
Even though extensions are very light and should never conflict between each other, the autoload
boot method should help solving conflicts.
Yes. There are four developers on the solution and they have access to all the modules and each environment. Of course, not everyone can publish changes to the production environment. Some of the trade-offs of the solution have been made to accomodate the development environments.
All extensions are tested together in a special test environment. This means that client-specific extensions and general extensions are present at the same time. This method helps avoiding regressions.
By Julien Vitte, Lead Web Developer @ InsideGroup
Laradock is a set of preconfigured Docker containers using Docker and Docker-compose, preferably with Linux.
The Quick start is very straight-forward:
# Clone the project git clone https://github.com/Laradock/laradock.git # Generate your .env file cp env-example .env # Run your containers docker-compose up -d nginx mysql phpmyadmin redis workspace
The main advantages of this solution is to easily setup your development environment, switch the versions of the supporting infrastructure and dependencies, the separation of each component, trusted base images, full customizability, etc.
The only thing you should know is that your code will be run in the
workspace service. And that is it!
How can you make this better? By automating most of it using Makefiles or automation tools of your own choosing. You could install the solution, manage your environment and configure it like a submodule to integrate it seamlessly with your projects.
Laradock only works with PHP and the services configuration is already done and homogeneous so you should never have to edit the Docker-compose file yourself.
The submodule allows the code modifications to be propagated through your environment. This can make your Laradock dependencies configurable across projects and independent updates still possible, while being able to use the automations in every project.