Learn Fastify One Plugin at a Time

So, this is the Fastify Workshop, whatever edition it is. And I'm going to, well, we are going to go through the basics. I keep doing this. The basics of the framework and a few of its key plugins. The source code of the workshop is public at github.com slash NearForm slash the-fastify-workshop, so you can essentially check it out.

Couple of reasons why Fastify. Fastify is a web framework, that started as a thought experiment at the beginning between a few of us. And then it has quickly become a framework that you can actually run in production. It's pretty great. It's very good. It has provided also a very good developer experience, especially with TypeScript support as well, which we are not going to cover, to be honest.

Quick things. Let's skip a little bit. Some core features of Fastify. It's fast. It's well. Yeah, it is fast. And you can serve as many requests. It basically provides almost no overhead compared to NodeCore. It's also very extensible because of hooks, plugins and decorators. We'll go through all of this. And it's schema based. It also provides some logging by default. Now I don't know how many of you are using Winston. Please raise your hand. Now, you folks that have not, OK, you need to change logger. I'm sorry. I know I'm joking. It's a Fastify as built in logging. By the way, if you folks would turn on your video, we'll give me some, a little bit better feedback from how the workshop is doing compared to everybody, to everything else. So please, if you can, that would be really, really helpful for me. Thank you. At least I'm not talking to square boxes. Talking to square boxes is a little bit depressing. I'm sorry. So, going through it, it's developer friendly. And we also use a logger which is called Pino internally. It's built in. So, how are we doing? A lot of companies are doing Fastify, including some big names, small names, a lot of different. So pay, check them out, they're all great. A lot of plugins, there were more plugins from when this slides was taken. So more core plugins and more community plugins. Fastify is really fast. That's one that says in the name, but you know, it's also true. It's fast. And it's way faster than alternatives. Now, it does not really, once you reach a certain level, it does not matter anymore. The key reason is your framework should not be your main bottlenecks. That's what you want to look for. And Fastify has been built for that with that in mind.

So let's get into the workshop. First step, you need to have node LTS which means node 14. Now, essentially what I want you to do, actually you don't want to do this. I want to also add this. Here we go. Now you should also see my window. Hopefully you can see this fine.

Okay, so essentially what you could do is when you run Node, you need to return the node for 13.15 or something similar. Does it? Is there anybody with a weird version of Node.js? I started using Node.js with 0.4. So I've been around a lot of different generations of the Node.js runtime. Whatever. So if you're using Node.js 0.4, hopefully nobody. This thing will not run there. So I'm sorry. Okay, hopefully yes. I don't see much interaction here. So feel free to speak whenever you want, interrupt me, talk.

My version is 12. Is that going to cut it or should I upgrade? Yeah, if it's the latest 12, it's fine. Which version of 12 it is? 0.18 or 0.3. I'm not sure if that's the latest one. I don't know. I'll check. It's 18. We'll see. If it's a problem, you will see very quickly. So it won't run. Or it will complain at some point. So we'll see. It might work. I don't remember which one added the features that I needed. It might be that it's fine. You might Sprint this is experimental because you're going to use ESM modules here.

Okay. Worship structure, in your workshop, what you're going to see, this is our folder. If we are going into SRC, you will see that there is a lot of steps. Actually, the structure is not just like that because I have lots of stuff. If you go into SRC, you will see that you have Step 1 and something. Each one of those folders includes a bunch of things. It includes your files and a package JSON. You don't need to do anything with the package JSON. Things will be installed. Once you clone this folder, things will be cloned for you if you run YARN. All dependencies will work fine.

So, the first exercise. So, okay, in the slides, you will see certain notation. You will see that this workshop is very interactive, and each module builds on top of the previous one. If you skip a step and you cannot do one, you can even jump ahead and just use the code that is with that fixed. Okay? Very simple. So what you should be doing now is doing. So let's do the first one together. So you do CD, SLC step one, L word, and then you run yarn start. Okay, so what I'm doing is going step one, and load. Okay. And then, okay. I'm doing curl localhost 3000. It's working, okay, I've cheated. I've cheated. I'm doing step two, we will start doing step two by using this, moving this module forward. Okay? So use the basic, use step one to develop step two. Essentially. You can even close this folder and start from scratch. So in server, you will see that we have a bunch of things. So we have Fastify, and fastpm. And we create a new instance of Fastify, and then we run our route. Were you all able to run this and test this? Yes, maybe? Yep. Oh, good. Okay. Any blockers, anybody that didn't make it? I can see half of you. So hopefully, you're okay. So, this was step one, was just to get our hands started so that we can start doing things, okay? Step two. You can use the code that you have been working on on step one if you want to. So, in Everything, in Fastify, everything is a plugin. So you can, Fastify allows the user to extend its functionalities with plugins. And you can just put whatever you want, routes and decorator hooks, a lot of things. We'll talk about them in the future, but the most important bit that you're going to do is you want to split Server.JS into two files. First you want one file that Server.JS that contains only the server setup logic, and one index.js file that contains the code to instantiate, specify, and register the plugins. Now, when I mean the startup logic, I mean this line. You want in one server, in one file, in Server.JS, it's the entry point. So you want to where you call listen and when you call start. On the other one, what you want to do is you want to keep your plugins this part. After you've done that, I asking you to create a new, ooh, sorry. And create a new slash users route and put it in routes slash users.js and export it as a Fastify plugin. And load it up. Again, just adding the route. Sorry? Just adding route for a slash users. Yes, for now yes. So, two things. First of all, split the server into two files and then create a new route, get slash users. Are we going to work these on the step one folder? Yes, please. Yes, yes, yes, keep working on the step one folder. Keep working there or copy that folder, rename it something and just work there. I have a question. I'm seeing that importing from Fastify, but you are using Capital F, why? Why? Do you prefer? For Capital F because I tried it with a lower case and it works. Why there is a preference for Capital F? There's no preference. Okay. If you like it, you can call it. Yes, I know. You can call it FU and it will work. The reason is. So the reason why it's small F, it's capital F is because I call this Fastify with a small F. Okay. So if you wanted to use a small F and this is what I do a lot of time as well, I just call this.

I have seen this example and I prefer it rather than. I also do this. Yeah, but there is no any particular way. No specific reason. Also, it's less characters to write rather than fastify again. Yeah. Whatever works for you.

Okay, so there is no pattern that you prefer more. No. Okay. Thanks. And even if I prefer something, just do what works for you. Yeah, I know. But if there is, you know, as you are the creator, sometimes there are best practices. No, there is no best practices. I have no best practices on naming things. Okay. I have very, very low fantasy for all of this. So... Okay, thank you. So... How's it going? How good so far? All good. Okay.

So how would I solve these exercise? What I would be doing is, okay, so I'm going to ssc step one. I will create routes and then users.js file. Okay. So, and then I would also create index.js. In index.js, I would take this stuff, copy this here. And... Okay. Return app. Here you go. Okay. I hope you like this. Index then inside server, what I would do, and this is actually new in a few of the latest Node 14 versions, so it's not in Node 15. What I would do is I would call import build from app.js. Oh, sorry, index. It's not... App. Okay. And yeah. So this is app.js and this is server. Okay. And then. Here we go. Now that you can do this because it's a top level. That is top level await in one of the latest Node 12 version. So essentially this is Node 14 version, sorry. Now we can run this so I can do node server and it's there. So per localhost 3000. Here you go. You can see it, right? This is still working. Now for the users to have some users in there, what we are going to do is that export default async function app. This is a application. This is your route. So we can do app dot get users. Why are both of them are async function? So in Fastify, things are async functions. So it's plugins are async functions in Fastify. The reason is it can either be sync or async. If you want, in Fastify, they are all async for compatibility essentially. It expects you to return a promise at the end of it. So that's why it's the signature includes a promise when you're when it finishes. You can also do instead of async you can also do have a callback and call the callback at the end if you prefer. I don't know, the async is better. Yeah, you see, I knew that for some reason I had a good feeling that that was okay. So in your AppJS, then what we can do, we can do app.register, which is how we add a new plugin. And do import and we need a thing though. So if we want to import things, we need this tiny module called bsm. Because otherwise we don't know which folder will be loading this. So, and these is routes slash users slash.

Hopefully this would work. Why? This should be working. The join. Yes, thank you. Thank you man, yes. Yes, thank you.

Here we go, unexpected token. Why? Export. And then, I keep making mistakes here. Very interesting. A yes, OK, so here we go and then curl localhost 3000 users. It's working OK so I don't know how this is what I said it will happen. We'll look at the implementation. So this is essentially what we are going to, what we're doing. You can also use this. However, it will have problems. So we'll go through that in a second. What it's going to do is that in here, in the solution, you can see that we are using this pattern with a start. The reason is we need to do the await. However, in the latest node 14 there is top level await so you don't need to do that. We don't need to do that anymore. Happy days. This is our, essentially, our slash users implementation. We are returning just a list of usernames and it will just work. Any problems with this?

Can you go over the Fjs file? Just how you connect between the server and the Fjs? I'm not seeing the file. Oh, you're not seeing the file? Sorry, sorry, sorry. I thought these were shared. Just a second, sorry. Thanks. Ah, so I thought I was also streaming my slides. Can you see the slides now? Yeah. Okay, cool. That would be better. Here we go. So, I thought I was showing the slides and they were not shared. Sorry about this. Can you see the slide and the text right now? No. No, I don't see the slide. Just the editor. Now you can see both. Yeah. Okay, I wanted to show both. Okay, happy days. Sorry about this. I thought it was, I was sharing both. I thought I clicked and then I didn't click. So, okay. So this was the exercise, Split server.js into two files and create a get slash users in route slash user.js. How many of you were able to get through this? Yay. Yay. Okay. A few people. And Okay. I don't know the rest. So there's a lot of people in this room that have not opened your video or not talking too much to me. So thank you. If you can talk to me or say something, give me a knack if things work. That would be very, very, very, very, very, very, very, very, very nice. I just have a question because you, you're using this package, the dynamic ES module to do the dynamic import. But in the sampling the code in the step two, you actually do it without using this package, just doing the register of the plugin. Yes. Yes. Okay, let me show you. So in here, yes. There is a difference between those two things. First of all, if you prefer App.js, use App.js. Okay? The reason using this module is that oh, at the beginning, maybe because at the beginning, oh yes, so if you do this, it won't work well on Windows, essentially. There are edge cases where these do not want to do what you expect it to work. Okay, long story short, I didn't know that even that was possible, to be honest. So maybe at the beginning it wasn't.

It works on Windows for me. It works on Windows, cool. Then, yes, not needed anymore, Happy Days. Like it. It's Abbott. So at the beginning, it was definitely not working, like a few weeks ago, a few months ago, when I started working on this DSM stuff. Interesting, okay. So anyway, not needed. Cool. Can you explain line 11 in app.js with the imports? Not on that one, on the... Where, here? No, the other, oh you changed it, okay. Yeah, that's, just remove it, it's fine. Don't worry about it. Okay, the import right there. So that is a dynamic import, what is that? What are you doing here? Yeah, this is a dynamic import, okay? So essentially, instead of, you know, you could have said, import users from routes users.js. Right? However, I will be using one more line. I'm not super fond of using one more line. Does it make sense? Does it? Yeah, it makes sense. So you do it as you need it in the, right, right? In the line that you want. Okay. Okay. Can I switch to server.js, just for a second? Yep. Just to see the differences between what you have in the right one. So, in node 14, you can do this. Latest node 14, you can do this, top level await. In node 12, you have to do this. And it's just to see the difference. Does it make sense? Yep. Cool, okay, perfect. Yay, so you see the slides, right? Yep. Amazing, okay.

So, yes, okay. So we have a routes. Okay, step three, we're going to add logging. Fastify ships with default to Pino. Pino is a logger for Node.js. You probably know that I mentioned these already a few times. So Pino, here you go. It has a nice logo. That's what it has. It's a logger for Node.js, which is really fast. By the way, logging, if you're using Wiston, you are likely, logging is probably your main performance bottleneck. And the same as you'd be using bunion and other things, you can just switch logger and you will get a significant performance boost out of your app. In Pino, Pino has two principles. You can actually do some log processing in the separate process, and it has very little overhead itself. You can read up on logging for Fastify in the logging documentation, so you can go to Docs and then you can click to where it is Logging to know more about logging. So I would recommend you to check that out because the next step is going to go about adding logging. So important thing to note is that Pino provides a child logger for each route, which will include the request ID for example. So you can actually track all the log lines for the same request. You can also have a pretty print option when you start Fastify to output the logs in a more human readable form. Now you want the human readable form only in development, not on production. So what I am asking you is to enable the built-in request logging and then enable the print-to-print as well and then use Pinode to log something out. So off you go. How are you doing folks? All good. All good? Hopefully. Yeah. Amazing. Okay. So anybody that's still working? I'm good here. Oh, cool, cool, cool. Okay, so how do we turn on logging? Okay, so let me jump to step three, logging. So in here you can turn it on with doing pretty print true and in server.js, then you can actually use the logging here. Like festifile is starting up and then you can log on the route. Let's try this. That's step three, logging. So no server. And oh, now it's nice. Okay, cool. And then I can curl log Lost 3000 slash users. Makes sense.

Note, you can see that we have the request ID here, okay? And here. Does it make sense? Okay, it has the request ID. And so that you can see that you can track down how it's evolved over time. Makes sense?

Okay so, so here's the solution as I see pretty print. We can turn on and off with the option. And then we can use also the loop demo. So the logger lines, we can log lines also from our routes. Know that we can assess a child logger specific for the instance inside from the request object. So okay, here we go. Okay. So next step, which is going to get, we're getting interesting very quickly. Okay, I'm adding you more and more things to, we are raising up in complexity.

So fastify use a schema-based approach, and, the default is based on JSON schema. You can actually swap these out if you prefer something different, but in this workshop, we are going to cover JSON schema. Internally, so this is used for both validation as serialization. So we're going to start with, I think with serialization. So essentially we are saying that, if you want, we are letting you specify a schema for your responses. You specify this schema for your responses because you want them to be rendered faster or because you want to filter some of the data going out. So essentially you want only some of the data going out to be present. So, you can read more at, in our docs as well. This long explanation on things. So check out the docs.

Now, we want you to validate the response of our users route using a schema. Check out fluent JSON schema. Nobody remembers the JSON schema syntax by hand. It's impossible. I don't know who developed that because it's very, very hard to remember. I never remember things. But I always use this library, fluent JSON schema because it's fluent. So, and if you're using Visual Studio Code or it's language servers or whatever, you can actually auto-complete it pretty nicely. So it will auto-complete for you if you are typing things correctly. So, just import it and it will just go. And what we want is that the response, sorry. Step four is, what we want is that each of the response is serialized properly and contains that acquire property username in each array item. Okay? I gave you a few pointers. So, this is the URL, check out the serialization and read up users about fluentisation schema. And, I would say, off you go. I will just drop for like two minutes.

Question. Yeah. I might be a bit annoying but, the only reason we suggested to use a fluentisation schema is because of the syntax of the, um... How should, how do you say, the syntax of writing, in object notation rather than having the dot? Yes, that's the reason. Okay. So, if we get used to the other syntax, should we change to fluent schema or is that? No, it's fine. If you know, it's totally fine. Okay, yeah. Use what works for you. Okay. Is there any overhead from using? Zero, zero. These runs only at startup time and it's actually very fast even. Okay, thank you very much. It's not, it's cool that you only run at the beginning of your process. So, it might be important if you're dealing with like cold starting a lambda maybe but even there it's probably. It's very tiny versus the time that it takes to actually compile the JSON schema themselves. So. Yeah, okay. Thank you very much. So, how's it going folks? All good. I see there's a lot of people that are not like videos closed, not really interacting much. Hopefully you are following. I am. Somebody, hello? Yeah you're still there. Like, some people pop in and out is good. Okay. Just to clarify if I'm bringing everybody along that's actually joining here. Okay, yeah, yes there are people that are here. Okay. Did you get it working folks? Yeah. Hello? I have a question. Yeah.

Alex here. I have it working but. So I remember using it like long time ago fast fibre. I remember like if this validation fails it shouldn't return 200. Sorry this is for the output. Okay. This is the response. So we are talking about the response schema. So this is the. Okay, so it is for the other one. It's for the response. We are going to TED to do validations in step six. Okay, okay. I see. So like the empty response is what we are trying to have to get in case the validation fails. Sorry, it's not a validation. So I don't get your, it's not. I'm not talking about validation. Maybe the question is, let's say what we return doesn't match the schema. What happens? So it depends. So some of the properties, if it's possible to fluent JSON schema, try to provide have the best ergonomics you can. So if it can be rendered with some missing properties we'll just filter out additional properties. If you are putting some fields as required and those are not there, then it will error. Okay, I see, thank you.

So, in this case, you get an error because there is not required in here. I guess the error also means that you get an error code from Fastify automatically. Sorry. So when your schema is failing and the schema is erroring, Fastify will send a status code. Yes, that's an error message. Yeah. So, if you are, let's just go here. Okay. So, if I'm putting out something like this, Now I'm doing server.js, then curl. I can't see your terminal. Ah, yes, sorry. Yes, sorry, sorry, sorry, I'll fix it. Here we go. Sure. Okay, you can see my terminal now. Yep. Okay. So, I am in CD. I am doing step four serialization. Okay. Now, I am going route. Users, same thing as before. I am adding an empty user. Okay. So, I am starting my server. I am curling. Now, these returns are JSON object, right? However, I will recommend you to do it with V. So, if I run curl with curl-v, you will see that it gets a 500 status code and adjacent object that respecify the status code and include the error message. Now, if I want to customize that error, because I might want to, what you can do is... Okay. And is async function error. Error. And then I can do return. Okay. And then, node server. Now, you see, it just specify message, username is required. So, I just remove the properties. Does it make sense? Yeah. Can you also change the default message that you get from the Fluent JSON schema? Well, this is the app. So, okay. So, it is this. This problem is because you made a mistake in your code. Yeah, of course. So, you cannot change this message. It's a mistake in your code. Yeah, certainly. This is a developer error, okay? Yeah, that's clear. What you will be able to change is you can change the error, the messages for the object that are coming in, okay? So, this one is not you can change. Okay, so in fact that you cannot even say it's not a... So, this is a 500 error. Okay, this is something went wrong. It's a GitHub unicorn. Hope you're familiar with the GitHub unicorn. Yeah, yeah, and just thinking in cases, I mean, it makes perfect sense, just thinking in cases like, for example you want to support different languages as well from your server and maybe... This is an internal server error. So, these should not go out to an end user. Yeah. Okay, don't... Like, this is a default. It's more than, we spit this out because it provides you a slightly better developer experience. But to be honest, the default should just be something wrong has happened and nothing more. So, we are going to start writing a little bit of unit tests in your code. Okay. Fastify offers automatic HTTP injection. So, you don't need to call.listen and start on a port. You can just call.inject and on... Here you go. You can just call, what it is? Apinject in your code to build your aplicative to automatically call a route inside your system. Inject is actually really fast. So, you can use it in any place if you want to.

So, in here... Oh, I need to share the other screen. Okay. So, the next step is to... It's about testing. And if you go to the doc latest, fastify.io doc latest testing, you can see that it explains it all. And you see that the benefits of using fastify.inject. And this is how you use it. You just do app.inject, await, and you get things out. It's easier to have a.json function if you want to. Anyway, trust your code completion. It will should work out of the box.

So, I would ask you to write a unit test for the index.js module. I am a huge fan of NodeTap, but you can really use what you prefer here. You will find it in the example that we're using NodeTap. I will ask you to write a test that checks that getting the user's route, it responds with a status code of 200 and returns the expected array of users. Now you don't need to start the server, as I said you can just need to call.inject. Any questions? No, cool? Off you go.

For all of you that just joined, the URL is on Discord, so you can find our source code at github.com.com slash neoforms slash this fastify workshop. And we are currently doing step five, so you can follow the instructions and we are actually doing step five and we will be done with step five soon.

How many of you are familiar with unit tests folks? A lot of people, yay, okay. How many of you are using tap as I recommended? How many people are using jest? Jest, jest, a lot of people use jest. Yeah. I'm sorry for you. Worth to try. I'm not a jest fan. I use tap, I think jest is quite good for front-end stuff. Maybe not on the server. There is a few problems with using jest with node that makes it very hard to work with.

Okay, so we are up with time. Cool. Did you make it? Anybody didn't make it? Are you still working on it? You're still working on it. Cool, okay. I'll give you a few more minutes. I have a question actually. Whenever you change your code, you always need to restart the server. Yes, I always do that. So is there any way of not doing that? Yes. So two things. First of all, this is just a normal node server. So if you want, you can just use node man. There is nothing special. Okay. That would be my preferred way of doing it. So this is not, there's nothing special really. You can also use another tiny utilities that you have written called Fastify CLI, but I'm not covering this in this workshop because I wanted to teach certain things in a more manual way instead of, just follow the step-by-step of the template. Right, now I was just wondering, thanks. To be honest, when I would develop things on, when I develop things with Fastify, that is, there is somebody waiting, there is somebody in the waiting room. Okay. So whenever I do things with Fastify, we develop thing with Fastify, I'm typically write unit tests. Write tests, test, test, test, test, test. So I normally have to even run it ever, essentially. And when I do, yes, I use something like NodeMod or whatever. Yes, okay. So Simon has noticed one very important bit. You need a.taprc file if you're using TAP. Why? There is a few interesting point. So if you go into the, oh sorry. If you go into the step five testing, you will see that we have an index.test that's using TAP. TAP, however, is... It's just saying the code will be just like. Yeah, yeah, yeah, sorry, yes. Thank you, okay. I'm sharing the code as well. Here you go, perfect, thank you. Okay, so you will see that in here, we just use test and use TAP. Now, but if we do a step five testing and you open it up, you see that it has a ESM false. You see this? This is the funniest thing ever. I don't know how many of you know how much of a mess is ESM in Node, which is the new syntax, okay? So TAP used to support ESM via this module called ESM. However, this implemented the old Beiber-based, transpiler-based version of this. Unfortunately, this is not compatible with native ESM. That's what we are doing in our code, okay? We are just using the native module syntax, so we need to disable it to make it work. Good point, Simon. Ah, okay, sorry, somebody asked me, Priyanko, sorry, I didn't read your message. Sorry about that. So, okay. No worries, I'm gonna check it on the documentation. Yay. Cool, how many, did you get it to write the test? Can you repeat why I understand that that you have to have ESM false because of what you said, and is incompatible to your native ESM in the code? Is that correct? Yeah, exactly. Okay. So it's incompatible with Node core ESM, so TAP14, so the current release of TAP came before the native ESM syntax of Node core was taken out of experimental. So it was essentially from before. Oh. Yay. Whatever. I'm going to do this. Maybe I can just do yarn. It's actually, maybe it's actually working. Magic, okay. Does it work for all of you folks? Okay, let's go and look at the test.

So what we are doing, we are importing TAP and then getting the test. You can't just do the destructuring like at the top of import, mainly because TAP still does not support it. In a future release, it will likely do, but at this point, it doesn't, so sorry. Then we get our build server from index.js or app.js. This is where we got. And then you can build the server and call await Fastify.inject. Does it make sense for you? Cool, I see people nodding. Hopefully everybody else is. What is happening when you call inject in the background? Is that a mock or is it a real? So the full Fastify server will restarted up. So all your plugins internally will load all the structures, everything we get loaded in your system. And then a new fake HTTP request will be put inside Fastify. We use these module. Okay. These are the information. This is Siri. Contact of contacts. I'm sorry about it. And we use this module, call light my request. This is what we are using internally. You don't need to worry too much about this. Okay. It's just a fake HTTP request. Is internally, it's internal. So it's not creating a server or anything. But it's highly compatible with Node Core. Does it make sense? Yes. Yep. Yeah, Inai. Matteo, correct me if I'm wrong. But fastify is just a collection of plugins that you specifically like, and they're fast and they work together, so it's kind of like a wrapper over all those plugins that you can do. Is that correct, or? No. Well, okay. Sorry. It depends. So you can say that if I'm going to fastify, this is, oh, sorry. Repositories fastify. Okay. This is the fastify repo. Okay? If I am going to go in lib, and I am going to count, oh, it's, we have something like 30,000 lines of code. I don't know if you can see plus fastify.js at the top. So I didn't know if you consider this small or big. I don't know, but it's definitely not just some, like it's 15,000 lines of code. Plus, there is a lot, there's a very big ecosystem. So there is a framework, which is the core, which is thin. And then there is an ecosystem of plugins. Now the framework, there's some very key parts in coordinating all of those things. So it's not that there's just a collection of opportunities, actually. Does it make sense? Yes, yes, yes. Cool. Is everybody able to write your test or do something with your tests?

It's not strictly needed because we are not actually creating any resources. But it would be way better if you did this. So you can actually do here, down, and then you do fastify.close.bind Fastify. This is needed because you want to shut down your Fastify server once you have run your code. Not strictly. Sorry. So this line of code will like configure that after the test is run, Yes. And it will close? Yes. Okay, okay, thanks. Now, Fastify have both have a startup sequence and a close sequence. So you can, for example, if you're using a database connection, it will close that for you. By specifying this, it will actually do this magic. Essentially do, it will actually do its whole thing. So you won't have any lingering connections or other bits in your server. Sweet. Are you saying that by trying running the test two or three different times, we have multiple instances running on the background because we didn't close it? Well, you're not running anything right now because if you use Inject, it does not create a server. Okay. But if you, for example, if one of your plugin, you are using a database connector? Yeah, yeah, yeah. You will be in trouble. Yeah, got it. Okay. So, next step. Validations. Hopefully you like validations as much as I do. So, we use, Fastify use, who do do do? This can go. Okay. So, you see the slides, right? Yes. Okay. Ooh, sorry, validations. Validation, okay. So we are using, in Fastify we use Ajv to validate our slide, to validate our code. Which is a high performance JSON Schema validator. You can check it out. It's pretty cool. Now, I am going to ask you to start creating a new post slash login route in route slash login.js and validate the body of the request to ensure it's a JSON object containing two request string properties, username and password. Okay. Off you go.

Off you go. Cool, okay. So, it's something like this, hopefully. So, in here, we are specifying two bodies, two parts of the body. And we are saying that we want a body defining a post with a body and the response. Were you able to test this route? Did you test manually? Okay. One of the key parts and bits of... So be careful that if you want to wire this up, you need to import it, okay? So in case you wonder, you need to, so... Okay, so in case you're wondering, you need to import it as well. So in here, you have... You are importing your routes and then you're running it, log in. You're actually creating something like this. A few important parts, is that when you're testing this, manually okay, so is step six validation. LS node server. You always need to... You always need to... You always need to specify the content type. So Fastify is not lenient on the content type that you specify is actually very strict. If you're saying a body, you need to say what is what you're sending before passing. Express will try to make it work. However, these are some unwanted consequences on how you structure your application. So not really nice. Note that we can even try with the wrong things. So it would, oh, it's... It's, sorry. Oh yeah, so these just works, but if we say, we change the property, it won't work and it will say that you have, about the should have a required property user name. So it's actually validating, we are testing that we are validating. You can actually write tests if you want for all of this, by the way, you can find the tests written for all the stuff that you can probably copy and pass to your next projects in the future. So anyway, so here it is. Does it work? Does it make sense? Cool, yeah, okay, fantastic. So I will call it a five minute bio break for everybody. We have been doing this for maybe an hour and a half. We are probably tired. I am, I'm definitely ham. So I am going to stop my video and we'll be back in 10 minutes, okay? So there was a question from Stephan Baselier. I hope I pronounced your name correctly, about how to have multiple validation error on their response body. It's possible there is a configuration flag inside, in AJV. However, that is a catch. It's, it can be, it was enabled by default at the beginning. We disabled it because it's perceived as a security risk inside AJV itself. So depending on your structure, if you're using an array, if you're asking an array to be validated, depending on the type of properties that you are putting into those objects in the array you can actually create, allow your attackers to create a denial service against your application. Because essentially if they are missing a property, I'm putting it simply, and you're passing an array of 100 elements, then you will get one error for each one of the 100 elements. Computing some of these can be quite complicated. So the reason that was disabled, essentially it's because AGV consider it as a security risk. Another question was, can Fastify be used to create a WebSocket server? Yes, of course. There is Fastify WebSocket. Ah. You can just use this and you will get it. I have a question about the WebSocket server. Is it using a Socket.io or WS? WS, Full WS. Oh, WS. WS, Full. It's just using WebSockets, okay? The LDR. Friends do not recommend friends using Socket.io. Yeah, I don't. So don't use Socket.io. It's very convenient for a lot of things. However, running it in production is actually a nightmare. So, unless you need to support IE8, 9 and 10, don't go there. Okay, great. That's fantastic, that's what I like. So, this is actually using WebSocket. Like use pure WebSocket things. So this is, this does what it says on the tin, it's actually WebSocket. Okay. Which by the way, Socket.io was great when you need it to use to support multiple transports, be to have real time communications. So, but that's not needed anymore as WebSockets are everywhere. In case you need, for example, subscription rooms, the concept of room subscription, you can use the other modules to build on top of WebSocket, kind of building your own protocol on top. Gracias. Niente.

Perfect folks. Okay, any other questions? No. Can we move forward with our workshop? Authentication. Do you like authentication? No. No. Does anybody like authentication? It's a necessary evil. It's a necessary evil, cool. We are going to make it fun. Hey, we are talking about Fastify JWT. So, JWT is probably the most popular way of doing authentications these days. Most hyped way of doing authentication these days. So, essentially, you basically generate a JWT token, you authenticate you users amount, then you generate a JWT token that can be used to access your application. A JWT token is typically part, is composed of various things. It can encode some information, like for example, the user, and then that is signed. More questions coming, I will answer later, okay? On that. So, this is it. We can use, authentication. So we want, I ask you to change your index.js file, to use, add the fastify-jwt plugin, using an un-coded string, as a secret property. So, essentially something like, fake, that would do. And the configuration options, okay? Then, add, then change your logging route, so that, you actually generate terms, at JWT token, when that is done. When the, if the username and password match. Okay? Off you go.

So, a few questions, that came in. What about using Fastify sensible and Return Reply Unauthorized? Yes, that's perfectly fine. Fastify sensible, it's one of. It's a nice utility module. That, there are a lot of things, that you can actually just use, so that you don't need to, do a lot of things yourself. You can, just use this and everything will just work. It's actually, there's lots of very handy bits, in here. I personally like it. Another question, that came in, was, can Fastify Oauth with Azure? Or MS Graph API using MSAL? So, long story short, there is no out of the box module, that I know of. But, this is buts, the life is full of buts. In one of the projects, that I'm working on at the minute, we have it, authenticating against, Azure AD B2C, for example. So it's actually very simple, to create those authentications from scratch. But I don't know if there is a plugin, and how much is, those are different, compared to, I know Azure AD, integrates in one way, Azure AD B2C, integrates in another different way. And I highly suspect that, MS Graph API, would actually authenticate it, yet in another different way. For, the beauty of Azure, I don't know how many of you have been working on Azure, but it has been a wild ride so far. So, essentially it's, I don't know, I have my feelings.

Mateo, I have a question regarding, how do you recommend to handle secrets, using libraries like, dotenv, or what do you recommend us, to handle secrets in production mode? Okay, first of all, there is a few bits to say. I recommend you to not use, R-coded secret for your JWT token. You should use, public private, key certificate, private, public private key system. So that, there is actually a full key object, that you are, that you are passing through. So, that's the first one I recommend, okay? Which I truly think is the best way. And these are typically the only one using that, knowing that secret, having that private key, is either, Cognito or Out0, or, Azure, ADB2C, or one of those systems. So essentially, somebody else in your, in the architecture of your system, is handling authentication for you. So, this is the starting point of, on authentication, you should not be doing it. Okay? My recommendation is, like authentication is a tricky business these days. Lots of things to consider, unless you know what you're doing, you know, try to avoid it. Generically, four secrets, I recommend either loading them up, via environment variables. So that, you are loading them up, and so on and so forth. However, loading them up via environment variable, kind of, expose you to some leakage risks, in the more tight environments. Because, essentially, if you are defining, so those environment variables, are passed in via Kubernetes, or via AWS, Azure, and so on and so forth. So by poking, reading up those settings on all the pods, that your container, are configured, they will be able to, read those secrets. Right? So, my recommendation instead, is to, if in those more tight security deployments, is to use, your cloud specific, secret management. So, on Azure, there is this key management system, on Azure, AWS, has the same. I don't remember the name. I just, they are all the same, to some extent, we have just published an article at nearform, about these modules. So there is this thing called, Fastify, Secrets, and core and so on. So you have, here we go. Well, these are not linked here. So, this Fastify Secrets AWS, for example. So these are for AWS, it increase with AWS Secrets Manager, and, essentially, it's, you just, you can just read things up, essentially. So, note that with these, you will just need to assign a role, using AWS, to that container, and you will be able to read it. So there is no configuration needed, what said the secret, from the app. Does it make sense? Totally, I completely agree with you. Even there is another service called Bout, which is very good. Yeah, yeah, yeah, I know. Yeah, I, we don't support these in this module, but, Oh, sorry. I didn't want to open this up, and I want to open the blog, and there is, we just published this article, and I'm covering secrets in Fastify. So it's, maybe you want to take a look.

Cool. Were you able to create, were you able to create the authentication system? Yeah. Any blockers? No, yes, no, maybe. So let's look into it. It's, we have a slash, a post slash login. We pass in a schema. One of the things that I am showing here, you see that I'm using the schema and the route in every single file. Okay. I keep the routes and the schema inside the same file. I've seen a few people that tend to separate the schema from the route itself. And, from time to time, I see when people split their schema, the handler, schema and the handler, in two different files, as well as the tar leaf outside the plugin. Don't do this, okay? The schema and the function that manages that data should be visually near each other. Each other. If you keep them in the same file, either one on top of the other, you will know... It will be very easy for you to know how the data that is getting into your function is going to be validated. If you split that into multiple files, you will not know about them. Hopefully this helps. What is your opinion on additional properties? Should we omit them or just leave it like the default is? Sorry. What do you mean? Well, there is this property on AJAV schemas, the additional properties, so you can remove them from the body of the request or the query statements. I am... My is always remove them. The reason is, especially when you load things from a database, when you're loading things up from a database, you might get some properties. Somebody else might add a new property on that document or something, and that might be sensitive. So, you always want to tightly control what you return to your users so you are not leaking private information, which could give some unwanted information to attackers, best case, or worst case, be made to make you non-compliant with GDPR. So again, we live in the world we live in, so be tight in your outputs. Does it make sense? It makes sense, yeah. What about the input? Are you also like, yes. Trying to be as explicit as you can or not? Yes, essentially, yes. It's very rare that I turn on additional properties. Understandable, yeah. Keep those things tight. Cool. Okay, next step, configs. Configs are the most, as we said, we were talking about them before, are one of the most important parts. Okay. So, you don't want to commit your step into, to commit your configs into the code, okay? This is bad, we all agree this is bad. You want those configs, to load those config at runtime. So, this goes into the 12 factor application mantra. Hopefully you will, I'm telling stuff that you probably know that as well. So, just a sec. Then, what I'm asking you to do is to add environment variable support. Now, there are also things that we want to configure, like for example, the log-in level. And, if you want to enable pretty print. Because that's not a production setting in the lock, okay. So, in order to configure a log-in, you're using to use this module called M schema. And, I want you to load the JWT underscore secret environment variable with a fallback to a.env file. So, that when in development, you can have a.env file that you don't commit to configure your development, your dev environment setup. So, the module is like this, Fastify M schema. And, then, you have to do the same thing when you create the M schema. And, as you can see, it's pretty simple to use, you require it, or import. You call the scheme, you define your schema. You can define your schema with a fluent user schema if you want. Then, you create the config. And, then, you call M schema with the schema and the data which is Process.env by default. So, you might just want to pass the schema. And, you need to turn on.env. If you turn on.env true, it will actually load your.env file. Make sense? Then, use that to configure your module. A few things that I'm, actually... it's actually very important is, you want your module to be configured in server.js. So, server.js starts your application up, as well as configure your server. Index.js take that as an option. So, the two things are split. Why do we want to do that? Because in our tests, we don't want to load the development config. So in our test, we want to run things isolated as much as possible. Then we have a dot dev for our development environment. Off you go.

Hey folks. How are you doing? We're good. Are you able to use to configure this and use it? Yeah.

Doing great. Okay. Happy days. Cool. So this is the solution that I will go for. So I would, know that these might not be needed. You might want to change these if you want to have in multiple locations. We have our three properties. We want the JWT secret, the log level and PrettyPrint. The JWT secret is required, but the log level and PrettyPrint are not, and they have two defaults. So you can configure it on and off, essentially. So you can put all of these into a config.js, and then in step eight, and then in the server file, you can import that config and then pass each to the server. The reason why we are doing that is because, so that we can configure it differently for each in tests and so on. This is one of the things that a lot of people, like this is a key part of writing testable and maintainable node servers. A lot of people online and in other clients on some of my clients, they have done that they define all the routes in their main flow. So essentially they don't have these split between the moment where we are building the server and the moment where we run the server. These different enable us to do proper testing of the system. So you can instantiate the server multiple times. This is very common in some of the Express setups. I don't know, like a typical Express application setup as have you exported the Express app and be done with it. It's all globals. I don't know, that's my... Here we go. So how do we use it? Well, you do the build server. Here you go. That's the build server. So now the next step is that we're going to do is we're going to add some... We are adding a user being authenticated via JWT. Next step is protecting routes with those JWT tokens. We need to verify the token coming in. How we're doing it? We are going to use both Hooks and Decorators. So first of all, Decorators. We need to... You see, these are the three key parts of Fastify, Plugins, Hooks and Decorators. So I want you to create a Plugins slash Authentication.js that you essentially, you use these to extract what you had into the index file. And from, you move it from index to this Plugins slash Authentication. And then you expose an Authenticator, Authenticated Decorator on the Fastify instance. So that, which calls the verification of the token. Sorry. I repeat, sorry. I mean, it is on the slide. So it's probably better to keep it on the slide and read it up. Please ask questions if it's not clear, how are the rest of you doing folks? All right. Folks? Yeah, good. Thanks. Nice. Okay. So happy days. Anybody that is completely stuck and doesn't know where they're stumbling their head? Yes. Save. Okay. So, so, this is your solution. Oh, sorry. What's happening? I don't know what, this tool is getting me nervous. Okay. So, and, so. This is the bytes. So we are going to get a, ah, what's happening? So, in here you are seeing that you are going to register Fastify's WT and we are calling decorate. We are the decorator to our, Fastify instance. You need to use this bit, this trick to publish the decorated value to the main instance, okay? Otherwise it will be encapsulated. Let's talk about hooks. So in order to use what you've done before, have you got a question? Yes. Why not using Fastify plugin? It's the same thing. Okay. This shows our, what Fastify plugin does. It says that in order not to encapsulate the current instance. Yes. But on the documentation, you say to prefer Fastify plugin rather than this, because it might change the implementation. Yes. But it won't like it's a higher level up utility.

So it's we recommend something, but it's not always. Yeah. So I wanted to know this is preferable or to use Fastify plugin? It's the same. This won't change. Okay. Okay. But because on the documentation it might change. It won't change. So where this is written because you know, it's I will remove that sentence is not going to change. Okay. Okay. Then skip the, forget the question. I'm gonna send you the part that this said in the documentation. Yes. So again, it won't change in Assemble major change. So don't worry about it.

I have a question. Do we need to still register the authenticate plugin in domain at.js or index.js? No. No, you just removing... So yes, you will. So you need to... No, you need to load it. So it's not loaded manually. Okay. So. Okay, so. Okay, so Fastify LiveCycle. So in order to use what we've just written, we need to integrate it with the life cycle hooks. So if we want to protect a route, you need to... We need to execute that function as one of our hooks. How are we going to do it? I would recommend you to create a get slash route in route user index.js. Something like this. I don't have much time, so you might want to cheat. I'm giving you five minutes. So create a route, create get slash route in route slash user slash index.js. And this is not correct. I would put this into on request. Sorry about this. And this is going to be, I need to take some notes on the exercise, why the heck it's, is there. So use on request, but whatever. So, off you go folks. Let me ask you a question here. I mean, I've obviously got a syntax error or something, but Do you want to share your screen? Not really. But, you know, I'm not able to find the line that I have the problem in. You know, that's the question I have. So I've got a stack dump, but I can't, you know, it's all internal from Fastify. That's not referring to my code at all. Yes, so this is one of the problems of, what error are you getting? Cannot read property bind defined. I don't know. I'm sure I did something wrong, but I mean, I just don't know where to go to solve it. Okay, so to be clear, we are working on this in certain cases, the stack of the error messages are a little bit awkward. So we are, if you're wondering, we are working on it here. It's essentially, what it is, improve errors, user experience. It is. So can it happen that it's a syntax error on my part? But we still get. It's not a syntax error because the file loads, but it's something that is empty that you're calling bind on that it does not work. Okay. So it's not a syntax error straight, your code actually executes, but when you're calling your calling bind onto something, typically it's on a plugin. Now, because the plugin loads as synchronously, but I would need to share to see what you're doing to help you. So. Yeah, it's okay. Don't worry. Let's carry on. But if you want to share your screen, I will be happy to look at it. So. Well, I just copied some. I can show it. Why not just a sec? I could do. That's right. You know what? Carry on.

I think I'm not. Can I? No, it's okay. I can't share. Let's carry on. Because it was just a general question about how we serve debug, when we have a problem. So it's normally there should be there correctly, but it's weird that it's not. So essentially like some of those routes, some of those things are known, like for example, in case you redefine an already existing route. It won't give you the right error. Okay. But for others, it's, if I can't see it, that will be very interesting to see if you can to see it, because it is not. Yeah, but I think I can't share, actually, on the Zoom. Yeah, you need to reboot to go out and reboot. Never mind. Sorry. I don't know how, If you can pass your file, I can take a look, essentially. That's the only thing I can do there, next to the. Yeah, okay. We're doing a screenshot, maybe. How are the rest doing? How do we test it with a curl command? You need to take the token from the previous request, and then use the token. I see. Okay. There is an example in the chat from Martin. Okay, thank you. Yeah, you need to get the run example later, whatever that means. I see. Okay. Does it make sense? Is there anybody stuck? I know William is stuck. I hope it got out of it. The rest I can't see all of you, so I hope you are good. I know Martin can be... I know Martin is doing it because he posted a link. The example, so... Yeah, okay. Perfect. So now it's the time where we switch to one of my most loved modules, Fastify Autoload. At this point in step 10, you will probably have in step 10, at the end of step 10, there are two folders, one called Plugin and one called Routes. And you have a block of imports here. Right? You see, this is going to get crowded very quickly. So the more functionality you add, the more crowded this gets. Okay? Fastify Autoload is a convenience plugin that load all the plugins in a directory and configures them matching the folder structure. Pretty neat. So, I'm asking you to integrate Fastify Auto, two instances of Fastify Autoload. One for the plugins folder, one for the routes folder. And remove the user path from user slash index.js as Autoload will magically get it. Ha, good for you, William. And Fastify Autoload will automatically add the path, derive the path from the folder structure. Cool, have fun. How you doing folks? Did you make it? Did you break it? There we go. So do you prefer working with autoload or without autoload? With autoload. Yeah, yeah, everybody does. Okay. There's a lot, there are a ton of options in autoload. So you can actually configure it in the way you want it to be working, essentially. So you can have the auto prefixing in or not have the auto prefixing depending on what you like. It's one of my favorite modules, to be honest. Because it's a good compliment to Fastify itself. However, it's way more opinionated, Fastify is opinionated, but autoload is even more, even if it does a ton of configuration options. So that's why it sits in its own repo. Also the testing for it is a total mess. I don't know if you try to open that up, the test folder in that module, it actually creates, it has infinite project structures in there. So it works with, I don't know, it's a really hard module to test. So anyway, yeah, that's it. Okay, so here is what we are doing, we are using this DSM utility to create the folders. I am creating, we need full paths right now. So that's why we are going to use DSJoin from DSM. I tried without the join, it seemed to work okay. It's still work okay, great. Then it's not needed anymore, I'm very happy about it. Cool. Yep, that's it.

And then you automatically, you need to put the slash here. The slash will be because it's user, okay? Did it work for you? Okay. Now, we are moving into the next last step. So, first of all, we have 20 minutes. You would probably need 20 minutes plus to do this last step. So, I just wanted to ask if you got any questions before we go into the last step.

I've got a general question here, because I don't know much about Node either. I remember looking at Node servers before and thinking they weren't very mature because we just use PHP. But where would you say was the use case for Falsify? Is it really, if it's a site with a large load, you know, a lot of requests, is that where it wins? From high requests to low requests, essentially you can use it for whatever you like to some extent. It powers a lot of very high traffic servers and in some very low traffic servers, essentially. You can even run it in a Lambda if you want to. So it's really easy to work with, the key part in Fastify is it creates some sort of structure in your application and code with the plugin system so that when you actually run your code you know what's happening and you know what it's doing, okay? So it's not just like a global scope where you stick everything, like, with other techniques.

And what about Nginx for instance? I mean is it much more efficient than Nginx or? You are comparing oranges and apples. Really? Yes. Okay. Like Nginx is a, it serves static files. And does reverse proxying. Fastify you write your servers. So you have an Nginx and then you have your Fastify. Right, okay. So you would set it up like that, would you? You'd have Nginx in front for serving the file? Yes. Yes. Okay, okay. Well I would typically, I would not server the files either from Nginx. So you want to have a CDN in front of everything. Right. Okay. You typically have a CDN at the outmost layer and then you have the, and then you have multiple, and then you have your load balancer and servers behind. Okay. Cool. I seen a question from Martin that says maybe compare it to a Golang. This is a very good question. Okay. My take on Golang is I typically write code and framework for the wide mass. So I tend to make other stuff, Fastify wants to take some certain class of things that are really hard to do well, easy for everybody. Which is kind of the principle of node.js. The Golang culture is more off. We are from Google, you need to be smart. I am not, I'm sorry, somebody's laughing, but it's one of the key distinction of JavaScript versus Node.js versus Golang. So from my point of view, if you are smart and if your developers are really smart, use Golang. But it's not really accessible from my point of view. So my point of, my take is Node.js is a very good tool which is way better for teams because it provides a better developer productivity, essentially. However, I see a server written in Golang will be faster because it's a compiled language and yeah, it will be faster. But it is the same when you compare, for example, Node.js with Rust. It's basically the same. They resolve different needs in my opinion because, for example, you can work with Rust when you are doing some load processing of data, images, sounds, something like that. In Node.js, it's better when you want to accelerate the development cycle of your team. Yes, exactly. So if that's essentially the reason. Golang is a nice language. I've been adding... I had a very, very bad interaction with part of the Golang community a long time ago and this completely pushed me away from it. Essentially it's not a language that I would use in the... that I recommend using in the companies I am consulting with mainly. It's in the culture. As I said, this is a good that Google is the... You see it comes from Google. And from the fact that it only use one... They use one character variables everywhere. Like the idiomatic go use it one character variable everywhere because if you're not smart enough to understand what's that, you're stupid. And that's... Sorry, this is... For me that is the barrier. If you think that somebody that cannot understand from the context what one character variable is, that is stupid. Then you are not... We are not talking about the same... We don't share the same values, essentially. So that's a good question. There was another question in the chat about... Uh, um...

Uh, um... Another question is about Express. Yes. So, the TLDR on the relationship with Express is quite nice. I'm going to share some screens, okay? And let you draw your own decisions. Okay? Because I don't want to state it loudly, but I'm going to share my screen. And where it is, sorry. It's, ah! Help me. Wait a second. I am, here we go. Okay. You see the NPM? Yes. You see what time I'm highlighting? This is my take on Express. Wow. Okay. It's used a lot. It's very stable. Is it getting any active development? No. Draw your own conclusions. Now, there is a few problems with Express. And this is actually very important. Express does not support Promises natively. So, in Fastify, when you're writing your route, you can write an async function for your route. You can't do the same for Express. If you just put async in here and you throw, your process will leak memory. It's very simple to do that. In Node 15, from Node 15 onward, you will actually crash. Happy days, okay? So, be careful. Essentially, at this point, this is, I would not recommend being used, but it's my take on it. So, there are a lot of users. 66 million of downloads per month. So, how can you go wrong with this? Hopefully, I give you my TLDR of it. So, yeah, Martin, you say you don't have to change something that is perfect. Yeah, that's not true. The problem is that while Express is might be perfect, JavaScript in Node.js is changing. So, it's essentially a moving target. You need to release new features to keep up with Node. So, Express was frozen in time at five years ago. Essentially. Well, even more. Wait a second. When version four came out? Version four came out seven years ago, I think. Yeah, version five alpha one came out on November 7th, 2014. Yes, consider it. Okay? Sorry to be criticizing. I'm just stating facts. Okay? Coa is an error handling model that I don't understand. And if I don't understand an error handling model, I'm not getting into it. So, that's the answer for Coa. We are out of frameworks, folks.

So another question was if you would have to recreate from the GAMDAP, what would you change, if anything? I think I changed everything over time, I probably would not change anything. Essentially I have already changed most of what I wanted to change. So there is still a lot of things to improve, but there is nothing that we can't fix right now. It's evolving, okay? It's a moving target to some extent. It's evolving, keep landing features, adding new things, improving, and so on and so forth. So that's it. Any other questions?

Yeah, I'm just follow up. I'm just going to ask the same question again, I think, but now I'm just raising that simple crud applications. So is it a good sort of use case for that? And just on that, one thing I found before when I was looking at the JavaScript frameworks is that they sort of like what you call an ORM and the mapping, you know, providing support for access in the database was not so good as for instance, just using a PHP or Rails or something like this. I found that the JavaScript libraries were not so good for data modeling. So would you think it's still a good fit for just- Well, it depends. Okay, let me be, okay, let's be clear. So there are Cloud applications that are only Cloud applications. If you can, if it's Cloud applications plus some logic, we are talking two different things, okay? So from my take, if it's just a Cloud application, use Azure. Right. I don't know if you have, if you are familiar with Azure, it's essentially a GraphQL as a service. You just give it a database schema and it gives you a GraphQL API completed with authentication. Right, but what if it's a game, a game-like thing with some database? Okay, so to be out, so I just want it to differentiate because, so if it's something that is only CRUD, I would not even use PHP or Rails or anything. Okay, I would just use pure something else, okay? Some backend generator, something that does, something that does it all for me for free, okay? So I don't have to do anything. Like you can create a backend with Azure, in an afternoon essentially to be, like if I'm going for speed I'm actually going for speed.

For the rest I don't necessarily, so there are a few options for data access. From my point of view I typically write a lot of really heavy custom software, most of the time. So CRUD never exist. Like most of the code that I wrote or my company wrote or the company I work with, develops and so on, most of that is not, it's very custom. So to the point that as you've seen in the last step, I am actually just recommending people just use SQL. Yeah, so that's why I'm thinking that the data modeling is not so good. So we're just going to write some SQL.

So from my point of view, I know, so it is the problem. I know SQL very well. So because I know SQL very well, for me, I'm writing SQL and I don't have anything in between. So I'm very happy about it because I don't have to learn yet another tool that does not do what I like or what I want. I always had a very, very bad history with hibernate, J-Something, whatever, okay? There are a few decent things that you can use for data modeling. So the first that I'm going to recommend is this library called Knex. It's a library for writing queries. So it's similar to the... It's a query builder. It's actually pretty nice. If you're familiar with Rails, it is an equivalent. It's similar. It's Arielle, I think in the Rails world. Let me... It is, yeah, I think so, yeah. Yeah, it's kind of similar to... Oh, now it's bundled in ActiveRecord. Okay, so yes, I remember correctly. Okay, so Arielle. Arielle. No, no, it's fine. I give the recommendations and I know, and I did look at them all. My feeling was that just a lot of these were not very mature, these sort of JavaScript libraries. No, Kinect is super, super mature. Really? No, Kinect is super mature, to be honest. This one, it's one of my favorite, but it's called Massive. It's not really, it's not super well used, but it's, I like quite a lot. And that's kind of it. So what I'm using at, what we are using at NearForm is this module, which is we even wrote that. We've wrote our own tiny little thing. So here you go. There is one that you should not be using. So there are a lot of options that are between from okay to really good, but there is one that is actually really, really bad that you should not be using. And it's Mongoose. You will see it in every single tutorial out there. Don't use Mongoose. I mean if you're using Mongoose everyday. People are not raising hands because you are afraid of what I'm going to say. Don't use Mongoose, okay? The reason you don't need to use Mongoose is because they think they are smarter than the implemented joints inside the framework itself inside the ODM itself, which is an extremely bad thing to do, okay? If somebody tells you something like this, like, don't, this is horrible, sorry. This is the reason why, you know, essentially they say that they've written a joint that is better than the one that MongoDB provides. You cannot beat a native database at their job from the outside, okay? They are currently trying to defeat the laws of some of the basic fundamental of database development. So no, this is actually playing rock. Okay, sorry about this, I just wanted to say this stuff. Are there any other questions?

What upcoming Fastify feature are you excited about? Nothing? To be honest. Does that mean you feel it's pretty stable at this point? It's a maintenance as usual. So essentially, yes, it's stable. There are going to be some major changes coming in the next V4. And then there will be a V5 and there will be more changes, of course. But I don't expect, in the core at least, like the switch between two and three was actually a huge boost in term of developer productivity. I don't expect there is another one coming. There have been a few very interesting features that we have just shipped, actually, in the V3 line. So we have shipped the new host-based routing, so you can actually support multiple hosts on the same Fastify server. That's there. We have added support for a new layer for managing the schemas, completely changed the implementation of the way we manage the schema internally without letting you know. So basically, you haven't failed anything. Different change, but we have made it extremely more flexible to solve some specific edge cases. We have been refactoring the Fastify WebSocket module so that it has, it supports routes as well. That was not there before, and you can actually write hooks that are executed for WebSockets in the WebSockets. So that's great. So most of the things are actually being shipped. So there is not... There will be new features, but most of the features are coming from people that say, oh, I need this, and then they implement it. I'm excited to know what will come next.

There is actually one thing that is being developed. So we have been talking with others about developing some sort of React server-side server-side render component that is super fast. So it might happen sooner rather than later at this point.

Mateo, a couple of things. Thank you for your workshop. Thank you. I like it. And one thing about Fastify is in three hours, I feel like I'm in control of the server, which on Express I wasn't. Anyway, another thing too is I took the Broken Promises workshop last year and it was great. I'd like to take it again because it was- It's canceled tomorrow, unfortunately. I know James had a- Unfortunately James had a very big family issue due to COVID. So he's fine and safe, but you know, that's not- He lost a member of his family so it cannot be. Yeah, it's gonna happen in the future, maybe in another conference. Yes, definitely. Stay tuned, James or myself will tweet about it. So it's probably going to happen in less than a month, to be honest.

Okay, great. Okay, thank you. And how is your baby girl doing? She's good, she's growing. She's growing. She's almost three months old now, so- Wow, I know. Can you work with her? How do you do it? Hey, you haven't heard her crying or doing anything so she's just around the corner in my house, so. Okay, well, thank you. Thank you, folks. Okay. So long time, and, ah, yes. Just wait until she start running around. Yes, I know. Long time I'm interested in contributing to Node.js, but it seems impossible to me. How would you advise approach to this matter? How can I grasp on it so I can start contributing? So, okay. Contribute to Node.core or to Fastify? Fastify is pretty easy to contribute with, okay? So, it's, if you want to start contributing to Fastify, you can, the best thing you can do is you end up here. There is a contribute tag tab in fastify.io website. This lists all the, good first issue in the project. And if it was Node.core, I would like to contribute. Now, if you want to contribute to Node.core, there is, so what was your problem? Why could you not contribute Node.core? It's a bit complicated. Until recent days, I didn't really know how to even start contributing to open source project. But now it's a lot of code and I get lost in the way. So, that is this project, this website called Node2Do. And it help you getting it into Node.core. So, you click on the getting started guide and it walks you through the steps on configuring your stuff. Amazing. I know it was Walter Schultz asking. Thank you. However, some of the issues that you find might not be easy. So, I typically recommend to start contributing to Node core once you're comfortable to it. And then finding a bug that you have. So that's something you really want to improve or change. Because so that you will have the passion to go through it essentially. Are there any other questions? Oh, open API Yes, you can use open API. In fact if we are the most recent deployment that I've done that we are doing these days, is it's behind the Azure API management thing with automatic upload of the open API, generated by Fastify there. We are going to use the Fastify Swagger module. With, you know, of course, it's called Fastify Swagger, but it's open API as well. So we are going to use this module, Fastify Swagger, to publish things in there. So here we go. And you can do Fastify Swagger 2, or you can do open API. I would actually recommend, it actually works. And that's the thing. So, yes, you can support open API as well. Cool. Any other questions, or should we part ways? Because I am super tired. It's 8 p.m. So, yay, see you in Ireland. Yes. Yes, folks, and if you have more questions, ping me on Twitter. I'm very happy to answer. There are a lot of examples that you can find around related to things, so just give it a shout. Thank you. Perfect, bye-bye, folks. Bye. Bye-bye. Thank you.