Fullstack Engineer, AI-ready and design literate

What is a Fullstack Engineer?

A software application is comprised of many layers the bottom of which are programming languages computers understand, the top of which are the elements that humans understand and interact with. The layers together form the stack and an engineer who can work with the all layers is known as a fullstack engineer.

Typically for web development these layers include server-side programming, database management, an API and a front-end. The server will respond to user demands, send/receive data to/from the database and present this data via an API to the front-end. All of these things will live on some infrastructure which a fullstack engineer must also provision and manage to some degree.

Below I describe which programming languages, frameworks, languages and APIs I am proficient with. If you are not a technical person the below makes for pretty dry reading, but might be useful to anybody wanting to understand my skillsets or for anybody considering a career in web development.

Before going into my skillsets on specific technologies and frameworks it's worth outlining a few general purpose tools I use. It's worth noting that these are my preferences and other great options also exist. My choice of code editor, where I write code is Visual Studio Code. VS Code has lots of plugins and customisations which I am just used to and enjoy using. My preference for version controlling is Git and I save all my projects using GitHub.

My Frontend Capabilities

All web applications in the browser rely on three things, HTML, JavaScript and CSS. HTML and CSS are not programming languages but they understanding them fundamentally is non-negotiable if you want to call yourself a web developer. HTML defines the structure of the information you present on a web page and CSS determines how this information is displayed to the user.

Framework

JavaScript is the the language used for manipulating what HTML and CSS is presented on a web page and how they respond to user behaviour. For many (very good reasons) frameworks have been "stacked" on top of JavaScript to make building robust web applications easier and faster. There are numerous frameworks such as Vue.js, Angular and Svelte. However the one I use is called React and is the most popular front-end framework. Knowing React comes with the added benefit of being able to make native iOS and Android apps using React Native. "Stacked" on top React is another framework I use called Next.js which extends React to make websites faster, easier to build and more robust at scale. This site you are reading right now is built using Next.js.

TypeScript is also "stacked" on top JavaScript to make code more robust and (eventually) easier to write and maintain. TypeScript is JavaScript with the ability to add guardrails and helpers. Whilst strictly not exclusively a front-end programming language it helps a lot and I use it in my projects.

CSS

As mentioned a fundamental knowledge of CSS is a must, however there are a number of approaches you can use to apply your CSS. I started my journey by using a framework known as Tailwind which can be a sort of "shortcut" to building good looking interfaces, but as my confident with CSS has grown I've moved to using CSS Modules and Styled Components and writing more "vanilla" CSS.

Animations

For animations and making websites "feel" delightful for users I have learnt both GSAP and Motion. I prefer Motion for its simplicity and how lightweight it is. If you're using desktop to browse this site, you will notice the logos on this page grow slightly on hover, this is done using Motion.

Data Fetching

Most websites need to fetch data to provide users with useful information. For this purpose I was taught how to use Axios, but I'm also comfortable using JavaScript's native Fetch API.

Backend and API

A frontend needs to be provided data to make it useful, the backend and the associated APIs (the plumbing) is responsible for this. For most complex web applications the front end is just the 10% of the iceberg that you see and the backend and infrastructure is the remaining 90% underwater.

The backend is where the data lives, where all business logic takes place, where authentication and authorisation happen and essentially where anything that needs computation exists. More often than not the "backend" is a variety of services (imagine your heating, water and broadband utilities to the home) and there exists a complex web of connections between to provided these services (known as APIs).

Programming the backend

Unlike frontends, which require JavaScript, backend functionality can be written in many different programming languages, e.g. Python, Java, PHP and many more. I don't really know any of these other languages, but I do know JavaScript (from frontend land) which is handy because this can also be used to build backends with only a slight adaptation. The technicalities of this adaptation to JavaScript aren't that interesting except to say they allow JavaScript to run anywhere and not just inside web browsers. This "anywhere" JavaScript is known and Node.js and is even more popular than React as a technology used in web development.

Within the backend node environment I use Express.js which is a really well-established and flexible library for building-out the plumbing for the APIs I mentioned above. When building APIs you need great tools to test and debug them, the tool I use for testing is known as Postman.

Where the data lives: Databases

Most of us have heard of databases. Databases exist as a store of information for the backend to fetch, present to the frontend and then store after changes are made. Without going into too much technical detail there are two main types of database I work with: SQL and NoSQL. SQL db's you can think of like a fixed spreadsheet with different tables for types of information and links between those tables. A NoSQL db you can think of like a collection of filing cabinets, each cabinet can be flexible and contains different documents in there to the other cabinets.

To understand the difference between the two databases imagine we have two applications:

1. the first which helps you buy a car
2. the other which is a social media application.

The information for cars has a fairly fixed data structure. Each car will have a manufacturer, model name, colour, price etc. Therefore you can build fixed tables and be confident that each car that you add to your database will conform to this structure. You actually want a rigid data structure because you want to ensure that every car in the database definitely has information on price, colour, make etc, without this information you app will break. An example of this sort of database is something like PostgresSQL.

On the other hand sometimes you want flexibility over rigidity. For example users on a social media platform will want to customise their profiles differently, post different content at different times and have different friend connections. A flexible data structure is a must here, unlike cars each person's profile is very different, the whole point of the application is to allow unique expression. MongoDB is an example of a noSQL database.

Interacting with Databases

There are entire engineering jobs that are just dedicated to all things database from designing the data structures, querying the data, backing up data, ensuring speed, reliability etc. I am not even close to being a database engineer and only have a working knowledge of database management. Thankfully there are a few more modern tools which make working with databases easier for non-experts.

The first is Databases as a Service: instead of provisioning database servers and architectures myself I can goto a cloud service like AWS or Mongo Atlas, spin up a database and connect to it. All the management behind these DBs is taken care of more me.

The second is something called Object-Relational Mappers (ORMs). Essentially these tools allow you to interact with many different types of database without having to learn a new specific database language. In times gone by engineers would have had to learn Structured Querying Language (SQL) to interact with SQL databases. An ORM like Prisma means that I can interact with a database using TypeScript (JavaScript) and not really ever had to write any SQL. This is great since I already know JavaScript for my frontend and backend.

Content Management Systems

Using all the tools discussed above it's possible to build from scratch a web application that can do almost anything. However lots of tools already exist which help you build things faster without reinventing the wheel. One catagory of tool is known as the Content Management System. They are essentially very flexible "kits" for building applications which include a robust backend, API and administration panel. For example this blog is built using Payload. Payload provides a great authoring experience for writing articles, asset management and an API for presenting information to the front end. Other CMS's that I've used are Sanity and Wordpress.

Infrastructure

All of the frontend and backend code needs to live and run somewhere, the cheapest and easiest place for this to happen is in "the cloud". The term cloud computing is fairly misleading and what it means in reality is a warehouse datacenter somewhere. This datacenter is probably owned by either Amazon, Google or Microsoft and they very kindly allow us to rent a little slice of their computing, networking and storage resource to operate our web applications. I've used various Amazon Web Services products when building web applications.

As time has gone by 3rd-party services has been created which stack on top of raw products from AWS and others. This makes configuring, scaling and networking servers easier than ever. For example Vercel (the company that makes Next.js discussed above) offers lots of easy to use options for running your frontend and backend. Other services like this that I've used are Heroku, Netlify and Supabase. I've also used Docker which uses containerisation to package up your code into a self-contained box that you can drop into any infrastructure and run easily.

Artificial Intelligence Capabilities

The companies that have developed the latest large language models have made accessing their models programmatically using APIs (not via the web chat interfaces) fairly straightforward. With a strong knowledge of building backends you can bolt-in functionality from LLMs with a little bit of additional worked. I've worked with APIs from OpenAI and Anthropic in projects.

For more complicationed use-cases like Retrieval Augmented Generation, where you actually use LLMs to interrogate documents that you yourself provide things get a little bit more complicated. For RAG applications you need to build a pipeline to help "embed" the semantic meaning of the information you provide into a special kind of database known as a vector database. You then need to query your own database and combine this with the pre-existing "intelligence" within the AI model. I've worked with some of the tools involve in building these AI pipelines such as LangChain, LlamaIndex and Pinecone, a vector db.