Web Application Architectures

In the ever evolving and fast paced web space, engineering web applications now involves in making a lot of decision making. One of the most important decisions to make is, what kind of web app are you going to build. Here, in this article I am going to talk on a high level about the various approaches, their characteristics and challenges.

MPAs

Characteristics

        Multi page application is a type of architecture where on every link click or form submission, a new request is sent to the server which in turn responds with a new page, assets and data.

Typically you will see your browser’s loading behaviour like spinning animation near the tab and ‘waiting’ text at the bottom. Navigating from one page to the other page also reflects the changes in the URL.

Challenges / Drawbacks

        Since browser have to wait for server responses and then re render the UI based on the new response the UX is not very ‘modernish’. Users would lose interest on staying on the same tab and move to other tasks.

        Separation of components and huge bundle app sizes could cause more problems on the UX side.

        Storing / caching previous results / actions of a user could be challenging to track on the current page or involves unattractive work arounds ( writing to local storage or other storages of browser).

SPAs

Characteristics

        

        Single page application is a type of architecture where on every link click or form submission the user stays on the same page, the interaction with the server is done mostly via AJAX calls. Navigating to links causes new components to be rendered on the browser itself and if any new data is required then again, an AJAX call is made to the server to fetch it.

        Depending on the layout you may or may not see a change in the URL. You will not see the spinning icon on the tab or the waiting text at the bottom, instead you will see spinners \ loaders in the UI itself to give feedback to the user.

Challenges / Drawbacks

        Since everything could be stored in global stores (Flux, Redux, Vuex, Mobx ) all data is available in the entirety of the application. Although at first glance this may be good, in some scenarios this may lead to showing of unwanted or stale data. This gives an overhead to the developer to always worry about clearing the data in global store that is no longer needed.

        Since browser handles loading of all components, this leads to more browser processing and memory usage. The problem intensifies when we think about how much of free resources are available to the user’s browser as different users have different load capacities on them. Planning for such scenarios could be very difficult.

Since the components are rendered by JS, this takes time and web crawlers usually don’t wait so long until the JS is loaded to grab content and move on. This leads to SEO issues.

SSRs

Characteristics

        Server Side rendering application is a type of architecture where it is similar to an MPA but also has some characteristics of a SPA. SSRs initially rose in popularity because they solved one of the problems in SPAs which is SEO.

        Typically in SSRs then web server actually loads a components DOM and then sends it to the browser, this leads to less overhead initially for the JS engine on the browser. Also because of the content already rendered on the server, the crawlers have content to grab and move on. After the initial page load, the further interactions could be done dynamically on the front end itself.

Challenges / Drawbacks

        Most of the time since new requests are made to the server for links and form submissions, it suffers the same challenge or drawbacks as MPAs.

        Since the rendering is done by the server, the server needs to understand JS components. Right now only JS based web frameworks can perform SSR.

        Client side Hydration: Sometimes there could be a mismatch of the DOM generated on the server side vs the client side. And since JS frameworks rely on virtual DOMs, the different DOMs could cause issues for virtual DOM implementations.

PWAs

Characteristics

        Progressive web application is a type of architecture that has been recently promoted by Google. PWAs are a recent trend, initially it was a brain child of the Big G.

        Although PWAs can be any of MPA / SPA / SSR, it has some characteristics of its own.

        PWAs offer native application UX in the form of offline notifications, offline website caching and partial app updates.

Challenges / Drawbacks

        Since PWAs rely on service workers to provide offline experience, an overhead is present with respect to learning service worker registration hooks and it has an increased deployment complexity.

Takeway

        Having a good knowledge on different types of architectures is crucial. Deciding on a web architecture is crucial during the planning phase of a web application. The application’s use cases need to considered carefully in deciding the appropriate architecture.

References

https://seventablets.com/blog/what-are-progressive-web-apps-are-pwas-the-apps-of-the-future/

---