Website in Decoupled or Classic Mode?

Redo its site in 2020 Of course, with the new year you’re going to make some good resolutions, and maybe you’re planning to redo your website? So it’s time to ask yourself the right questions: For what purpose(s) Which techno to use How long will it take Of course, even more time must be taken for reflection when creating a website. Because in the context of a redesign, it is not always easy to change technologies, but not impossible! When we talk to e-merchants, we realize that the vast majority use the following CMS: Magento, Prestashop or Shopify (which is starting to break through). And most of the time, agencies don’t try to propose anything else, few propose an in-house solution or one that could go off the beaten track. All about decoupled architecture As part of the redesign of the website, the objective was to integrate a new e-commerce website to our existing application suite (based on the Laravel php framework). Like a Prestashop or a Magento, we already had all the bricks of the e-commerce site: Laravel in backend Angular Universal in frontend Nevertheless, we could have gone on the Magento and React CMS in frontend, it would have been a possible choice. The main disadvantage of having a so-called “monolithic” application like ours is the lack of agility it creates. Indeed, the updates are heavy and lead to a high maintenance cost since they require a complete update of the application (even if the modifications only affect a small part of the application). And in terms of performance, we inevitably find ourselves limited in the use of technologies for the front-office. How does it work? To answer this problem, we have been interested in so-called decoupled architectures: You may be a developer or you work in the web business, the principle of decoupled architecture is certainly not unknown to you. You may have heard of the so-called “RESTFull” API systems. In terms of web development, you either work with an agency / freelance or you have internalized the skills (which is our case at Polytrans). You have certainly noticed that once the backoffice of your application is up and running, the majority of updates concern the front office (so the visible part, the one that requires all our attention to have a good conversion rate and a nice rendering). In fact, the life span between the front and back office is twice as long as the one between the front and back office: 5 to 10 years for the back office 2 to 3 years for the front Here again, the principle of the SoC (Separation of Concerns) would make sense. As we can see on the diagram above, the main difference of our decoupled architecture is the file format that the server renders. Unlike a php file, a JSON file will be lighter and faster to interpret. Moreover, it avoids any page reloading since the content is directly updated in the application running on the client side. This is what we have implemented on the Polytrans website. If you have already implemented a Javascript application, you have already been confronted with the following problem: natural referencing! So we get an application: faster to display (rate increase of the conversion rate) most agile easier to update But that’s not all. In addition to greatly improving the user experience, we will also be able to offer a brand new experience: the PWA (Progressive Web App). PWAs are ultra-light hybrid applications that take the functionalities of your website by adding the application brick (ability to send PUSH notifications, icon on the home screen, offline management…). It is basically the enriched version of a responsive site, which will replace in most cases a native application. As a lead developer, I see another advantage to this type of architecture: the appeal it can generate in teams. Indeed, frontend technologies have been on the rise for a few years now. By choosing a leading-edge technology like this one, you make sure you can easily attract new human resources! Faster updates Thanks to the principle of workspace on Angular, we will easily be able to share these technical evolutions with our other e-commerce site: La Ferme Des Animaux. Indeed, the majority of the components of our application will be used in the same way on the different points of sale. The main differences are in the style and structure of the page content. To illustrate the time saving of working in decoupled mode, imagine that you are on a multi-boutique CMS, you are developing or have developed an evolution (adding an estimate module for example). Once the integration is done on one of the themes of your CMS, you must repeat the operation on the theme used by the other site. You therefore increase the time of integration and update of the application by the number of hosted sites. With the decoupled system, once the component is created for one of the sites, it is directly available for the different sites, all that remains is to adjust the style and structure of the content. Constraints, of course… It is obvious that setting up this kind of application is more constraining and represents more work initially than a simple CMS. It will be more expensive both in development time and hosting costs than a monolithic site. Indeed, whatever the architecture of your IS (Information System), it will be necessary to adapt it to make your site work decoupled. It will also be necessary to duplicate your deployment method, especially if you use continuous integration. For human resources as well, even if these technologies have the wind in their sails, you will have more difficulty finding expert resources on the subject, and what is rare is expensive, necessarily … Conclusion This technology can be applied to any web project, by coupling it to a hosting based on micro-services, such as AWS or Google Cloud, you will get a reactive, easy to update, scalable, and high performance application. More than ever, in the case of decoupled architecture, the implementation of a CD (Continuous Deployment) strategy is very important. Indeed, if a typo had crept into your deployment, preventing the execution of the application, you would have to recompile the entire application, which can take some time. (Time seems even longer when your site is down!). If in some cases, the choice of the decoupled architecture is a necessity (if you want to have a very advanced user experience for example), in the majority of cases, it remains a plus, but a plus that can make a difference!