Here, at AUTO1 Group, we are growing. Not only in terms of company size, number of employees, revenues, etc, but also in terms of database size, amount of servers, lines of code in applications, amount of accessible pages. For supporting this growing codebase we are adopting new approaches and new technologies. Different innovations were already introduced, but today I want to tell You about switch of a paradigm from MVC to SPA, and how implementation of SPA approach evolved.
\nWe have our internal application, called Admin, which is heavily used by hundreds of colleagues in many countries. Historically, it was written as a monolith php application, based on Silex (and later Symfony) frameworks (some overview is present in this blog article). Admin application had architectural layers, which fell into a concept of Model-View-Controller (MVC). The View part, which is in essence the HTML code of all pages, was prepared on web-server using TWIG templates. Usually, one developer was working on both back-end and front-end implementations of web-page. That was called Full Stack development.
Downside of such approach became obvious when first HTML tables with complex internal structure were implemented. Lets take as an example a page that displays hundreds of cars, provides pagination, possibility to edit data, shows aggregated results, etc. Such page consists of static components (navigational menu, list of available locales, information about current user, html-template, that renders appearance of the page, etc) and dynamic components (information about cars). This kind of web-page is hard to build for a single person. Knowing that development cycle of such complex pages could be split between several software engineers, we divided responsibilities between back- and front-end developers. We decided to generate the View part of MVC architecture in client's browser instead of application's server.
And this was exactly the case, that fitted well into SPA paradigm.
\nSPA stands for Single-Page Applications - an architectural paradigm, that divides elements of the page into static and dynamic. Static elements of the page (such as page layout, navigational menu, user information) should be loaded into client's browser only once per user session. The page layout rarely changes. On the contrary, dynamic components of the page can be updated continuously.
\nRegardless of the technologies involved for rendering a page in client's browser, main difference between SPA and non-SPA approaches is whether a browser requests each time full page content (including static content, such as layout, menus, etc), or it requests only the important (dynamic) content. This difference can be seen in a diagram below.
First picture represents traditional request where full page contents are passed from web-server to a browser on each request. Second picture illustrates SPA approach: full page content is fetched only once, afterwords only dynamic content is downloaded and full page reload does not happen.
\nStarting from a monolith application, where HTML was rendered on a server-side, we gradually moved to our current state, where a separate application serves SPA for us. But let's go step by step.
\nAdopting of new front-end technologies, such as JavaScript library React, allowed us to start building first SPA pages. React code is executed in the web-browser. Front-end (React) developers became responsible for all the visual representation of a web-page.
\nFor organic integration with new technology we updated existing workflow of generating HTML of the page. Specifically, we introduced several new endpoints, that provided essential information for rendering HTML page layout. Those endpoints were:
\nFront-end developers wrote React code, which could fetch data from aforementioned endpoints and render HTML5-compliant page layout.
\nNow we needed a way to pass this React code from web-server to client's browser during initial page load!
\nThis was achieved by introducing of what we call SPA-controller: set of php application's code (written with Symfony framework), which returned very basic standard html template that contained latest version of the React code. Being executed in the browser, this code rendered HTML contents of specific SPA page.
\nUnder the hood of SPA controller we implemented such functionality:
(if template was not cached, or TTL of the cache is over) do a request to CDN, that contains actual version of front-end assets
\nThe response contains lightweight HTML similar to this:
\n<!doctype html>\n<html>\n <head>\n <meta charset=\"utf-8\"><meta http-equiv=\"x-ua-compatible\" content=\"ie=edge\">\n <meta name=\"viewport\" content=\"width=device-width,initial-scale=1,shrink-to-fit=no\">\n <title>SPA index</title>\n <link href=\"https://cdn.xyz.de/1.2.3/main.css\" rel=\"stylesheet\">\n </head>\n <body>\n <noscript>You need to enable JavaScript to run this app.</noscript>\n <div id=\"app\"></div>\n <script type=\"text/javascript\" src=\"https://cdn.xyz.de/1.2.3/main.js\"></script>\n </body>\n</html>As You can see, SPA index page contains none of the data that should be shown on a page. This data will come as a result of subsequent requests.\nStages of building SPA page are illustrated in the diagram (notice 3 phases):
\nAs a result, we implemented a Golang application, that did exactly the same, as it's predecessor-monolith, but outside of php environment. The current page lifecycle started to look like this: This is pretty good, huh? Of course, there are challenges in current approach also. We are investigating the best way to deal with user locales in SPA index, we learn how to do proper caching and authenticating user, but this is a topic of another story!AUTO1 Group
\n#spa #monolith #mvc #engineering
","fields":{"slug":"/spa-evolution/","tags":["auto1","SPA","monolith","MVC"]}}}]}},"pageContext":{"slug":"/tags/MVC","tag":"MVC","categories":["Architecture","Coding","DevOps","Engineering","ProjectManagement","QA","Social","TechRadar"]}}