Full Stack Developers Are Unicorns

Full Stack developers are unicorns. Looks beautiful on paper, but is a myth...are you triggered yet? What does this guy mean? I am most certainly a full stack developer, you say? Let me take you through the history and descriptions of full stack, and let me see if I can give you a bit more nuanced view of the matter.

What is considered full-stack?

Traditionally, a full stack developer is a developer that handles both the UX/UI and the data fetching of a front end application. With today's frameworks usually the front end is developed using a framework, such as Vue, React, or Angular and written with JavaScript or TypeScript. The back end for these kinds of projects is often written in JavaScript on Node.js, Kotlin in Ktor, Python in Django or others. There are countless frameworks for both the front end and the back end. My argument is that these back end solutions are not really back end.

Isn't back end? What do you mean?

Let's start with the definitions, from Oxford Languages.

Back end: the part of a computer system or application that is not directly accessed by the user, typically responsible for storing and manipulating data. "[The] back end has three parts to it: server, application, and database".

Front end: The part of a computer system or application with which the user interacts directly. "Designers tend always to work on the front end".

So, if we're looking into the back end definition. The server is the physical or virtual server and contains the operating system and an environment on which the back end code can run. It also contains the database, which contains all the data for the application, or for several applications. The last thing is the application or the code that provides the data to the front end.

If we go back one step to when MVC was popular, or Model, View, Controller - as it stands for. Model are data models used to transport information between the view and the controller. The View is the visual part of it, and the Controller is the code that prepares the data to display. If we tie this down to the well-established software architecture model of "Three Tier Architecture" this only serves the purpose of Presentation Tier.

What is Three Tier Architecture?

It is considered a well-designed architecture to separate concerns within an application. The three tiers in a three-tier architecture are:

1. Data Tier - usually a database of some sort.
2. Application tier - this contains all the business logic and makes the results available through APIs in a generic purpose API, not adapted to a special application, but to the company's needs.
3. Presentation Tier - This tier is the interface to the end-user. The main purpose is to present data and receive data from
   users. This may also display data in a more "user-friendly" way.
   
   

So what do you call my website back end?

It is a part of the presentation layer. It is often useful to restructure, combine or merge data before presenting it to the end user, in order to make it more user-friendly. Another function in this layer is to obscure API end-points, store secret keys, etc. But this level should never contain any business logic, and in my opinion, never access a database directly - other than content databases explicitly made for the purpose of serving front-end with text, pictures or other content, or cache databases, like Redis or similar.

Since this is not a part of the processing layer, or is communicating with the data layer, and does not contain any business logic this is merely a proxy, not a back end.

It is possible to integrate these proxies directly into the data layer, but just because something is possible, doesn't necessarily make it the best idea; it would raise a lot of issues regarding security, monitoring and access management to your data.

So my claim is: Are you developing front end code and creating a proxy in Ktor, Node.js, Django or any framework like that, you're still a front end developer. And it's nothing wrong with that - we need developers specialized in the different parts of the front end as well.

Impossible to learn more than one stack?

Of course, it's not impossible to learn more than one stack. Personally, I know several developers that have been developing both in front end and back end. And there is no problem for a developer to learn several different languages, frameworks and environments.

However, I also do mean that someone will probably not be an expert in both parts of the development lifecycle, just as I would not have the capacity to be a great front end developer in addition to my current knowledge and skillset. It is just a completely different way of thinking, working and developing code and architecture. As a specialist in your stack, you would also do a much better job than someone being a generalist. My claim is that the saying "Jack of all trades, master of none" also applies to development stacks.

Note that I am not saying that one stack is "better", harder, more difficult, more prestigious or anything like that. They're just different, and we need to get the descriptions right. Or else, it would be impossible to know what one means when saying back end. Are you talking about your front end's proxies or the company's common APIs, internal data transfers and event-handling architecture?

If you got the choice

Finally, a question to anyone who knows both stacks: If you were given a choice, what stack to stick with for the rest of your career, that wouldn't be a difficult question, would it? If you're being totally honest? Of course, we all have a favourite, no matter which one that is. But there are some things we are more happy working with than others.

When all that is said: I hope you find the stack, the framework and the language you really love and look forward to keep learning more about, because development is fun!