Designing Web Applications-Architectural Components

Photo by Javier Allegue Barros on Unsplash

What are the most high level components of web applications?


Before you start choosing technologies

Time frame for development


  • Is it a startup MVP? If so, you’d like to keep hiring in mind — choose technologies that people know, so that the pool of experienced candidates is as big as possible. Choose technologies that people want to work with, so that potential candidates are excited to grow in your organization.
  • Maybe it’s a side project? Then you want to keep your long term goals in mind, think about the next job you want to have or a technology at your current company that you want to master.

Knowledge in the team

Product characteristics

  • Security, regulation: maybe the product is in the domain of health, and saves users’ sensitive personal information. In this case you should pay extra attention to security from the very first user. Maybe you need to be GDPR compatible pretty soon? In that case you might want the servers in Europe.
  • Mobile vs. web: if the product will contain both web and mobile versions, you might want to use React for the web front-end and React Native for the mobile. You’d want to consider working with GraphQL, because it allows smaller objects in the transactions, which is better for possible smaller bandwidth that might occur if the internet is bad. If most of the app is front-end and there’s just a thin layer of backend around the DB, you might want to use Node for the backend, to allow flexibility of the people who work on the project.
  • Continuous deployment (CD) or not: It’s considered best practice to do continuous deployment (release every new working feature to production without waiting for a certain “release date”). However, some products don’t allow using it: games that has specific release date, health related products that are under regulation and need massive QA cycles, and more.


  • How long will it live for: is this a short term project, a POC? Or maybe it’s just the beginning of a product that will change a lot following feedback from users? Maybe there’s one shot to create it and it will stay the way it’s been created?
  • Who will maintain it: will it be you? If not, will you have time to onboard the maintainer(s)?


Remember: always check before using

So now we’re ready to start..

Photo by Clay Banks on Unsplash

Back-end decisions


  • Dynamically / statically typed vs. type inference: one of the main questions we might ask ourselves is do we prefer to work with dynamically or statically typed language, and do we prefer to work with a language that infers the types. While it’s correlated, it’s not the same — dynamically typed languages will check type related errors only in run time, while statically typed languages will check it much often, in compile time. But that doesn’t mean the types will be written by the developer necessarily — that depends on the language design. If a language determine the types from the context — it supports type inference. While this is a big difference between languages and people tend to feel strongly about it — I personally think it doesn’t really matter to most projects.
  • Popular: Like mentioned before, if we choose popular language, we can hire more easily because the pool of talents is bigger, and because people will be excited to work on it. There’s another important reason to choose a popular solution — the community. Can we find our questions online with answers? Are there a lot of posts explaining how to do things? Have many people tried to do complex stuff with it, which might cause necessary evolution?
  • Leader / team preference: In my opinion, this will be one of the main reasons for choosing the language. If the team doesn’t like working on the code base — the motivation will drop and it’ll take longer to develop.
  • Relevant for domain: different products need different technologies’ characteristics. For a machine learning I’d choose Python over JavaScript, because Python has a lot of relevant libraries that haven’t developed yet in JS. For a project with a huge front-end and tiny back-end I’d choose JavaScript full stack (to the back-end as well), because I want to be flexible with adding people to the team and the time spent on each end.
  • It’s not forever and not sole: high chances you’d write micro services at some point. You will be able to use different languages for different micro services. And you can always migrate.
  • Opinion: performance is less important: Java is more performant than JavaScript, which is more performant than Python. Does that mean that for a project with a lot of processing you necessarily need to choose Java? I don’t think so. At the beginning the performance is not prioritised, and we don’t always know what will be the problem performance-wise. Keep it simple! First create a product. If you encounter performance issue — solve it then.

Framework / server


Micro Services

DB Decisions

Relational (SQL) or non-relational (NoSQL)

But is that the right question to ask?





API Decisions

REST. From:

REST Vs. GraphQL

HTTP vs. WebSockets

Front End Decisions

MVC vs. SPA vs. SSR apps

  • Model View Controller model was the popular front end architecture ten years ago. In this architecture, the server sends HTML pages to the browser, with the relevant data inside them. The pages are created in the server using template engines.
  • Single Page Application is the most popular way to create front end applications today. The front end code is downloaded completely to the browser, many times from a different cloud than the server, and it communicates with the server in JSON objects only, updating and fetching data, and not HTML files. This way, the front end can have a state that is kept throughout the use of the app, and is not reloaded every time the server sends a new HTML page (see the state section next for elaboration).
  • SSR (server side rendering), or universal/Isomorphic apps: it’s a mix between SPA and servers that serve the HTML pages. It’s good in case you have to load the first page really quick, or you need advanced SEO. But these are usually needed for marketing websites, that you don’t want to create as SPA applications anyways (in most cases), but as a Wix or Word Press website.


  • React Vs. Angular Vs. Vue Vs. Web Components: all of these four are modern ways to create front end applications. “The front end wars” have been going on for years now, with people trying to decide to which platform to migrate. Vue was heavily used in the east, so a few years ago I wouldn’t recommend using it, cause of small western community. But in the past couple of years this has changed. I love the documentation of React, as well as its diverse approach to developer teams and the eco system. Angular is supposed to be better fix for large organisations, but I don’t have personal experience with it. And Web Components are way to create front-end app which is platform agnostic, and is (supposed) to stay here forever, even when other platforms will stop being supported.
  • State management: front-end components need to share information between one another, and it’s saved in a global state. This state is hard to manage, and there are a few great solutions for it today. The most common one is Redux, which became unnecessary for React apps in many cases with the publishing of the new hooks API. An alternatives are MobX, and Apollo, a GraphQL library. Global vars can be saved also in session storage / local storage, but that’s recommended for very specific usages as you can read here.
  • UI components — Bootstrap / Semantic UI / Material design / Ant design: it’s not recommended to create the entire graphics of the app from scratch, even if it’s a big company. Relay on one of these libraries and modify it. To choose between them, consult with a designer! You want to choose the library that is most similar to the design you need. Also check how flexible it is to modifications, cause some of them aren’t.

Deployment of SPA

  • S3: a storage service of AWS that behaves like folders, and can be configured to a domain, so that browsing to that domain will download the front-end code and run it.
  • Netlify: my personal favourite, a cloud for deployment of static apps, allows auto deploy from different branches to auto generated domain names, saves history, comfortable pricing model.
  • GitHub pages: another popular alternative.

Cloud Decisions





Server location / Regulation

Can use more than one!

Configurations differences


CI/CD Decisions

How to deploy

Different environments

Build & Test platform

Logs / Monitoring Decisions

Front-end logs


Security Decisions

Prevent XSS attacks

Prevent DoS attacks

Don’t save raw passwords in the DB

Don’t save keys in the code

Use unique, hard passwords for prod with 2fa

Processes Decisions

Git flow

Stack updates

Code Review

Sprint planning / tasks management



Here’s a cute dog before we continue

Other Decisions

Domain management

User management

Common Mistakes

Over Engineering

How to become familiar with these stuff

Do side projects

Work at different, innovative companies

Be a CTO at a startup

Ask a friend




Engineering Manager at Kry. Co-Founder of Podcasting @extend_podcast. Twitting @dafnaros.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

My Big Data Journey with Cloudera

A search-first mindset

Build your First DAO and deploy it to moonbeam network PART1 : Setup and play around

In programming, the first solution isn’t always the best

What you need to know about Winible’s presale

Applying PSPs to istio-cni-node pods

Flutter and Its Huge Potential

Stuck Learning How To Code? Read This.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Dafna Rosenblum

Dafna Rosenblum

Engineering Manager at Kry. Co-Founder of Podcasting @extend_podcast. Twitting @dafnaros.

More from Medium

Getting started with React Hook Form

My experience with creating a Solid application


React countdown timers simplified.

How to bring the micro into the frontend