Geek Culture
Published in

Geek Culture

Full Stack: The deepening division of labor labor

In this story I will overview the history of web development, why full stack development gained in popularity and why I think it fails.

Quote from Adam Smith:

The greatest improvement in the productive powers of labour, and the greatest part of skill, dexterity, and judgment with which it is any where directed, or applied, seem to have been the effects of the division of labour.

Chapter I, p. 7 — The Wealth of Nations (1776) — Book I

See also:

ORM: The deepening division of labor

The very first web application was static, basically it was HTML with some CSS and that’s it. I will move forward dynamic application, we sites with AJAX, for example. Most of them didn’t have proper 3-ties architecture, you could see for example some business logic inside JSP\ASP. While it was considered bad practice to call to DB from Presentation Layer, you can sometimes see this also.

I want to look on this problem from the bird view. Could we have one personal that can do both frontend and backend?

When the web application became complex and tools and even programming language became different for front-end and back-end, many businesses prefer to hire 2 different persons, one that is specializing on frontend and another that specializing on backend. It was the “separation of labor” principle in action.

It raises 2 new problem:

  1. We have new integration phase, that is time consuming by itself;
  2. We need manager that would manage both sides.

The naïve solution for problem is to put the burden of the managing on one of existing managers. The managers, however, didn’t want to do additional job, so “the squad” was invented, basically pushing the managing job on the developers itself. This is totally fine, but the whole philosophy was developed around “the squad” in order to hide this simple truth. And it doesn’t solve the first problem. It even became harder, now that we have one more person in the loop, we also need some planning at the beginning, not only integration at the end.

So, another solution arises — full stack developer. We want to use the right tool for a job, so we want to keep heterogonies technologies at our programming stack, for example, we want to use some JavaScript-based framework for the frontend, and Python-based framework for the backend. So, we want to hire somebody that we will able to use all these tools. Does these persons exists?

Well, obviously, they do. We see many job description for full stack developers that are filled by somebodies. But does they really can master all the tools they need to or they stay in the comfort zone?

Personally, I didn’t know any backend developer that was good full stack developer.

Don’t get me wrong. I know backend developers that wanted to make switch to frontend and full stack developing was just one station in their journey for front-end developing. I know also frontend developers that wanted to develop backend. But this are marginal cases. My point is:

Full Stack developer is frontend developer first.

And

I know too many Full Stack developers that are bad backend developers.

And this is not their fault.

Before I will expand one previous topics let’s look on benefits of full stack developing again.

If your web application is mainly about UI, the business logic is not very complex and you have only 1 kind of clients (Web-based, for example, more on this below), you will definitely benefit by working with full stack developer. The overhead will be reduced and you will almost not be hit with drawbacks.

One of the drawbacks that you will end, that you will store at DB the UI-state. Almost inventively your DB Schema will be simple reflection of the state in UI. This has it’s own pros and cons. The main pros: it is easier to reason about web application, your web application state is just UI-state, you’re storing-what-you-see-on-the-web-page. The main cons: you’re storing-what-you-see-on-the-web-page, so if you want to allow direct REST API call to your application you will find yourself that you should pass many non-relevant parts of data. They make sense in the context of Web Application, but are useless in REST API (your REST API is a “server”).

Also, if you design your web site to support both mobile devices and traditional web pages, it is better to have some UI-independent state representation in the backend.

Also, storing-what-you-see-on-the-web-page may slow down your maintenance. This point is actually depends on the skillset of your team. If everybody feels in comfort with using UI-state at the backend, this may actually speedup the developer, but if you have some developers that feels like it is wrong to use UI-state at the backend, when they get the ticket to make some changes, they can hard time to understand what is required to do.

I want to repeat again: the main profit is lowering the friction in developing new features. As I said above, it may have some problem with maintaining (depending on skillset of your team). And you skips integration phase altogether.

If the complexity of your web application is middle or high, it is better to have separate state for frontend and backend.

I like to picture it in following way:

As UI design is language for front-end, DB schema is language for back-end.

In typical web application SQL-based DB should be enough. So, as care is usually taken for UI design, the same amount of care should be invested in proper DB Schema definition — what table are, normalizing them, denormilizing if needed, indexes, foregin keys, etc.

NoSQL is also perfectly fine to be used. Even it is MongoDB or another Document-based DB, you shouldn’t unthoughtfully just storing your UI-state as JSON. You should have independent backend state representation and store it. Of course, in this case it is tempting to have 1–1 correspondence between UI-state and backend-state, unless you have another client type, you will usually ends with this.

So, we have along era that we have different technologies for the backend and for the frontend.

Than, something quite interesting happen. Many attempts was made to use the same technology both in frontend and backend.

If attempts to use same technology both in frontend and backend were successful, full stack developer were the right way to go. But they failed.

If we go back to Adam Smith, we could say that this is process of reverse of the division of labour. We want to use the same tool for something that it wasn’t designed for. No wonder, that this has failed.

Anyway, I want to list just two of those attempts. Vaadin for example, was Java-based framework for frontend. Node.js is kind of opposite example, this is JavaScript framework for backend.

Kotlin is example of deepening, new knowledge, this is example of another approach. I will describe it in general terms first and than I will go back to Koltin example.

How we can solve our problem?

What if we have some high-level language, just like Java or JavaScript, that can be used both in frontend and backend and it will transpiled to back-end “native” and front-end “native” code.

First, what is transpile. It is shortening of transcompile. And the last is “to compile (source code) by translating from one source programming language to either another language or an older version of the same language, producing translated source code in the other language or version.”

So, we can have on one hand the same “abstraction”, the same high-level language, that will be “translated” to backend specific lower level language and frontend specific lower level language.

Kotlin does it as follows, simplified. You’re using Kotlin Language in the module for backend and Kotlin Language in the module for frontend. Let’s assume that your frontend is in Android or Web.

So, for Web you can use Kotlin Native for frontend, you will get native binaries that can be run directly on Android.

For JavaScript you can use Kotlin/JS that will be transpired to JavaScript.

For the backend you’re using ordinary JVM-based Kotlin.

Note: by 16 February 2022 Multiplatform projects are in Alpha. See https://kotlinlang.org/docs/multiplatform.html

Summary

I don’t know any really successful production-ready effort that use some high-level language and than transpiles it back-end “native” and front-end “native” code. Kotin looks promising, but he is still in Alpha. So, meanwhile, personally. I prefer to use some tools for backend and another tool for frontend.

Personally, I prefer to focus on backend and I prefer to have some another person in the team that will do frontend. This works great for me.

--

--

A new tech publication by Start it up (https://medium.com/swlh).

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