Introduction

[00:00:00]
>> Welcome to full stack TypeScript. I'm Mike North. And I'm a senior staff engineer at LinkedIn where I work on developer infrastructure. I've been a Frontend Masters teacher since 2015. Today, I'm here to talk to you about full stack TypeScript. You may enjoy using TypeScript for your browser based, or your server side code which is no surprise because it offers a great authoring experience.

[00:00:22]
And you catch entire categories of bugs at build time before they ever affect a single user. One of the downsides to working this way, it's not really a downside, but something we don't have yet in a setup like this is the ability to get the benefits of type checking across an API call.

[00:00:43]
This is to say, anytime you fetch data, and you get a response back, you find yourself having to assert that, yeah, I expect this payload to be of a particular type. And there's nothing that makes sure that all of that stays in alignment except your own vigilance as a human being.

[00:00:59]
And the project we're going into work on today, we're going to try to create a system that looks more like this, where you can kind of see how the green color represents one set of types that are shared across the client and server. And then another set of types that represent how data is actually persisted in our database that's sort of this purple color here.

[00:01:20]
What this means is you get all the benefits you already love about TypeScript, like the ability to confidently refactor, make sure you haven't left any dangling things. You get that across these network calls, right? And to do that, we're gonna use GraphQL. So the scenario we're going to explore today involves using TypeScript for all of our client and server side code, GraphQL for API query language and our wire format meaning the way we construct our JSON as it travels over the network.

[00:01:56]
And we're gonna focus on using a very simple relational database it's just based off of a JSON file. It's important to understand that if you were to swap that out for something more realistic like SQL relational database or a document store like Mongo DB everything we're working on today it will still benefit you greatly.

[00:02:15]
You can even replace your back end with something that's not written in TypeScript and you'll get some of the same benefits that we're going to enjoy. The way we're going to get hands on with all of these great tools is by building a Twitter clone. At the beginning of the day, we're gonna start out with UI completely based off of hard-coded static data.

[00:02:37]
It'll look great, but it won't do much. By the end of the day, you'll be creating new tweets and you'll be able to like an unlike tweets, not to mention the fact that everything you see on the screen will be powered by real data coming from your database through GraphQL into the UI, a much more realistic scenario.

[00:02:57]
Before we get into the project, let's talk a little bit about what GraphQL is and what problems it aims to solve. So let's imagine a hypothetical scenario where we are building a new page for an existing app. Let's imagine we have this screen on the right already and we're being asked to build something like what you see on the left.

[00:03:19]
So we may have an API endpoint that already exists that produces a lot of detailed information to power this right side of the screen but we may need some different things on the left maybe a field that doesn't exist yet. For example, what if we wanted to enable or disable this little book button based on the doctor's current schedule.

[00:03:42]
So we have a couple choices in terms of how we want to proceed if we want to go and do this with a restful API. First, we could use the existing endpoint as is an add this availability field. And if we imagine that might involve talking to some calendar system which could take a little while, this means everything that's asking for information about a doctor, gets a little bit slower.

[00:04:07]
We could build an entirely new endpoint that produces data only for this availability field. And we could ask for the existing doctor information and this new thing in parallel. This is gonna result in a lot of little fragmented supplemental API resources. And it's gonna be very difficult to keep everything well organized over a long period of time.

[00:04:31]
The third option is we could build an entirely new API endpoint that gives us everything we need for this new scenario we need to handle. This is gonna result in a lot of duplicate code where you'll have doctor detail view, doctor summary view, doctor advanced view, doctor admin view.

[00:04:48]
And all of a sudden this whole idea of leveraging a single API endpoint for doctor is gone, right? That's not ideal either. Finally, we could modify the existing endpoint, so that it produces a different response depending on a query parameter that we pass in. The fourth option we have is to modify the existing API endpoint.

[00:05:11]
For example, providing a query parameter that tells the API whether to produce a summary or a details view which may involve different fields for each. This is going to become difficult to manage at scale, especially if we don't establish a strong convention across all of the resources we have to manage.

[00:05:29]
What does summary mean? What does details mean? In addition, if we have multiple different options that all can influence each other as new scenarios need to be handled. You can see how we end up having to worry about a lot of different combinations of things and how they interact with each other.

[00:05:49]
Even if we had these three different flags that we could turn on, that would influence the way a doctor is represented. We'll end up with n factorial scenarios even if we worry about pairs have options and how they interact with each other it starts to get very complicated.

[00:06:08]
So GraphQL aims to solve problems like this one in that a client asks for the data that it needs. And we can avoid problems like over fetching by producing only the data that's asked for and no more. We'll learn more about the details of GraphQL by getting hands on and tackling the concepts that are involved one by one.

[00:06:30]
For now, let's dig into the workshop project and examine the starting point code. First, you should clone the GitHub repo, which is Mike North, full stack TS. After you have your local working copy, I recommend you install Volta which ensures that you're going to use the same Node and Yarn versions that I do when I'm running the project for the class.

[00:06:54]
To install the dependencies for the project, just run yarn. Once you have it locally cloned, you can run yarn build to create your first build and then run yarn dev to start up the server. I'm gonna go ahead and do that for us right now. Yarn to install the dependencies Looks like a build is happening automatically, which is great.

[00:07:28]
This shouldn't do much oops, if I can spell build correctly. Great, and now I should be able to run yarn dev. And I should see a nice little banner, saying the servers running on local host 1234 there it is, may happen twice for the first time you started out, but that's no big deal.

[00:07:47]
So you can click this first link here, localhost 1234. You should see something that looks like this, the Twitter UI. So where will we find ourselves at the end of this course? We're gonna to start with this Twitter app that's purely hard coded on the client side. It's just pulling fixture data from arrays that are in those client side modules.

[00:08:09]
By the end of the day, we'll be able to create new tweaks and we'll be able to interact with that like button. We should be able to see the little heart light up and go away, and the count should increment. And all of the data we see on the UI should be coming ultimately from our database and traveling to the UI through GraphQL.

[00:08:30]
In terms of what we won't end up touching in this course, this is stuff that is sort of beyond the scope of what we're focusing on. We shouldn't have to touch any CSS. We shouldn't have to install any new dependencies. We shouldn't have to change the TypeScript config.

[00:08:43]
And we should not have to worry too much how our backend interacts with the database, right? We're just gonna use that db class, and that has methods on it, ready to go. It has everything you should need on it. And we'll consider that to be a separate topic, like the ORM aspect of things.