What is a full stack engineer when you boil it down to its essence? If you're someone already in the community, visualize the vast number of people who bandy this term around. Truthfully, "what is a full stack engineer" is a very difficult question to answer because it's a term that has been used for years by engineers of varying skill levels to mean different things. As new trends are introduced, it causes a particular overloading to occur as "full stack" adopts new responsibilities.
I do believe there's a chance to save this term and agree on what it means. I do believe that the meaning of the term does mature as the engineer does, so I will break this down into two overarching sections. First, I will explore what novices mean when they use the term. In the second half, I will explore how the term has evolved to incorporate deployment. These explanations build off each other, as you will soon see.
The Multitier or N-Tier Application—Setting the Stage
In my experience, when I hear novices use the term "full stack engineer" what I immediately think is "Oh, they must know an N-tier application setup." For those unfamiliar, multitier (aka n-tier) is simply an architecture that divides up a Web application into layers or tiers. The most common division is the presentation tier, the middle or logic tier, and the data tier. Sometimes, there are more divisions between these layers, but in general, other setups are variations of this simple theme. Let's briefly dig into what each tier denotes.
The data layer, or persistence tier, is where you write an application's runtime data onto the system's hard drive. The most common technologies used are relational databases, document storage (noSQL), and finally even a simple file to store data. Common relational database management systems include Oracle, MSSQL, MySQL, and PostgreSQL. Common noSQL technologies are MongoDB, Redis, or Cassandra. Common file formats are simple text files with no formatting to CSV files. The ultimate point of this layer is to extract data from volatile runtime of your Web system's various processes and store in such a way so that the next time you start or restart your processes, it is still accessible. Some divisions end the data layer at the system used to manage the data; others also include the mechanism for access.
Middle or Logic layer
The middle tier is the layer that sits between the presentation and the data layer. Its responsibility is to safely retrieve and place data requested or given from the consuming client and pass along to the data layer. Naturally, this often involves more complicated tasks like authorization, authentication, API endpoint design, or creating logic to enforce business logic, and so forth. There are very many flavors of technology choices, so finding the language that's right for you should be simple. Personally, I enjoy Scala and NodeJS, but you may find that Java, Python, Ruby, PHP, or countless others may take your fancy.
Common N-Tier Stacks
There are numerous Web frameworks to quickly build applications. For example, a very popular Node framework is MEAN. Breaking it down, MEAN stands for MongoDB, Express, AngularJS, and Node. MongoDB is your persistence mechanism, Node and Express serve as the middle tier, and AngularJS is a single page application that serves as the presentation layer.
For the Python stack, there a number of frameworks. Django is a highly opinionated application that gives you the complete toolbox right from the start. However, if you prefer to build your own framework, you may decide that using Flask will suit your needs more.
The Ruby stack is Ruby on Rails, which is a great framework that is used by start ups or to quickly prototype applications.
Finally, for PHP you may choose a Ruby on Rails-like framework like Laravel, or go for a more traditional LAMP stack. LAMP stands for Linux Apache, MySQL, and PHP. LAMP is interesting because it touches on the operating system, Linux, which is crucial for my next section.
Deploy Your Application—Taking It Further
Now that I've described the building block of full stack development, it's time to overload the term in a way that is the most common as you become more experienced: deployment and infrastructure. There's been a relatively new trend in Web development that was introduced to fill a vacuum between site operations (manage production Web site) and development: devops. The goal of devops is to focus on deploying applications, assist in monitoring health, and in general making development environments easy to work with. I'm glossing over many details, but to fully appreciate full stack development, one must be able to pick out responsibilities from devops.
Deploying your application could mean you literally SSH into a server, and then install all dependencies (your persistence technology choice, your server-side technology choice, and so on). Or, it could mean you choose a "infrastructure as code" solutions such as Chef, Puppet, Ansible, or Salt. Going a step further, you may even want to investigate containerizing your application by using Docker or creating images by using Packer. Although you may not be personally involved in the implementation details of this, knowing this piece is crucial for a full stack engineer because they will be expected to deploy their complicated applications once they've been created.
So, as you can see, being a full stack engineer represents being able to acquire a vast knowledge of many pieces of your Web application. I've shown that experience modifies your understanding of the term. Deciding to become a full stack engineer requires looking at the puzzle from further away than specialists, but once you figure out how everything fits together, it's quite a thrill!