DIV and Backend again. A TypeScript Tale: Part 1

Setting up NX

With the web development world coming to grips with the benefits of type safety, it can be difficult to maintain type parity between your front end clients and back end services. It is possible to maintain types using an ORM and have them flow out all the way to the front end, without maintaining types for your front end at all. In this 5 part series, we’ll go the way to mount Div! Along the way, we will explore all the tooling you will need in order to pull off a completely type safe To Do List:

Our Final Todo List

---

1. YOU ARE HERE
   nx.dev - A mono-repo organizational tool. We need nx to help us share code between the back end and the front end. In addition to code sharing, nx provides excellent tooling to get you setup with: typescript, cypress, eslint, storybook, react/angular, jest, gatsby/nextjs, etc… Nx will be the glue for all our tooling.

2. Type-GraphQL - A graphql schema generator/framework which uses your types (from typeorm) to produce your graphql schema.

3. TypeORM - An excellent, battle tested, ORM with over 20k stars. TypeORM will be where the bulk of our actual types flow from. TypeORM can generate and run migrations as well as traditional ORM capabilities.

4. GraphQL Code Generator - The type safe link between your front end and your back end. We will generate an SDK, which we can use on the front end to achieve complete type safety. We will use the apollo generator, but there are tons of options for common graphql tooling.

5. Tying it all together - Lets put all our hard work to good use with some examples.

Prerequisites

We will be using typescript, react, and graphql for our setup, and we won’t be diving to deep into how each one works. If your just getting started with typescript, react, or graphql, you may need to look some things up along the way.

You should have the following installed:

1. node: version 14 or greater. I recommend NVM if you need to switch versions between projects.

2. yarn: You could use npm if you like, but this guide will be using yarn in it’s examples.

3. Docker: We use docker to setup a development database. You can always install postgres directly on your machine if you don’t want to use Docker. Just make sure postgres is running on port 5432.

Part 1: Setup with Nx

Want to skip ahead? Check out the the Part 1 source on GitHub

Nx.dev is truly the Gandalf on your journey. Nx does all the setup, knows the way, and can read all the config for you. Just follow Nx, and your sure to have an easier time. Fly you fools!

To quote Nx:

Nx is a suite of powerful, extensible dev tools to help you architect, test, and build at any scale — integrating seamlessly with modern technologies and libraries while providing a robust CLI, caching, dependency management, and more.

We are not going to dive super deep into how nx works, and all of it’s capabilities, but you won’t need to know much follow this guide. We will be initializing Nx with NextJS and express.

If you find that you want a more in depth intro to Nx, there are excellent video courses and documentation available directly from Nx.

Getting started with Nx is probably the easiest part of this whole process. In your favorite terminal run:

npx create-nx-workspace the-wooley-devbox --preset=next

You will be asked for an application name, and what type of CSS you want to use. Name it however you like, but our examples will use “web”

A couple terminal setup steps:

1. $ cd the-wooley-devbox

2. $ yarn # install node dependencies

3. $ yarn start # start NextJS on port 4200

4. open your browser to http://localhost:4200 and witness the glorious NextJS intro page.

Lets examine the folder structure created by nx:

View On GitHub

The comments show what and where each folder is and does, but lets examine a couple that might be new to you. There is also official Nx docs for the folder structure.

1. workspace.json is a huge json file, where nx keeps track of all your various libs and apps, as well as custom commands for each.

2. nx.json is a smaller json file where nx keeps track of tags, and some extra metadata for your libs and projects.

3. libs - we don’t have any libs yet, but in Nx, libs is where most of your code lives. Nx generates various types of libs for us (react components, or validators, etc..). They will eventually be consumed by apps.

4. apps - While using Nx, think of apps as entry points into your code. In our example, we only have one app: web which is our NextJS front end. Think of applications like glue for your libs.

5. apps/web - this is our front end NextJS application. workspace.json has an entry for web, as well as commands for interacting with it. When we run `yarn start`, we are actually running `nx serve web`

Up Next

We have set our selves up with a basic front end using Nx. We aren’t benefiting much from Nx yet, but up next, we’ll setup our graphql server, where we can start to see some of the benefits of our mono-repo setup.

If you use this setup in any projects, make sure to tweet it to me: @ericwooley. I’d love to follow your progress!

If you would like to see more content like this, make sure to sign up for the news letter.

If you spot an error, or have any recommendations, please:

If you really liked this content, please consider sharing it.