Video details

Fabien Bernard - How to make sure types are not lying to you? - TypeScript Berlin Meetup #9

TypeScript
09.11.2022
English

Let’s secure our usage of external APIs! TypeScript can give us a false feeling of safety. Let’s increase our vigilance about this and see how we can make it really safe!
Fabien is a Fullstack TypeScript Engineer specializing in React. He enjoys creating a nice UX and resolving complex problems in a simple manner. To achieve this, he also spends a lot of time building tooling; indeed, he is convinced that a nice DX and good tools will result in a better end-product (fewer bugs, easier to maintain, etc.). Besides his passion for development, he likes challenging himself by climbing, woodworking, and making stuff in general. He loves learning, and he is not afraid of making mistakes!
Connect with Fabien: https://twitter.com/fabien0102
This talk has been recorded during the TypeScript Berlin Meetup #9. Join our Meetup group here: https://www.meetup.com/typescript-berlin/

Transcript

So today we talk about how to make sure that my types are not lying to me because I think it's why we love typescripts a bit too much. So let's see if it's always our friend. So welcome for those that don't know me, I'm Sallyan, you can follow me on Twitter and I'm currently working etcetera. We are doing also database as a service because databases are hard as pretty much just demonstrate just before before talking a bit about TypeScript let's do a little break and let's talk about my second OB sport climbing. In sport climbing it's actually interesting you just climb mountain in the middle of nowhere you need to uncover yourself to this kind of weird thing. So basically you have two balls, a chain on a ring usually assume that it's very strong you have a chain you can cross multiple things, you can cross just simple bolt and you kind of need to do your own stuff to make sure that it's redundant. So if one bolt just give up, you don't die. Very important sometimes you have a bit of just metal and you basically always compose around but why I'm talking about this because for me it's kind of JavaScript plus I script you have this chain very solid that you trust will never fail. Europe will just cut before the chain after you have the bolt and to maintain you don't know if it was maintained recently the rock quality usually you like to check it just to make sure if for example you see something like this you don't use it just obviously let's try to have the same awareness when you are using a TypeScript library. My goal today is that every time you are using something that you think it's type safe to ask you the question what is behind the types? Can I trust it? Should I trust it? And if the types are not connected, are not correct, what is impact? So if my entire production is done, do I use the user? Do my customer lose money or not? But just be aware but let's stop talking about landing, let's plug in. It's time for life coding because that's why it's not fun. Now let's try to see if I can kill this thing. Of course not. I'm not sure about the screen recording on multiple screens. So what are we building today? Let's build a little application together just for fun. So classic application I will have basically a backend. This backend will have a database. This is actually for me totally a black box. The only thing I have from this back end it's actually an open API spec. I could use GraphQL or whatever but I should open up on what we are trying to build. It's the front end part. That's not a black box because it's my application and here I'm trying to build the front end. This is the plan. What are we building? We are building a little climbing application to stay on the theme. Right now I just have one database set up with some just connections. I have some roots, just have a sector. I have a list of climbers and I have some assets. The idea is just a quick application where I can leave the route and say oh, I sent this thing. I can add my friend and we can have a leaderboard. Whatever. It's not just an excuse. So let's start vs code. So first of all, up here I have a little application. Is it big enough for everybody? Yes. Perfect. So I have a little application. So far I just have one open API spec. This is a big thing. I have one server ready running. I don't read Gmail. I'm a test developer. So let's keep this up. Let's open this. And the first thing I want to do is to create some type definition from this open API little tool. I have a file. I have this, it's on the server and it's called OpenAPI. I will call it API because I'm not creative and I want a real create component. And I will put this in API just like this. As a front end type script developer, I already feel more confident because I don't need to read the ML anymore. I have type definition. So this is quite cool. Building my confidence. Let's implement this application. So I need the sector first. Everything it's in it just to make this compiling. Perfect. This technosign. And just like this, I have my tabs. This is quite cool. What I need to do because I will request the route from one sector. So I cannot need to inject the first sector. And the second one so easy. I'm in react use effect that will react at sectors. On here, if sectors is defined, it just sets sector, sector. The first one I was not expecting this name up. So here normally I should have a sector. Now I need the roots. Perfect. I just autocomplete everything. This is the beauty of transcript. We are building our confidence up. I want the sector. It's there. I just want to disable the query when I don't have anything. Just to avoid userless sector. Okay, cool. I have some red. It says this. That makes sense if I don't have any roots. That basically means that I'm loading it. Normally we think it's green. I can click here as magic. I have an application on here. I feel confident you send this on production. Open the champagne thing. But if I go here on everything screen, if I scroll down, if I can yeah, I can see what is this? I don't have the number of bolts, but how my test script is compiling. I'm good. But my back end is not a good one. It just manually types open API species and somebody did a mistake. This happens sadly. But on here I did my QA job quite nicely, I catch it quite easily. I can check the request and say okay, it's undefined. I can even just see on the database because this is not smart. What do I want to do about this? I want to be able to just make sure that the open API is the source of truth. And if something is wrong, I want to catch it as soon as possible. Because here it's one component that's using it. But you just fetch something, put it in a way, pass it to the next and at some point it blow up. And after you have this in production, you have a bug and you spend one week just following the trial. Our third party didn't okay, I get you. So let's fix this. How can we do this? So let's close the server and we can actually use type guards. This is actually what does everybody know that you don't? Perfect, that's fine. The idea behind that is to define some schema here. This is just a unit test running test. And the idea is I have something, any string what I want. When I consume this from the wild, I want to be able to type it. So what can I do? I can define a schema with that. And this is an object on my object has two properties. I have bar on this, it's a string basically. But at the runtime now that I have a schema, I can actually do up cost. This has magic, this noise type. If this for example no, it's string, you will see my test will fail. Normally I should have a very specific error that just say oh foo I expect a number and I receive a string. This is very powerful because at runtime I have two things I validate a website, that's what I expect, it's really what I expect. And I also have type safety. I transform this ugly to something types that I can use in my application. Of course I'm developer, so I'm lazy. So here I have the schema and everything. I could do this by N, but we don't have time to do this and I want to create basic is the same schema, bit of magic, validating the types and this is the one to one mapping with what I have, if I'm smart enough, I can inject this part of my just two generations shortly. So what can I do with this? Easy, keep it dirty. It's a live coding, we don't have time to make nice code. So I have roots. If it imports, it's already import and it's an array of my root schema. And I'm doing this, I run my server again and if I'm going back here, I have a very explicit error that says that should be a number and it's undefined. Now I have two way to fix this. I can report this to my back end, do something about it. At least I know it's up to you and of course it's quite obvious, but in real life everything can happen. Just a breaking chance that was not communicated to your team. Everything blew up. You have a third API. I had this with GraphQL API. Oh, GraphQL, nice. I generate my type up python back in, nothing was just compliant to the types. And I use this technique with GraphQL API, the type generating from the GraphQL API. So GraphQL test script, generate the schema and use the schema to do this. And you are really confident that just if something blew up, it's not your fault. You can just say, I was expecting a number. You didn't do your job, so I can report easily a new issue and you can just go forward and I think I totally forgot to start the chronomet, so I don't know if I'm on time, but anyway.