Full Stack Development Series: An Introduction

For my first attempt at blogging, I decided I'd write a series of tutorials that line up with my interests both in and outside of work. This series will cover many topics including:

• REST API best practices
• Swagger documentation
• UI Design
• HTTP communication between applications
• Database types and connections
• Monorepo structure
• Deployment options

Before I dive into any code, I'd like to provide an overview of this "stack" and the reasons I chose specific frameworks. TL;DR: these are the tools I've used and am used to. Exploring other frameworks will be it's own series of posts!

• An Introduction (this post)
• Part 1: Getting Started With Nx, Angular, and NestJS
• Part 2: Creating a REST API
• Part 3: Connecting Angular to a REST API

The Back End

I come from a Flask background and used it for many years as both the back and front end. Between work projects and casually browsing open source repositories I stumbled across NestJS and I fell in love. There is some bias here - I've been an Angular developer for over six years, and NestJS was written to follow very similar design patterns:

The architecture is heavily inspired by Angular. - NestJS Philosophy

Controllers (components), services, Dependency Injection, interceptors.. a match made in heaven. It also doesn't hurt that my monorepo framework of choice, Nx, has native support and generators for NestJS objects.

There's also the REST vs GraphQL API debate - and we'll be using NestJS to provide a REST API. Admittedly, this is because I've only worked with a GraphQL API once and have never implemented one. Hopefully, there will be a future post showing how to implement one!

The Database

After spending many years learning SQLAlchemy for Python, I had to switch to a library that was compatible with NestJS. Their documentation lists many libraries and ORMs, but I chose to use TypeORM. Much like SQLAlchemy, it provides support for a variety of different database types which means more flexibility for developers.  This helps the application fall in line with The Twelve Factor App's Backing Services guidelines.

When I first toyed around with this application, I used a local MariaDB database for development. This worked extremely well, however when I went to deploy my app to Heroku I realized they only had Postgres available (at the free tier). Thanks to TypeORM there were very few changes needed to the codebase, mostly just focused on datetime columns thanks to an annoying bug.

The Front End

When I started developing interactive websites (with Flask!) I picked up jQuery and wrote a lot of very bad Javascript. But hey, it worked! Due to circumstances at a previous job, I had to pick up AngularJS (not Angular2), and thus my "front-end developer" skill set started to build. Fast forward a few years, I received a chance to rewrite the UI for a major, internal application for my company. I've played with React and Vue here and there, but I have been so drawn to Angular's opinionated systems and Typescript's strict type checking that it's still my go-to for interactive web applications.

As part of this series, I'll address component design with Storybook, end-to-end testing with Playwright, custom interceptors for JWT authentication, and Angular's "new" standalone system.

The Infrastructure

In my experience, a Full Stack Engineer doesn't have a lot to do with the infrastructure (hosting, firewalls, storage, etc) of a project. That being said, if an engineer knows enough to deploy an API, and a web application, and interact with a database, they're bound to get involved at some point. For example, I've had chances to weigh in on the architecture of Kubernetes clusters and helped create automation for CI/CD.

For this series though, I wanted to make sure to cover Docker and how it fits into the Full Stack Application ecosystem. I'll handle Docker files, security best practices, docker-compose, and image registries.

It may be the end of this post, but the series is going to start out describing how a monorepo can be used to organize the code for all of the layers above. Nx provides many tools as well as provides linting rules to ensure boundaries are maintained when necessary between applications. My favorite aspect of it is the use of shared libraries for data structures; simultaneous development of multiple apps that share interfaces is easier with all the code in one place.

Wrap Up

While not every tool has been listed in this article, I hope it provides a good thousand-foot view of where the series is headed. I plan on providing a public GitHub repo that stays in sync with this series, and potentially a public demo of the app once it has some content. Thanks for reading; I'm looking forward to navigating this series with you!