In recent years GraphQL has really taken off as a pattern/library/type system. It offers much which REST does not and its standardisation and flexibily has really helped in its adoption. When I began looking for a detailed explanation of how graphql works internally I struggled to find anything which was not too high-level. I wanted to see how the schema, query, types and resolvers all worked together mechanically.

Its not possible to focus on all parts in detail in this article so I have focused on the execution part of the query lifecycle.

This is part of my “under-the-hood of”…

I spent many years struggling to improve as an engineer. Learning how to use modern tools and frameworks is not the same as actual improvement and in the long run I had not found that it had any kind of meaningful impact on the kind of input I would have in my team and company.

This article is aimed at the software engineer who is wondering how to get to the next level in their learning. Perhaps trying to have a larger input and a more direct impact on all manner of interactions. …

VSCode has become a staple for many developers local environment. One of the reasons is the powerful extensions which can be run from within the IDE itself, from type checking to code auto formatting. Here we will take a look at an overview of VSCode and then dig into how the auto formatting works. The final task will be to build a small version of Prettier (or eslint — fix) which can run as a VSCode extension. The goal is to understand the mechanics at work inside this kind of extension and some key differences with other types of extensions.

…

Test runners are a very important part to the modern JavaScript application. Without which we could not be able to run any tests at all. They are fairly straight forward to understand in terms of what they do, they run your tests and print output. However something which is not as straight forward is how they work and the mechanisms they utilise to enable the command-line interface that we are all so familiar with.

A video for this post can be found here. This is part of my “under-the-hood of” series:

• Web bundlers (e.g. Webpack)
• Type systems (e.g. TypeScript)
• VSCode…

I struggled to find an explanation from a low-level view of exactly how a “JavaScript type system compiler” is implemented. I understood many of the jobs of a type system but was unsure of the mechanisms involved and how they worked together.

This article will aim to shine a light on some of the fundamentals at work under-the-hood. It is not possible to focus on everything in 1 article so here we will be looking at “type checks” specifically. Starting with an overview of type systems then building our own compiler which can run type checks and output sensible messages…

This article covers a basic overview and an in-depth explanation of the mechanics of JS code generators and source maps. Building our own from scratch, hence why it is quite long.

Source Maps are something of a mystery to most people. They are found in most web-based compilation scenarios; from type system to web bundlers. But often the details of how they are actually built is not 100% transparent as their usage alone can be complex enough. Today we will start with a brief overview of what they are and how to use them. …

React is filled with interesting design patterns, when Hooks were introduced it cleaned up many of the issues people had with the more arguably frustrating features such as classes and lifecycle methods. Today we will have a look at building our own React engine with Hooks, so we can understand the mechanisms at work for useState and useEffect.

We will not be covering Fibre, reconciliation or the change detection mechanisms.

This is part of my “under-the-hood of” series:

• Web bundlers (e.g. Webpack)
• Type systems (e.g. TypeScript)
• Test runners (e.g. Mocha)
• VSCode auto formatters (e.g. Prettier)
• Source maps
• Apollo

A full…

At Nested there are a series of best practices which are followed for a given project’s delivery. Today we will look at those practices, and how to use some “delivery metrics” to understand if they are being followed.

The values had been built up over time through many project successes and failures. Many of which are something you would expect from any product/design and engineering department.

I’ll first share the top 5 practices we have, including a basic reason why we follow them, then get into the “delivery metrics”.

This follows on from 2 articles I hard written previously on…