I Would Never Use an ORM

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.