These days everyone is a "full stack" developer, but what is a full stack?

"Stack" refers to how we think of the various software layers.  The term is fuzzy and if you disagree with my definition, please let me know.  Since I, personally, learned web technologies from front to back, I'll start there.

Frontend

I first learned HTML.  I made static websites in the late 90s with HTML and <TABLE>s and <FONT> tags.  It wasn't my first exposure to programming, but it was my first exposure to the web.

As HTML developed, we got CSS to do styling and JavaScript to make websites feel more dynamic.  This trio (along with images) is what gets sent to a web browser when someone makes a web request.

This trio represents the frontend. Some people specialize in various components like the HTML and CSS.  Others work specifically on the JS.  Some interact with the backend (to a point).

Some build in Vanilla JS (that's JS without a lot of heavy libraries) and others use React or Vue.  This can also be very low-level work done in Rust or C++ that utilizes WASM.

Backend

The backend is what servers your HTML and sometimes your CSS and JS.  Often this is NodeJS, Python, Ruby or PHP, but any language that can output documents and listen as a "server" can be used.

The backend is responsible for taking a request, routing that request to a handler and returning a response.  This might involve talking to external or internal APIs, databases, caches, offline tasks, micro services or components of your cloud infrastructure.  The backend can end up representing so many other things.

Those who work in both backend and frontend are often stylized as Full Stack Engineers.  

Backend vs. Frontend

Backend engineering is sometimes perceived as being "real" software engineering.  If you feel that way, but haven't worked deeply as a frontend engineer then you need to do your homework.  

Here's some observations from 18 years of professional experience:

• Backend code is written in environments that can be easily defined.  For example, my backend might be written in Python 3.8 running on an Alpine linux container.  Every instance of that code will always run that way, and if it changes, the change will more often then not, be intentional.  E.g. I decide to upgrade Python, or the Linux distribution it's running on.
• Meanwhile, there are multiple browsers that are inr regular usage: Safari, Safari iOS, Chrome, Edge and Firefox.  Each has various quirks.  Each is upgraded regularly and it's usually not the choice of the team developing the code.
• Testing in the backend is usually done in a stable environment with minimal moving parts.
• Testing on the frontend almost always involves a browser which complicates things and requires network connections.  This is a recipe for difficulty.  There's ways around this, but it moves away from reality.
• Frontend performance optimization is quite complicated.  Code-splitting, network requests, sprite-ing, payload size, memory, etc.  
• Frontend can often change more, designs change quite a lot, and often can be done in a way that doesn't alter the backend.

You can make your job as a frontend or backend software engineer as complicated as you like.  

APIs

APIs can be user-facing or internal.  User-facing APIs can be developer APIs or they can be APIs that maybe your ReactJS or AJAX app utilize to make your page more dynamic.  Sometimes these are wrapped into the "backend" service, or they stand alone as their own service.

Offline Tasks and Queues

There are tasks that often happen "offline."  By "offline" we mean they happen not in the request-response cycle that we detailed in the overview of the backend.  They happen later.

For example, you might upload a photo to a social media website.  An offline task might be created to process that photo, strip it of sensitive data, resize it and then store it somewhere in the "cloud."  This is all work that needs to be done, but not necessarily when a user is interacting with a website.  

Queue everything and delight everyone - 0xDECAFBAD

0xDECAFBAD

Services and MicroServices

As teams or code-bases grow, things happen with code-bases:

• They get big
• The tests get slow
• Merge conflicts happen
• Some portions change faster than other portions

Offline tasks, and internal APIs can turn into Services (or microservices).  In a cloud environment like AWS, these can be Lambda functions, single handlers that do one thing and return a response.  

Microservices can help minimize a code base (or help organize a monorepo).  They can speed up testing by only running tests related to a single service.  They can organize teams to only work on certain systems.  They can enable faster iterative development.

Database

Most parts of the backend need to write their data somewhere.  Usually this is a database, sometimes it's in other places like object stores (Amazon S3), it can even be to files on a server.

Databases are services in and of themselves, but they have been made generic enough that you can find the same database being used at many different companies.  MySQL, Postgres are old standbys.  More modern options like MongoDB, Amazon DynamoDB, HBase and Redis exist.

It's okay to mix and match too.  Some data fits better in different places.  While relational databases are a nice way to model the world, sometimes a "recently viewed" list is easier to implement in a key-value system like Redis.

Hosting Provider ¯\_(ツ)_/¯

As web software is concerned, the hosting provider might be the end of the stack.  You might even ignore it.  These days, many companies use cloud providers like Amazon, Azure or Google Cloud.  There are also companies who've built easier to use providers on top of these providers like Vercel, Netlify and Heroku.

For most full stack engineers, they may know a few things about their provider, they may have even setup their organization.  You don't need to quite be a "DevOps"/Cloud Operations/Infrastructure engineer to get started.  Especially with the newer Platform-as-a-service providers.

So what is Full Stack?

As I said above, Full Stack is someone who can take a design and re-create it as browser-viewable code and also work on the code that generates said code.  Meaning, for example, if you can create a Rails or a NodeJS app which renders ReactJS you can consider yourself full stack.

Where do you find yourself in the stack?  Where do you want to be?  Hit me up, stacksonstacks@davedash.33mail.com.