Different Types of Full Stack Architectures

Question

I have built a few stacks in my time as a self-taught full-stack developer, but I think there may be a hole in my knowledge that you can hopefully fill in for me. I have built a few stacks that all have a core architecture like this:

• Backend in Go, interfacing with a Postgres database or doing some core logic
• RESTful API server (also written in Go) serving over HTTPS that triggers database methods/backend logic
• Frontend in JavaScript using ReactJS or some other framework. The front end makes calls to the API server (using fetch()) whenever data is needed/logic should be executed (on the backend).

I find that this is a pretty good, common architecture that can work in many different use cases. However, I am wondering if there is any other type of core architecture that differs from this. I have heard of GraphQL and I see how that is different than this traditional REST-like architecture, but I am wondering if there is some other type of architecture used to build web apps that does not revolve around a REST/SOAP/GraphQL API. I've heard of WebSockets, and I think that they fit into what I am asking about here, so how are they different from just calling JavaScript's fetch() to make calls to my REST API (or using a third-party library like axios.)?

Answer 1

The architecture of your application is whatever you decide it is. The alphabet soup you've mentioned in your question is just the ones that are more well-known. Each approach has its own features and advantages.

How websockets is different is that it's more "real-time." It's not uncommon to have a REST architecture that is supplemented by websockets to provide things like real-time dashboards, or the "this post has been edited, click here to reload" banner you sometimes see on Stack Exchange sites.

When you create a websocket, you open a two-way communication channel. This clearly differs from the other architectures you've mentioned, as those architectures are based on querying the endpoint to obtain some data. It's the difference between making a telephone call each time, and leaving the line open while you talk.

Answer 2

You're asking broadly about web app architecture, but focusing solely on client-server communication, i.e. the application layer. The style of communication doesn't really change the overall architecture pattern; these are just different data types or protocols. That's an implementation detail of an architecture, not the architectural pattern itself.

You can find some useful primers for web app architecture patterns, but here's a quick list (and a super elementary description) of some of the most common:

• Client-server, which is what you have described
• Microservices, wherein the UI interacts with several backend servers with specialized domains
• Layered, wherein concerns in the backend (and sometimes the frontend, as with a robust Redux service, for example) are broken into different concerns-- good for testability
• Peer-to-peer, wherein clients serve as both consumers and suppliers of resources

These aren't necessarily mutually exclusive. These can all be combined in different ways based on the needs of the application.