#2 - Breaking down a tech stack (Topic: “Deciding on a tech stack” - 2 of 4)

In this series of four posts, I try to shed some light on how to decide on a tech stack for your project. Read the first post here.

This week's article is about something that also is essential to your decision process, and that is to understand and know how to break down the stack into components.

One of the pitfalls I often see is the lack of a wider understanding of the entire stack (and therefore also project scope) and what synergies that a well thought and planned stack can bring. It’s obvious that when you as a specialist think about a new stack or a component in a stack, then you most likely tend to grab after your newest and most shiny tool. Most stacks consist of an array of different tools that need to work together and create synergy between each other. As an example, let’s say that you have to develop a de-coupled solution, and then just out of pure tech passion pick a brand new cutting edge JS based frontend framework, but you have to support extremely old browsers, and it needs to be hosted on some rusty outdated steal in a basement somewhere, then that framework might not be the perfect match (it might be, right now we are just playing around with the thought of things not fitting together).

Another pitfall I see a lot of developers fall into is the “pre-packaged-stacks”. A lot of frontend specialists are very often dragged towards these packaged stacks such as “MERN”, “MEAN”, and alike because the eco-system is written in the same language through all the different components, so the synergy is very high on that specific point there.

These types of “packaged” stacks have been here forever and are of course always evolving (for the younger audience out there, then some of the first were “LAMP” and “LEMP”.) There is definitely nothing wrong with these types of stacks. But what you should be aware of is that most of them work best for smaller less scalable setups.?I really believe in throwing all the “letters” up in the air and then looking at each component needed for the stack and then finding a “letter” that rhymes well with the others. Of course this is way easier to practice in 2021 where more and more digital architectures become more de-coupled and services based and therefore creates a way bigger freedom to choose the best different components needed for each area of the stack.

So how do you figure out this synergy between so many different moving targets, technologies, and processes? It’s not an easy task, but here are a couple of quick tips and guidelines for you.The way I break down a stack to figure out if each component is viable is by asking myself the following types of questions (depending on what we are building):

• Where should the end consumer actually consume the technology?
• Is the majority (if not all) of the end consumers' devices supported by this / these technologies?
• Can we by investigating the different technologies figure out if it performs as expected for the end-consumer?
• Do we have the necessary skill set to complete the project in regard to the technologies that we are thinking about utilising?
• Are the technologies matured enough to stand the test of time?
• Are the technologies widely supported enough so we can figure out to get help when the s**t hits the fan?
• Does the technology have a substantial number of packages and alike, so we don’t have to code everything from scratch?
• If we do know about a further roadmap, will the technology still be able to be used for that? (The last thing we want is to call our client or stakeholders and tell them that if they want this, then we need to rewrite everything)

?I pretty much ask myself these above questions for each of the following components (whenever they are part of the specs, also remember, there can easily be more than one of each):

• Client / Frontend, the end consumers platform(s)
• Server / Backend, the backend code that will power the frontend and external services with data
• Connectivities, do both the frontend, backend, external services, and misc support the connectivity / data-transport layer that we want to utilise (such as JSON, web-sockets, etc.)
• External services, does the external services have the necessary API’s, SDK’s and alike, so we can utilise them?
• Misc, our infrastructure that will serve the different applications and help persists the data?

It’s of course very important to understand that the above components and what questions we “ask” them can vary much all depending on what the heck we are building. The general thoughts that I’m trying to get across are about breaking down your tech stack, so you can find the perfect synergy whilst picking the best tools for each component in your stack to give combine the best tech 360 degrees of the setup and not just focus on one corner. Sounds easy right??

Next week I will be touching on different fast and easy methods and processes for setting your new idea of a tech stack of to the test before spending countless hours and money on it, in the article called “Test before you invest”.

Here is a quick bonus thing I would like to share with you. The other day at the office one of my colleagues passes me and told me it was a nice article that I have published (Thanks again Mr. Mannucci) but wanted to ask me how long time it takes for me to set a tech stack for a project. It’s a fairly easy question to answer, but getting to the actual answer for the tech stack can be hard…

“It all depends on what you are building and if you have built something that is close to the same thing and therefore already have an idea of the different components, and just like a good pop tune can take under 10 minutes to write and compose, the same tune can take weeks.”

If you just like Mr. Mannucci has follow-up questions about this or other tech-related things, then please don’t hesitate to comment below or slide into my DM.

Have a nice week!?????