11 min read

Web App Architecture and Options Explained

Web App Architecture and Options Explained

OK, let's say you are a developer, product owner, or founder. You want to build the next best app for the world. You have decided you are going to build a "web app" because you want everyone to access it. That's a good idea.

Wait, Define Web App Please

By definition a web app is application software that runs in a web browser, unlike software programs that run locally and natively on the operating system of the device.

These days, the stage of choosing web app architecture is often where you get lost in a variety of options available on the software development market.

Imagine a world where you could have your pick of the most modern web apps. With so many different architectural styles available, what should one choose?

Should it be

  • Isomorph
  • Micro front-end
  • Progressive Web App
  • Single Page Application
  • Server Side Rendering
  • Static Site Generator
  • Serverless

What’s the best modern web app architecture for you?

Hire me and I'll tell you 🤑 jk jk

In this article I am going to cover the most popular architectural styles I have seen and will provide insights on which one I would use for certain situations.

First Back to Basics: Web App vs Website

What's the difference between a Web App and a Website?

Websites are a bit old school at this point because the content is static. During the early days of Web2, most internet users would just set up blogs and the content was static.

Web Apps are dynamic and change as the user engages with the software. You use webapps all the time. G-mail, Jira, Asana, Monday, Zoom, Canva, Gitlab, Github, etc.The logic of a web application is distributed among the server and the client, there’s a channel for information exchange, and data storage located locally or in the cloud.

🚨 Hold Up! I'm Confused AF 🚨

I often hear people think Web Apps and Websites are the same thing. Web apps are the evolution of websites. The factors that distinguish a website from a web application are

  • interactivity
  • integration
  • authentication

In other words, the more customizable, interactive and functional a website is, the closer it is to being called a web application.


In my opinion it's always good to know the options available. By no means have I coded something using all of these patterns but I am familiar with all of them.

FYI I love product owners who know a little bit about these options because when they ask for a feature they have a sense of the layers involved and level of work required.

To help you understand if the suggested approach for your product really fits your business needs, we’ll evaluate modern web app architecture types according to the criteria we consider most vital for businesses:

  • Performance
  • UI
  • SEO
  • Linkability
  • Speed of realization on the development side.

3 Tier Architecture

Very popular at larger organization simply due to the fact it allows them form multiple teams focused on different pieces. The key three-tier benefit is improved scalability, since the application servers can be deployed on many machines.

Also, the database does not make longer connections with every client – it only requires connections from a smaller number of application servers.

The three tiers are:

  • presentation tier
  • application tier
  • data tier


The 3-tier web application architecture is a great way to organize your website's layers. If security is a concern, separating the client from database makes it more difficult for a client to obtain unauthorized data. Business logic is more secure because it is stored on a secure central server.

Each tier can be developed in parallel by different teams, and if one of them needs updating or scaling then it won't impact other parts on the site - which makes this type easy for maintenance!


When I worked at WebPT they were looking to obtain enterprise clients. During that transition we started using 3 tier architecture to build our newer apps.

It was a pain because we were still a small engineering shop, but building projects into three big pieces. We would make the UI + B4F(Backend-4-Frontend) and then the database.

It "technically" worked because we shipped out a product. My advice is to have an establish team and plenty of resources to truly gain the benefits of 3 tier architecture. A team of 30 people, makes sense. A team of 4 doesn't

Wouldn't be my first suggestion but it does work.


How SSR works

Ironically, JavaScript development and SEO are often at odds with each other. JavaScript makes websites fun and interesting to use, while SEO makes them available for people to find in the first place. Server-side rendering (SSR) was created to make them both possible.

Server-side rendering refers to an application’s ability to display the web-page on the server rather than rendering it in the browser.

  1. Upon visiting a web page, the web server sends a response to the user’s browser.
  2. The user’s browser renders the page, which is now viewable. Meanwhile the browser downloads JavaScript.
  3. The browser executes JavaScript (could be React, for example).
  4. Now the user can interact with the site.

Websites built with front-end JavaScript frameworks such as Angular, React or Vue all default to CSR(Client Side Rendering).

This is problematic from an SEO standpoint because when web crawlers encounter a page on your website, all they see is a blank screen.


  • SEO
  • Linkability
  • Instant first page load


  • Slower page transitions
  • Vulnerability
  • Complex caching
  • Server cost
  • Higher latency


Here are some popular frameworks. I haven't had the chance to work with Next.js but been hearing good things. I'm a big fan of Gatsby and it probably due to all the hype it initially got and all the great templates they originally put out.


I actually had some really good luck working with SSGs. There was a good amount of money in making personal blogs at the time. I was able to build blogs quickly for different clients.

Fast forward today, it seems like the new thing is newsletter using tools like Substack, Revue or Ghost, but a few years ago it was a traditional blog people needed setup. The quickest way to do that without using Wordpress was SSGs.

How SSG works

  1. You build the code(for example in React)
  2. You generate the HTML and CSS on your development machine before deploying to a server (run build)
  3. You put the generated built code on a server
  4. The client downloads the HTML, CSS, JS from the built code on the server
  5. The client immediately sees content on screen


  • Really fast website
  • Can deploy to a static CDN
  • Security: the attack surface of a static website is minimal
  • Fewer API calls


  • If content changes frequently, it may become stale
  • Need to trigger a rebuild to update content
  • If you have a really big website, build time may be very long


I've use SSG for making one of my old blogs for Vegan Eats(uber eats but for Vegans, should I bring it back?). I use this template and it was all in Jekyll. I had a hard time making customization but the speed of the blog was impressive.

Jekflix | A blog theme for Jekyll
Jekflix is a template for Jekyll inspired by Netflix and made by Thiago Rossener.

Examples of simple static-site generators are Jekyll and Hugo, while Gatsby and VuePress are a fit for the realization of more complex solutions.

Would only recommend to individuals clients, wouldn't bring SSG to an enterprise or startup client as a first option. If Forbes try to run on a SSG, we would run into problems quickly.


How SPA work?

SPA is the type of web application that works within a browser. It doesn’t require reloading the page when new data needs to be displayed.

This web app architecture type is extensively used in our daily life: Facebook, Gmail, Google Maps, GitHub and Twitter – all of them are single-page apps.

It's feels like it my entire career at this point is building SPAs


  • Quick loading time
  • Seamless User Experience
  • Ease in Building Feature-rich Apps
  • Uses Less Bandwidth


  • Doesn't perform well with SEO
  • Uses a lot of browser resources
  • Security Issues

Most of my web dev career has been working on SPAs. We created SPAs for Ticketmaster to help manage inventory for events. We used SPAs at WebPT to help PT manager their clients better. I am working on making an SPA for Drone Aerial Services, right now. Follow us on Twitter to learn more. SPAs are popular and a good choice if you care more about user experience and capabilities than SEO.