I Would Never Use an ORM

Rate this content

What's an ORM? An Object-Relational Mapping tool (ORM) is a library to map a SQL table to a Class. In most cases, ORMs force the users to structure their code to have Model objects that include both data access and business logic.

Once upon a time, I did several projects using ORMs as I followed the common belief that they would simplify the development and maintenance of projects. I was wrong. ORMs are often a hurdle to overcome for the most complex part of a project.

As the next stop of my journey, I recommended people use the native languages of their databases, e.g., SQL. This works great for the most part, but it creates quite a struggle: there is a lot of boilerplate code to write that can be pretty tedious. I was wrong, again.

Today I'm presenting you Platformatic DB.

29 min
01 Jun, 2023


Sign in or register to post your comment.

AI Generated Video Summary

Welcome to a talk on Object-Relational Mapping (ORM) and its potential pitfalls. The speaker discusses issues with modals and the MVC pattern, as well as the benefits of structuring code around system features instead. They introduce PlatformaticDB as a solution for easy backend development, showcasing its deployment and testing capabilities. The talk also covers integrating with Next.js, writing custom SQL queries, and the speaker's plans for future support and database compatibility.

1. Introduction to ORM

Short description:

Welcome to the talk on Object-Relational Mapping (ORM). ORM promises to map your database to objects cleanly, resulting in fantastic and well-organized code. However, ORM can be a big anti-pattern for your code. Let's explore why.

Hi, everyone. And welcome to the I'm not going to let you sleep talk after lunch. I don't know. Do you have good food today? Hopefully. But hopefully, you will not be sleeping in this talk. So please let's start doing a little bit of stress. You know I'm joking. I'm not that kind of speaker.

So yeah, to be honest, everything was said already. Not much to add. One thing there is a book coming out on Fastify on June 9th. So if you want to take a look, the name is Accelerate Web Development with Fastify. It's on Amazon. It's probably the top of the category at this point. And it's going like crazy. Anyway, apart from that, I haven't even have a slide for it. So I'm so good at promoting.

Anyway, this talk is about a topic that I really, really love. Object-Relational Mapping. I've been using Object-Relational Mapper for probably most of my career, or a good chunk of my career. And yeah, I don't know. So what do ORM promises you? Okay. So they have this kind of metaphor of, oh, we are going to map your database to objects very cleanly. And if you follow these rules, your code would actually be fantastic and well-organized and have no problem whatsoever. You know what happens with spaghetti when you cook it, right? Also, how many of you have used Java in your lifetime? Okay, so for all of you and for all the others, I'm sorry, do you know what happens to your application when it uses an ORM? It hibernates. Sorry, Java joke, only the people that knew Java. I've been trying to get some. I've used hibernate. I seem I'm young, but I'm not. So what do ORM do that's wrong and why it's a big anti-pattern for your code? So whenever you're writing, typically most ORM have this concept of a modal object.

2. Issues with Modals and the MVC Pattern

Short description:

Modals have three main responsibilities: managing persistency, holding data in memory, and implementing business logic. This violates the single responsibility principle. The popularity of the MVC pattern, modal-view-controller, is the reason why everyone is using modals. However, this pattern has its flaws. When coding a feature, you have three boxes: modal, view, and controller. But in reality, the view is often missing, resulting in an excessive number of models. For example, a real-world project had 2,000 models, causing a one-minute load time. ORMs have been delivering spaghetti code since the 90s.

How many of you coded a modal? Everybody, right? I don't know. Who has not ever coded a modal class in their lifetime? Great. Okay, amazing. So good for you. You have dodged a bullet.

So what's wrong with the concept of a modal? The problem with modals is that a modal typically has three main responsibilities. It manages persistency, it holds the data in memory, and it implements business logic, which sounds a little bit too much. There's this thing called single responsibility principle, that is something, one of the engineering things that went somewhat popular. So I don't know, but why is everybody doing this?

So the reason why everybody is doing this is that there's a nice pattern called the MVC pattern, modal-view-controller. What does this thing say? It's a structure to organize your application. Originally it was invented by Smalltalk to develop application on the desktop and then adapted for the front-end. Ouch.

Now what is the problem? So the problem is actually easy to follow. So you typically, when you, if you're coding your Node web app or whatever, you have three boxes. You have the modal, the view, and the controller. You have three boxes. So you want to code a feature. You have three boxes, you put the feature in one of your three boxes. OK? Good, right? Now, do we even have, do we have view still? Probably not. So we have controllers and models. Well, very quickly, you have 2,000 models in your application. It's actually very common, right? You think that 2,000 is a small number. Like, this is number from a real-world project. They had 200 engineers that are working on application with 2,000 models. And in order to have that system start, it takes one minute to load with all those codes. Why? Well, because it's a model view controller. You load all your models at the same time. It does not scale well in complexity, because you only have two things in which you reorganize your boxes. In fact, ORMs are so great that they deliver spaghetti code since the 90s. Okay? Sorry.

3. Introduction to Fastify and Code Structure

Short description:

Back in 2016, I created the Fastify framework as an alternative to the model-view-controller architecture. Instead of organizing code around models, controllers, and views, it's better to structure it around the features of the system. This approach allows for easier migration to microservices. The Pareto principle, which states that 80% of outcomes come from 20% of causes, applies to software development. We can ship many features with minimal effort, but some features can be challenging to develop. The first iPhone lacked copy and paste functionality initially due to its complexity.

It's an old system, eventually. And I like my carbonara, by the way, so if you want, we can talk about carbonara later on.

So, back in the days, I created this framework called Fastify in more or less around 2016 and I was looking at how we could structure our applications. And I said, well, you know, we should not really be promoting a model-view-controller architecture here. So what can we do instead that's not model-view-controller?

Well, what you really want to do when you're building an application is that you want to structure your code, laying out your code around the features that you're building. Okay? So you have your products, you have your cart, right? And then you have your orders. You probably have the user metadata, the advertisement, the B2B, shipping, I don't know. I'm losing the last bit of space in my, in the stage. So, anyway, you have all these things and you want to line it up one after the other and structure your code around the features of your system and not about the fact that it's a model or a controller or a view. So you want the code to be close to the rest of the stuff. It also allows you to migrate to microservices when you want to migrate to microservices. Right?

So, again, why all of this matter? Do you remember when this thing first came out? I don't know how many of you were doing software. Everybody thought, oh, this is a game changer. And how does this relate to the Pareto principle? Well, the Pareto principle tells us that the 80% of the outcomes come from 20% of all causes for any given event. What does this even mean for us and why does it relate to the iPhone? Well, in practice, it means that we can ship 80% of the feature, numbers made up, of course, in very little amount of effort. Okay. We can ship a lot of features with very little effort. And some features are going to be incredibly hard to develop stuff, to develop. You have probably seen all day. You know, you start a new project. It's greenfield. Everybody's shipping features every week. And then after six months, management is super upset. Oh, your velocity is going down. I'm fighting half of you or something. I don't know. People are doing this these days. And so why does it matter with the iPhone? When the first iPhone came out, it did not have copy and paste. I don't know if you remember. The first iPhone could not copy and paste strings for data from one thing to another because it was fucking hard.

4. Optimizing for Shipping and Complex Features

Short description:

Sorry for the word. It was freaking hard to implement copy and paste in real life. When building something new, should you optimize for shipping more features with less effort or for making your life easier when shipping complex features? Many of us fall into the trap of implementing things based on great tutorials that don't work in practice. When choosing a technology, consider one that removes repetitive tasks, even if it may require more effort in the day-to-day development process.

Sorry for the word. It was freaking hard. Beep, please, in the recording. It was freaking hard on the... To implement copy and paste in real life. It's another problem, unfortunately. And so they didn't do it. Fine. Okay? Ship faster.

So when you're building a new stuff, something new, what would you optimize for? Would you optimize for shipping more features with less effort? Or with actually making your life easier when you need to ship the big ones? The ones that are actually very hard to do? And typically as the industry, everyone of us fell in this trap. And we implement things that are, they use things that, it has a great tutorial and we could, everything is perfect, okay. In the great tutorial. And now I'm using it in Root 4 Real and it doesn't really make any sense. Okay. I've seen this in practice. So and that's the problem, right?

How do we do implement the complex feature? So what would you optimize for? And look, if you want to choose a technology, you might decide to pick a technology that help you remove all the repetitive tasks. Okay. To the point of, oh, I want to ship something super fast. I'm using a no code tool because it's great. Okay. I can ship, you know, that's the ultimate form of tech debt of using a, picking a no code tool because I can ship something just with a few clicks. And up until it doesn't do, it's the, it doesn't support my workflow. And then I'm stuck and I need to rewrite the whole thing from scratch. You know, that's the ultimate form of optimizing for, you know, the beginning of a project or even, you know, somebody will say, oh, I'm just, I'm not even doing that. I'm just connecting together Figma pages for the first iteration. You know, we've seen people doing that. And it's great. It works. But then if you want to optimize for complex features, typically it comes with a little bit more inconvenience for the developers in their day to day. Okay.

5. Challenges with ORMs and Backend Requirements

Short description:

So what do you do? Going back to ORMs and why I don't like them. ORMs help you at the beginning of a project for CRUD and easy tasks. But there's probably something better to do. The best line of code is the one that I don't have to write. When I want to write a backend, I want it to have the quality I desire and be able to run locally.

So what do you do? Okay. Do you do one? Do you do the other? I don't know. You need to pick. Oh, pick, pick. What do you pick?

So going back to ORMs and why I don't like them. So what you see is that you are coding your migration. your schema, and then you probably are running it. And then you set up your ARMs. Then you need to write your models. Then you need to write a lot of routes or solvers to build your models. And then after a bit of time, you're screwed. Because you're back writing custom SQL anyway. Because the ORM is slow and problematic and it doesn't do the thing that you want. Or you don't know what it's actually doing. Oh, I'm just calling two methods here. Why is it running a database query that's this long? What is happening? Anyway, I'm not super fond of them.

What do the ORMs help you? Well, ORMs help you at the beginning of a project for CRUD and a lot of things that are easy. There's probably something better to do. For me, the best line of code is the one that I don't have to write. I have another way of saying this, but it's probably another bad word that I cannot say on stage. The actual thing is, if I don't have to write code, it does not become legacy and I don't have to maintain it. It's probably better for everybody. When I want to write a backend, I have a few requirements for it. I want a backend with the quality that I want. I'm sorry, I've been doing this note thing for a bit. But I want something that can run locally. I don't want one of those fancy databases in the cloud. I'm sorry. If you like Dynamo or others, I'm not in love. I want a database that I can run on my computer.

6. PlatformaticDB: Easy Backend Development

Short description:

I want a backend with custom APIs, basic authorization, GraphQL, REST support, and the ability to deploy it anywhere with multiple databases. Last year, we created PlatformaticDB to help you build an easy-to-use solution that doesn't hinder complex feature development. PlatformaticDB is one step less than coding from scratch. You define the schema, apply migrations, and PlatformaticDB takes care of the rest. It's built on Fastify, with OpenAPI and GraphQL plugins, allowing you to code custom functionality in JavaScript. Demo time! I'm running our generator to create a database and will generate the types later.

And decide where to watch it. Then I want to be able to do queries using the custom APIs of the database. I want some basic authorization, because coding authorization is actually super horrible. I don't know how many of you have coded authorization sistemas. They are horrible. I want GraphQL, REST support, maybe Apollo Federation, I don't know. I want to be able to deploy it where I want and multiple databases.

So I go back and code. Sorry, this was the talk. No, I'm joking. And so I typically want to have the cake and eat the cake at the same time. I want this backend done, but I don't want to write it. So last year I had this thought of, maybe I can just write something that could speed it up for all of you to create it. And this is part of the reason why we created what is now called PlatformaticDB. And at Platformatic what we want to do is we want to help you build a solution that can be very easy to use at the start of a project, but also something that does not stand in your way to actually ship complex features. So build something gradually.

So PlatformaticDB, essentially it's one less step than coding your stuff from scratch. You just define your schema, which is great, then you apply your migration, whatever, and PlatformaticDB takes care of the rest, you get your routes and so on. And if you need something custom, which of course you will need something custom, you can just code it with JavaScript, and I'll show you how to do that in a moment. How does it work? Well, it's all based on top of Fastify, so we have an OpenAPI plugin, a GraphQL plugin, and your code, all sitting in the same Fastify node process, in the same Fastify system, and it all works fine.

So demo time. Would it work? I'm challenging the demo god, as usual. Okay. I don't know. Apparently I have a bad reputation for demos that don't work. So what I'm doing is I'm running our generator to create a database. And I'm doing this now. And yeah, no, I'm sorry. I'm not doing NPM install now, but I'm going to do it later. And generate the types.

7. Deploying and Testing with PlatformaticDB

Short description:

We generate a configuration file, type definitions, and migrations. The table has two fields and automatic types. We deploy using platformatic start, store data like Star Wars, query movies, and use subscriptions and WebSockets. Building APIs with this is straightforward.

And yeah, we're not going to deploy these using the GitHub Actions, yet. In another thing, we are just doing NPMI so that it's installing, while we are talking.

So how do I run this thing? So what does this generate me? This has generated something interesting. We are generating a configuration file and some type definition, some migrations. This is our database table, easy, not easy, whatever. You know, it's a table with two fields. And it has also generated some automatic types. More on the types later.

So now what we are going to do, we are going to call platformatic start to deploy this. Ouch, what happened? So we can go in platformatic DB, and we have this. And what we can do is we can try it out, for example. And we can store something called Star Wars in here. So this is an open API generator, and we have all the things created for us. And we run this, and this has been stored as Star Wars. We can also run it as graphical. And we could, for example, query all the movies and get all the movies. Okay? Also, what we could do, we could use subscriptions and WebSockets. So if we want to save something else, like the Wizard of Oz, I could run it and... Oh, no, that's true. So I need to do that. I need to choose Windows. Cool. So this Windows is running that. This Windows is storing not the Wizard of Oz now, but Harry Potter. And I'm storing this. And as you see, we got Harry Potter on the other window via GraphQL subscription. All of this comes out of the box, as I said. It's actually very straightforward to build APIs with this. What else is there? Well, a few more things. So this is finished running.

8. Using Fastify Plugins and PlatformaticDB

Short description:

With Fastify plugins, you can easily define your own routes and customize your application. The live loading feature in the Waggly UI allows you to see the changes in real-time. PlatformaticDB supports relations and provides tools for managing migrations. You can add custom resolvers to GraphQL and perform various customizations.

So what we could do, for example, is we have a plugin. And this is just a normal Fastify plugin. So I could potentially just call my decorators, and, for example, I could define my own routes. So I could do app.get. And I don't know, get all the titles for my movies. And this is actually very easy to do. And oh, I need the arrow. Okay. And not bad, const titles. Await. App.platformatic.entities.movie. You see there is all auto completion here. So find, and we need to pass in empty objects because you want all of them. And then we can return the titles.map. And here, m.title because everything is correct. We have refreshed this. And if we go to our Waggly UI, we refresh it, and we automatically have the titles already defined. All of this is live loading behind the scene. And we could try it out and execute. And this is returning the titles that you have just shown. So you can easy customize. You can add custom resolvers to GraphQL. You could add a lot of things.

Okay, so this is good. What can we do now? Well, it supports relations. It supports all the things that you want to think you could support. So for example, if you want relations, you could we could add platformatic db migrations create. And we got a new migration. And here, we could do other stuff if you want to. So I'm just I am conscious of time, and I'm skipping some stuff.

9. Migration Demo and Platformatic DB

Short description:

I can show you how the migration works and deploy to platformatic cloud. We just raised our paid plans. We have a new front end. Create a new app named jsonation-demo. Deploy it and wait for it to run. Platformatic DB is built on top of Fastify and offers easy testing and writing with plugins.

So if you want, I can show you how the migration work, if you want to come after talk to my booth, if you are interested. Something that's very cool, though, is that I could even deploy this to platformatic cloud, which is actually pretty nice. And we just shipped raised our paid plans. So if you are interested, that would be cool. And hopefully the demo gods, we end the Wi Fi will be with me.

So we have a new front end. So we just need to accept the new term of service. And we can create a new app. And it's jsonation-demo. And we create the app. We can we need to deploy something. So we call it main. And create a workspace. And this is done takes a little bit of time. Then we can download our credentials. It's main.plt.txt. And I just need to move this from downloads to here. Okay. And then I just need to do platformatic deploy keys main. And it's now deploying it. So will it run, will it not run? We'll see. Over the Wi-Fi, over the conference Wi-Fi. So typically, this takes a minute and a half over normal stuff. But we'll see if we come back to it later to see if it has deployed.

So while we are at it, platformatic DB is all built on top of Fastify. All of those are just Fastify plugins so you can use them whenever you want, if you want to. Very easy to test, very easy to write. There are docs and guides for all of this stuff. You can even use those plugins in your app if you want to. So you don't need to use our main runner or anything.


Question on ORMs and Query Builders

Short description:

Did I code an ORM? Query builders like Kinects or Keasley are great. They all fall into the same category and help you write queries. Drizzle ORM is popular but falls into the trap of creating model objects. It may not work for all applications.

So I have a question for you. Did I code an ORM? It looked like the Internet. Okay. This is a fun one. As I said, platformatic cloud is available today. So it's still running. The Wi-Fi is what it is. So it will be there in a bit.

So thank you very much. Maybe the Wi-Fi will help me. I am more or less question time. So I'm actually taking the question here until this is done. So we'll see if the conference Wi-Fi will get to me. So let's give it up for Matteo.

The first question I have for you is not on here, but what do you say about things like query builders like Kinects or Keasley? Are those okay? Or are they in the same realm of ORM? No, they're great. Query builders are great. Do use query builders. I really like them, to be honest. Internally, PlatformRTDB is built against one of those things. So I'm more of a template string type of person, but they all fall into the same category. You need some facility to help you write those things. So, yeah.

And have you heard of Drizzle ORM or seen it? I did. A lot of people are talking about it. I kind of... It's great for TypeScript devs, to some extent. I still feel like it's falling for me a little bit into the same trap of creating model objects and stuff like that. I don't think it's... It can work for certain applications, but not all of them, probably. Okay.

Integrating with Next.js and Future Support

Short description:

To make it work with Next.js, you write your API, deploy it, and call it using fetch or automatically generated clients. Soon, there will be out-of-the-box fetch clients. It currently uses OpenAPI but will also support GraphQL in the future.

And then a question from the audience is, how would you make something like this work with Next.js? Oh, this is a great question. So, typically what you do is that you can write your API, deploy your API somewhere, and then call this API using fetch, or some automatically generated clients that you use your Next.js or Remix or Vue or whatever really, Svelte application. We'll soon have automatically generated fetch clients, so you will not need to code that client yourself, it will just come out of the box, which sounds great to be honest. The PR is open, so hopefully that will get done shortly. Does that use the OpenAPI client? Yes, it's built around OpenAPI, but it soon in the future will also support GraphQL.

Custom SQL Queries and TypeScript Support

Short description:

Writing custom SQL queries with Platform.js DB is super simple, just write SQL and run it against the database. Platformatic currently supports SQL, but MongoDB support is in the roadmap. When it comes to complex queries, write them in SQL. As for TypeScript support, you get autocomplete if you use the CRUD query helper and types defined for your tables.

OK, awesome. There's a question here, what does it look like to write custom SQL queries with Platform.js DB? Oh, it's actually super simple, you just write SQL and run against the database, it's actually super simple. If you want, I, for the time is, so much, so little time, so much stuff to talk, so I can go around for probably an hour, demoing all the features. So if you want to come join me at my booth, very happy to give you a full demo.

So for that, does it use just like a tagged template? Yeah. OK. Cool.

This question says, is it possible to implement external PubSub systems for GraphQL subscriptions in Platformatic? So, it has its own. So, you could hook it up to, potentially to what you're doing, yes. Big question on how it will need to... You'd probably need to do some checks internally to get things done your way, but it's likely doable.

And the other question is, is there any support for document databases, or is it just SQL? At this point, it's SQL. But MongoDB is in the roadmap, so eventually it will happen. It's mostly a matter of time. So, if you want to really want to do it, I will probably be happy to help you do it. I'll guide you and contribute that feature. It's not that all the plumbing necessary is there. It's just a matter of getting things done.

This next question, I think it's more about complex queries. They're asking, how do you handle a WHERE clause in combination with a JOIN table? How do you handle more complex queries? You write your complex query in SQL. It's great. Literally, it's great. Write your complex queries in SQL, please. It's fantastic. Great answer.

This next question is asking about TypeScript support. I saw that it generated types after you did that. Do you get autocomplete inside of your SQL queries? No, you get autocomplete if you use our little CRUD query helper. You get the types defined for your tables. If you run a query, you will need to cast the result to that specific object, essentially.

Query Understanding and Database Support

Short description:

The speaker discusses the difficulty of understanding complex queries and mentions the support for various SQL databases, including Microsoft SQL. They express willingness to implement support for Microsoft SQL for subscribers. The speaker also addresses the compatibility of the platform with serverless architectures, specifically Lambda, and mentions the option to deploy on the platformatic cloud.

The reason is we can't really look into what your query is doing, to be honest. Because if you have accomplished queries with multiple joins and so on, that does not look like any objects that you could have been using before. Yeah, it's a hard problem to solve.

And this last question is just asking about Microsoft SQL support. So what's the support for the various SQL databases? We support PostgreSQL, MariaDB, MySQL, and SQLite. Sure, we can support Microsoft SQL. If you're paying by a subscription, I'm happy to implement it for you next week. Hopefully that gives an answer of the reality of somebody building an open source company. So if you want to sponsor the work, I'm very happy to have a chat.

And this last one is, does this work with serverless? So something like Lambda, ColdStarts, what's the story? So, OK, two things. So the first one, it's, you can deploy platformmatic DB on top of Lambda. There is one, maybe. I don't know. Let's see if it did run. OK, no, it didn't run. Fun stuff. And so, yeah, it didn't run. It crashed. Come on, too many people using the cloud after we launched it. Good stuff. So it didn't work. The demo gods were not with me. And so the gist is, you can deploy it on Lambda, you can deploy on platformatic cloud, and that would be the trick. But, you know, it will work eventually. Awesome. Sorry.

All right. I'm going to give a big round of applause for Matteo. Thank you so much, Matteo. Thank you.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
Node Congress 2022Node Congress 2022
34 min
Out of the Box Node.js Diagnostics
In the early years of Node.js, diagnostics and debugging were considerable pain points. Modern versions of Node have improved considerably in these areas. Features like async stack traces, heap snapshots, and CPU profiling no longer require third party modules or modifications to application source code. This talk explores the various diagnostic features that have recently been built into Node.
You can check the slides for Colin's talk here. 
JSNation 2023JSNation 2023
22 min
ESM Loaders: Enhancing Module Loading in Node.js
Native ESM support for Node.js was a chance for the Node.js project to release official support for enhancing the module loading experience, to enable use cases such as on the fly transpilation, module stubbing, support for loading modules from HTTP, and monitoring.
While CommonJS has support for all this, it was never officially supported and was done by hacking into the Node.js runtime code. ESM has fixed all this. We will look at the architecture of ESM loading in Node.js, and discuss the loader API that supports enhancing it. We will also look into advanced features such as loader chaining and off thread execution.
JSNation Live 2021JSNation Live 2021
19 min
Multithreaded Logging with Pino
Almost every developer thinks that adding one more log line would not decrease the performance of their server... until logging becomes the biggest bottleneck for their systems! We created one of the fastest JSON loggers for Node.js: pino. One of our key decisions was to remove all "transport" to another process (or infrastructure): it reduced both CPU and memory consumption, removing any bottleneck from logging. However, this created friction and lowered the developer experience of using Pino and in-process transports is the most asked feature our user.In the upcoming version 7, we will solve this problem and increase throughput at the same time: we are introducing pino.transport() to start a worker thread that you can use to transfer your logs safely to other destinations, without sacrificing neither performance nor the developer experience.

Workshops on related topic

Remix Conf Europe 2022Remix Conf Europe 2022
195 min
How to Solve Real-World Problems with Remix
Featured Workshop
- Errors? How to render and log your server and client errorsa - When to return errors vs throwb - Setup logging service like Sentry, LogRocket, and Bugsnag- Forms? How to validate and handle multi-page formsa - Use zod to validate form data in your actionb - Step through multi-page forms without losing data- Stuck? How to patch bugs or missing features in Remix so you can move ona - Use patch-package to quickly fix your Remix installb - Show tool for managing multiple patches and cherry-pick open PRs- Users? How to handle multi-tenant apps with Prismaa - Determine tenant by host or by userb - Multiple database or single database/multiple schemasc - Ensures tenant data always separate from others
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Relational Database Modeling for GraphQL
In this workshop we'll dig deeper into data modeling. We'll start with a discussion about various database types and how they map to GraphQL. Once that groundwork is laid out, the focus will shift to specific types of databases and how to build data models that work best for GraphQL within various scenarios.
Table of contentsPart 1 - Hour 1      a. Relational Database Data Modeling      b. Comparing Relational and NoSQL Databases      c. GraphQL with the Database in mindPart 2 - Hour 2      a. Designing Relational Data Models      b. Relationship, Building MultijoinsTables      c. GraphQL & Relational Data Modeling Query Complexities
Prerequisites      a. Data modeling tool. The trainer will be using dbdiagram      b. Postgres, albeit no need to install this locally, as I'll be using a Postgres Dicker image, from Docker Hub for all examples      c. Hasura
Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
JSNation Live 2021JSNation Live 2021
156 min
Building a Hyper Fast Web Server with Deno
Deno 1.9 introduced a new web server API that takes advantage of Hyper, a fast and correct HTTP implementation for Rust. Using this API instead of the std/http implementation increases performance and provides support for HTTP2. In this workshop, learn how to create a web server utilizing Hyper under the hood and boost the performance for your web apps.
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow (https://platformatic.dev/). 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.