APIs are Evolving. Again.

Hi everyone, I'm Matteo. Hi everyone, I'm Luca. Welcome to JS Nation, and we are so happy to be here. After 6 years together. After 6 years in the same locations, whatever, different conferences, different time, it's fantastic.

So before we get started, for the sake of brevity, you know we only have 20 minutes, we have abbreviated a few steps of the story, so if it's not perfect, not correct, please let us know, but it's fine, okay?

So I wanted to start everything by telling you that technology is actually a spiral. Every generation of technology, you know, implementation changes all the time, you know. A few years back we were coding in COBOL, now we are coding in Typescript, or Zig, or Rust, or whatever. But most of the time, foundational ideas do not. They actually came back and came back and came back. You know MVC was invented by Smalltalk a few years back, right? Like COBOL, also. COBOL.

And, well, we were talking about COBOL, and the biggest, our good friend, the monolith. How many of you love coding in very nice monoliths for your app? Yay! Don't be shy, don't be shy. Okay, it's fine. And so, yeah, the monolith. And, look, once upon a time in the world of APIs, there was Java. And this is JS Nation, it's a JavaScript conference. But, you know, not the coffee bean or the island. I don't know, did you know? You know that in Amsterdam we have Java Island, it's just over there. But that's not where they created Java, by the way. Okay. So, thank you. Everything started with coding applications, right, in Java. We all know how it started, with your beautiful IDE, you press the magic build or play button, and you create a war file. Well, yeah, at the end of the day it's just a tarball. And then you SSH copy or you just drag and drop, if you're on Windows, and put it in your application server, right? That's how everything started. And Java is a phenomenal technology that changed massively the way we look at enterprise applications, but it's a little bit slow, mechanical, it requires a lot of maintenance, but it can take you from A to B. No problem. We already all have been there, right? And Java started building the world of APIs.

But at the time they were called web services, and we all have been through the beautiful phase of having your Weasel file. How many of you coded a Weasel in your lifetime? Many grippears are here.

Okay, a few of you. Yeah, you know, it's called the WS star, and I don't know, when we were at uni we mocked this and called it that star. So that's why there is the desktop behind. Okay, sorry, I didn't explain this, because people told me that was not clear.

And we all built, also then later I know the SOAP parsing, because everything was XML, right? And on the UI side, the equation was a little bit different. Everything was built server side, and server side render, and we used tomcat. The model that we implemented was a model that was very monolithic, like Matteo said, because we had a single unit of deployment, but it was multi-threaded and synchronous. So when I was, a few years back, I was studying my PhD, and we, and I took a look at this fantastic thesis. There was the thesis of Roy Fielding, which was one of the pioneers of what we call the web. He theorized this little thing called the Representational State Transfer, or AKA REST. It's great, okay? Also, about that time, this was the year 2000, about the time 2001 and so on, we started to see another nice invention in the world. JSON.

How many of you use JSON today? You're raising it up. I don't see enough hands up. Okay, you're using XML at the bottom of the state. I know you're using XML. The die-hard. The die-hard. But, back in 2004, we had another great invention in the world of web, which was Ruby on Rails. I don't know how many of you were stunned by when Rails came out and it was able, oh, I can actually build a website or a fantastic thing in 20 minutes, like it was stunning. And we did fantastic HTML templates with ERB and another nice technology called PrototypeJS, which was a blast. And it's scriptaculous, whatever. I don't know how many of you were there at this time. But it's great tech. And that, the developer experience of building APIs and websites, was all about the data, so you started generating your migration for your database. Then these things were generated automatically, and more or less you get a nice scaffolding of HTML, your controller, ERB files, and all a nice CRUD REST API. All of this was like, I don't know, one comment away. Where did we lose the capability to generate a full website with a nice API for it in one comment? I don't know how much time it takes you to do that today, but it's totally not what REST does.

However, Ruby on Rails, especially my experience, was a fantastic tech for moving very fast from A to B, and actually slow from B to C. You wanted to reach C, but if you go to on the Rails, oh, super high speed, then you need to break off the Rails a little bit. Then you started going a little bit slower. You need to derail. Yeah, well, a little bit.

So, at the time, we also got the best developer experience ever for deploying stuff. And again, stunned. Before that, it was super hard. When Rokon came out and you could actually git push to a repo, and you could deploy your stuff. How many of you git push to deploy today? Okay. You should thank these guys. And you could deploy to any end, to be honest, but it's amazing. It was amazing developer experience, and probably still the best that you can get. Everybody wanted to copy this.

At the core of this stuff, and while before, with Java and those other things, we were doing these big application servers. Now the cloud started doing the uplift of running our services, and we started to have this nice reverse proxy in place, and these nice profiles to define what to see. A lot of you don't know that, but don't worry. And we have multiple processes for each machine running all this stuff. It's very simple architecture, but actually very effective. Still, we will be doing synchronous programming. What does it mean? It receives a request, it processes that request before doing the next one.

However, this is the JS Nation conference, and any application that can be written in JavaScript will eventually be written in JavaScript. So thank you, Jeff, and this was essentially the time where Node came to be. And 2009, Node.js started changing the way we build stuff for the web. When I saw the first Node.js demo, I said, no, this is the tech for the next two decades, at least, and I jumped on that bandwagon, even though I knew nothing about JavaScript. I'm a mechanical engineer in my trade. I knew nothing about JavaScript. And C++. That's a different story. transportation mechanism, Node.js is a little SUV that you can move from A to C.

You don't go super fast. You can use Node.js to actually do very custom things and move fast while you are doing it. There are, I don't know, millions of modules on MPM now. A lot of vulnerabilities, probably, but that's a different topic. And we were told at the time that because Node.js has this massive event loop, we can be single-threaded. And, you know, run many, many requests per second in parallel on a given process. Wow! I don't know. It's super fantastic, right? And, so... Bam, bam! So, what did we do? And bam! We broke the monolith. Yeah! Finally, the monolith was broken in pieces and we, you know, we are all familiar with the concept of divide and conquer, right? We all went through that beautiful loop. And that was the time that we started revolutionizing the world of backend, breaking the monolith with a single application into microservices.

And this journey took us basically to encounter technologies like Docker and more recently the service mesh, right? I think you're all familiar with both concepts. And those both concepts, actually, they kind of led to a false promise. That it works on my machine. And I think you're all familiar with the meme, right? That it works on my machine, then we will ship your machine, right? Because let's be honest. Docker doesn't work on your machine and on the cloud the same way, right? It's a great marketing exercise, but this promise actually started to trigger many more thoughts and ideas on how this space could be evolved.

In the meanwhile, the frontend was changing. You all know what I'm going to, right? We started decoupling. So now you have the frontend and the business logic, the single page application started to grow. Mobile grew massively. And so this journey took us from having this monolithic application to a distributed system, but most likely to the transformation to REST APIs.

And most of the time what happened in reality is that you just render what is in your database from the server side. In this journey, clearly we are all familiar with probably the biggest revolution and player that Vercel and NeXT put in place, because they actually brought that experience that was lost in this journey of the backend to the frontend. They said we can just have one git push, deploy your application, and you can go from zero to production in no time. But what about the backend developers? I was a backend developer, Matteo was a backend developer, we all have been there, and we said where the hell did he go, this journey, this experience? And so we were all in the midst of being transformed into a distributor system.

And as a distributor system engineer and as many of you, I know exactly that a distributor system is extremely complicated because coordination is a huge challenge. Do you agree with that? Coordination is everything, right? And so we saw the journey being taken from the operator side. So we saw tools like the Service Mesh. I can put a sidecar in your application and give you all the functionalities. Like, for example, distributor tracing because it's pretty miserable when you have a hundred microservices and somebody calls you at 2 AM in the night and says something is broken and you need to go and dig into a hundred microservices. And we saw the raise and fall of registries. All operators tools, but where are the developers? Where are the enablers of that? Because they're still missing a tool to allow developers to build, manage and scale microservices painless. And how can we actually bring this joy back to API development? Yeah.

Well, you know... At some point last year, we decided that we were going to fund a company. So enter Platformatic. And look, we are helping developers getting rid of all the undifferentiating, the heavy lifting of building Node.js applications. And what we want to reach is the same speed that I experienced a few years back when I first started Rails, with the flexibility of Node.js at the same time. So, this is not working anymore for some reason. We don't produce batteries. That's why the problem. Yeah. Sorry. It went through. Okay. Good.

Nice. Okay. Sorry. Sorry about it. Okay. So, a little bit of Mischa. And, sorry. Why this is not? Can you? Okay. Sorry. You keep... It exploded. Okay. Good. Okay.

So, it's all open source. And, it's all open source. And, it stands on the shoulder of giants. It's built on top of a framework called Fastify. So, I don't know. Check it out. I wrote the thing a few years back. And, another thing called Node. So, also, it's composed of a few things. And, the first one is platformatic service. So, basically, it bundles all the things you need to build APIs today. Open API, GraphQL support, REST. But it also has custom metrics, logs. It protects you from event loop, you know, mesh apps, which is very nice. And, it does TypeScript and AutoModule reloading support, as well as L checks. We also built a thing called PlatformaticDB, which is fantastic to build APIs really, really fast.

Because if you just create your migration, and after you have created your migration, you could get it done and create your APIs. You also, it support multiple database, and so on and so forth. It's actually very easy to use and you should give it a shot.

Now, you know, all of these is for building monoliths, right? You have built one thing, and a service or a PlatformaticDB, those are just monoliths. And now we are introducing something new. We are introducing the Composer. So you want to, like, we were asking a lot of devs, and all of them told us, well, we really like REST. And we started saying, oh, okay, but how can we combine multiple REST services very easily? Well, the Composer allows you to combine multiple APIs built on REST and OpenAPI and expose them as a single one endpoint, more or less, getting rid of the backend, frontend pattern. It also handle a lot of nice things that, you know, makes this kind of stuff very nasty to do, and we just take care and do it for you, so no problem. It just works out of the box. Yep.

We are also shipping a new technology called Platformatic Runtime. And it's... Yeah, this is... It's not correct. Whatever. It's not correct. Okay. So anyway, the Platformatic Runtime is a new technology that enables you to run multiple frontend...multiple application within the same Node.js Runtime. It's part of the new Platformatic Cloud, and it creates things...it enables you to run all of them together. More on that later. A deja vu. A deja vu. And because we know that managing distributed systems can be very painful, we actually decided to kind of take a different direction than a service mesh, and we said, we can actually create a system, a graph, on top of all this set of microservices, and basically create a generative taxonomy system that allows to kind of, like, do multiple and interesting things. So we could have dependency conflict resolution, or basically have a topological sort order of services, and are all things that more or less we actually have been through building distributed system and microservices. And so when I said it is a deja vu, it feels like we are taking a step back, right? We started this whole conversation with Java and the deployment to an application server, and it feels like we are going to where Matteo was leading us in the beginning, to a circle. And we actually noticed in this journey that actually there was an opportunity to evolve what was standardized and more kind of like the status quo for building Node.js microservices. But we wanted to do it in a modern manner, in a modern architecture. So... It's not streaming to the...

So... Okay. And so we actually decided to transform microservices into nanoservices. And this is actually thanks to what Matteo was just saying about the run time. We are actually able to put together a multitude of services and deploy them as a single unit inside of the run time and then shift the run time straight into any machine. And this run time, thanks to the taxonomy and all the other things that we just saw, is actually creating a virtual mesh between both systems.

So it's an overlay, but it's not an overlay with a sidecar. So one of the key features of the platformatic run time is that the services are not automatically accessible over the Internet. We are essentially interconnecting them automatically by using a few technologies that we have developed across the years and it's also compatible with the standard fetch API, so you could just fetch and instead of going through a full route of HTTP, everything is actually routed within the same process, kind of on a virtual mesh on the same process itself. It's actually pretty cool.

So it's great, right? And what do you want to say, Luca? That finally it runs on my machine, your machine, our cloud or your cloud, so finally we can get it running everywhere. So you know, today we are actually launching our cloud and you could deploy all of this stuff on Platformatic.cloud. And from zero for free, if you want just basic stuff, or if you need a domain name or some other stuff like that, for $99. It's dollar, not euro, so you know, if you care about those things. And the things that we actually thought was more fair for developers, was actually to charge what really matters. That is the compute power. So we kind of like took a look back on successful stories, like where Mateo took us with Roku and said these developers should be enabled to collaborate and work together on building those applications and we should only actually charge per unit of compute.

Oh, but didn't we say that everything that I talked about is just open source? Well, we have a surprise. We are going to do a release on stage. So happy? Here we go. So are you ready? Ready? Yeah. Shall we do it? Shall we do it? Let's open it. Let's open it. Are you ready, Luca? Go, press it! AAAAHHHHHHHHH!!! So, cool. It's all available now. Check us out at platformatic.dev. It's been released as we speak. The GitHub actions are doing its job. So give it the time to get up, not to come up. So let's get to it.

It's all available now. Check us out at platformatic.dev. It's been released as we speak. The GitHub actions are doing its job. So give it the time to get up, not to come up. So let's get to it.

It's going live. It's going live. It's going live. If you're not getting up, it's okay. We'll make sure we get you up. It's going live. If you're not getting up, it's okay. We'll make sure we get you up. We'll make sure that you're up. As we speak, the GitHub actions are doing its job. So give it the time to get up, not to crash and to deploy our stuff because we really deployed it right now. Totally live stuff so, you know, could have failed but big time. So we'll see. Ultimate live coding. Doing a release of, I don't know, a year work on stage. With a nuclear launch. Of course. Briefcase. Cool. Thanks, everyone. Thank you. And don't forget to look and check our website.

I'm going to ask you to join me at the Q&A corner. Okay.

Fantastic. Where I'm going to put all of my devices. All right. So because we have a couple of questions from the audience. Love it. All right. So if you have some questions for Luca and Matteo, please keep them coming. You can also stand in front of the block. I'm also tall. Yeah, living in the Netherlands didn't help my height. That's all right.

So let's look at a couple of questions. So there is the question if it is really free and open source and what is the catch. 100% free and open source. There's no catch. No catch. Perfect. That's what we want to hear. What are the benefits of having such granularity of nano services over the conventional microservices? The benefit is that you can very quickly like you if you're using traditional microservice you need essentially to deal with deploying each one of them. And therefore you need to if you're doing microservice correctly you are managing them as independent deployment unit. And therefore there's a lot of terraform and CI environment for deploying each one of them. A system like ours is actually very straightforward and because it's nano inside the same process you don't have to deal with it you can just you know the deploy once and you have one single deployment pipeline.

Perfect, we also had a question about you talked a lot about developer experience. What about UX? What about? User experience. User experience. We do APIs folks okay I am a back-end engineer. So if the co-founders are a back-end engineers we also have a fantastic front-end developer and designer to do our job to do that so yeah that's probably the answer. Probably interesting to know that we actually approach both sides so you have a more back-end engineer CLI experience and you also can approach the same thing to our UI and the UI that you see on your local machine is what you see on our cloud on your cloud. We just want to have a seamless experience. One of the greatest things for the front-end devs is that we offer an automatic client generation so that you could actually use consumable platformatic APIs from your React or Vue front-end very very easily.

All right we have a question where does contract testing come into play? Contract testing. So this is actually an interesting one. You will need to... May I say something? Yeah, go on. You will probably need to wait for our next launch, sorry. Yeah.

Is the next release going to be as spectacular though? Oh of course, we're keeping the foosball. That's pretty good.

Another question, are there plans for making platformatic be integrated into SST or similar projects? We clearly want to kind of like partner and engage with the whole ecosystem so we have a roadmap of different type of integrations. We are taking care in the beginning to create the right foundations for us to stack upon and build more functionalities but we don't know exactly when we are going to have it done.

All right, here's a fun question. What was the most interesting challenge during the development of this? There's no skipping questions. No, this is actually, this is very hard. So how many of you know how hard it is to do hot reloading in JavaScript and TypeScript and so on? It's an enormously hard problem, okay? I have been working for two years and a half to crack this problem and I'm happy that the solution we came up with actually works more or less. There are a few crashes, but it's pretty good. And we are keeping investing even more on hot reloading. I even have done a contribution to Node.js core to improve on that. So I'll probably do a talk on it in fall because right now it still hasn't landed. So finger crossed.

Very cool. We have two very similar questions, namely, is there a self-hosted solution and can I host my own platformatic instance? Yeah. If you go on our website, we are opening our beta program to run platformatic on your own cloud and, yeah, it's going to be mostly dedicated to enterprise installation, but clearly, because it's beta, you can... Oh, but, sorry, maybe the question was something way more simpler than that, Luca. You can take npm install platformatic and it will just work. Oh, by the way, I didn't say this. I'm doing a talk on all this stuff later this afternoon. So if you want to join my session, that will be... There's a demo. There is a demo. You can see it's really working.

It actually works. Okay. So people need to catch that demo. Yeah. Done. All right. Perfect. Done. Done?

Okay. Oh, I have to answer that. Does platformatic offer any sort of websocket support for realtime data? The answer is yes. Now. Now. Yes. Yay! Thank you very much. Thank you.