JavaScript Took Over the Server, Its Time It Takes Over the Database Too

♪♪ ♪♪ ♪♪ Hi, I'm Ben. I'm the CEO of Freestyle. We're building a new JavaScript runtime called Cloud State that lets you write your whole application in TypeScript.

Now a lot of you might be thinking you already write your whole application in TypeScript. But that's not true. You might write your front-end in TypeScript and you might write your back-end in TypeScript, but then you're using Superbase TypeScript to connect out to a SQL database. And then when you're connecting your back-end and your front-end, you're using a REST, HTTP, GraphQL, any of these things that are outside of JavaScript.

We believe that these layers cause the problem and friction in TypeScript teams. And when you bring them into TypeScript natively, your teams can run much more efficiently. Here's how we do that. We created a new TypeScript engine that lets you write your code as regular TypeScript and then it runs in the database. So what that means is that you could have a counter. And by just writing this counter, this data isn't stored in the heap. It's actually offloaded behind the scenes so that it's now persistent. Your TypeScript team isn't writing a Superbase translation layer. It's not writing SQL. Your team is now writing JavaScript, regular old JavaScript, and that's how it works.

When you use it in freestyle, you actually go even further. Not only do we let you write this counter in JavaScript and have it be persisted on your back-end, but you can actually just call your back-end functions from your front-end without any issues.

So let's take a look at a slightly more complex example. This is how you build a to-do list in TypeScript with freestyle. Now, the first part of the to-do list is at cloud state. That's what tells us that this is persistent. So you can see we take a regular to-do list class, give it an ID, and mark it as at cloud state.

And then, we'll skip this for now. We're going to go return items.info, and that is running on the to-do item class, which also has an ID and has a regular function, toItems.info. And what you can see here if I zoom out is we have a 53-line file that exists in isolation with pretty much just regular TypeScript. You're taking a to-do list class. This is how you could write a to-do list regularly. And with a single line at cloud state, this class has now gone from being an in-memory thing that you can run on the front end to not just running in your back end, but also having the data persisted. So this can actually be deployed to production now without needing a SQL database. This is the database.

So, how do you connect to this from the front end? Well, what you can do is on the front end, you write use cloud of the to-do list. And now, I can do to-do list dot, and you can see the functions we wrote are right there. Add item with all of the strong types, all of the TypeScript, it's right there.

This is the database. So, how do you connect to this from the front end? Well, what you can do is on the front end, you write use cloud of the to-do list. And now, I can do to-do list dot, and you can see the functions we wrote are right there. Add item with all of the strong types, all of the TypeScript, it's right there.

And you know what, I want to know what getItems does. So, I'm going to command click it, and now I'm right back on the class. Let's get me starting with a prefix. And let's see, when I go back to the front end, I can now just call dot starting with, and it'll tell me, oh, what does it want? It wants a prefix. So I put a prefix, and then it's happy. So you have full strong types throughout.

Now, what you're seeing here is that we realized even that was too hard, because you have to keep it in sync, you have to do a loading, a suspense, all of that. So we actually created something inspired by TAM stack. Instead of use query, you can write use cloud query, and this will automatically handle the loading, the sync, all of that. And it doesn't need a refetch, because if you may remember at the start, we had to invalidate.

And what invalidate does is it's server-side refetch. So, in the to-do list, you can see that we have a listed to-do items that we're getting. And whenever like to-do items data can be consumed, just as regular, like the type. And what happens is on the backend here, we can say, hey, whenever you add an item, anything that relies on this to-do list's get items, you should refetch it. So it runs it and it keeps it in sync. So that's this app, let me run it. Freestyle Dev. That's going to boot up the dev server, all that, do all the compilation. And now we're here. We have a completely persistent and live app ready to go right here. And you can see the data is not stored on the web page, it's stored persistently in the database.

So, we can actually take this further. And now, with two commands, freestyle build. That's going to build this app, prepare it for production. And then freestyle deploy. It's going to ask me what I want to name this.

And I'm going to say demo for talk. And it's going to take its time creating the project. Takes its time. And then it'll eventually deploy this product to production. Not just your stateful web app. It's not just doing the web hosting that everybody does. But importantly, this is now deploying the data persistence infrastructure that you need to build real functionality.

Now, how is this possible? Let's see, demo for talk. We now have a real persistent app. And it's loading. Oh, there we are. And you can see, hello, welcome. This is the app. I guess it's now booted up. And you can see it's shared, it's live, all of that. This is cool. I want to emphasize the real difference between this app and every other app you've ever seen. This app is written in pure TypeScript. There is no ORM, there is no configure to SQL. This is running like JavaScript on your front end, followed by Deno on your back end, followed by CloudState for your persistence. And all of that without ever leaving TypeScript. So I want to show you generally how this works. So the CloudState runtime is a merging of V8, Deno core, and a database engine we designed ourselves.

Now, why did we need a custom database engine? Because if you tried to do this with a document store, you would start to get super duper slow. Because do you store a whole object? Do you store part of an object? Where do you draw the line in this object store? And we know because we tried that. So what we actually did is we designed a object store that doesn't just store objects the way traditional NoSQL does. But it actually breaks them down into their individual fields. So if you're trying to access an object that has users and just that user's first name, you're not getting the whole object. You're not getting the whole user. You're actually only getting their first name.

And similarly, when you're writing back to a database, you're not writing back the whole user. You're not writing back the whole object. You're just rewriting their name. And that's how this is really possible. That we merged into the runtime, everything we need to be able to do these fine grained transactions to allow this to really work in production.

So I want to show you where this goes and what this enables. More than any one improvement that this does, this enables something kind of weird. I love JavaScript packages. JavaScript packages are the greatest thing about JavaScript. NPM is my angel and all of my projects rely on it. But there's a thing that's missing. I love ShadCM, for example. I love Bootstrap and I love all these utility packages. But every single package I've ever used is a utility. It's either a wrapper for somebody else's API, for example, Superbase, which wraps the connection to their Docker containers, or Clerc, which connects out to Clerc or it's ShadCM. It's something that gives me components, it gives me helpers, it gives me localization or something. But it never has been able to give you a whole feature. Why is that? Because the feature is the data. You could argue that any feature boils down to displaying, manipulating and moving data. And the fact is, there's no way to do that in a package today.

If I'm building a React component, where am I going to send this data to? Am I fetching out to somewhere random? If I am building the back end side of this, where do I store that data? And even then, how do I connect these things? You could try it in Next, but you wouldn't be able to make the API routes because it's all file system-based routing. But the cool thing about CloudState is that this file works in isolation. I can take this to-do list back end, copy and paste it, put it into a package, and then it works. So you can now share your back end, your data infrastructure with other people. But it doesn't actually stop there. Because you can see when we use it on the front end in the React components, we're not referencing a web server, we're not referencing an endpoint. We're referencing the class and the class's ID, and that can be stored in a package too. So any feature you build in CloudState can actually be shared as a package.

Let me show you an example of one of the first ones we've released. Freestyle chat.

Building a chat UI is hard. There's a lot that goes into it. You need a REST API for the first load, you need the socket to keep it in sync, you need the data persistence, you need multiple user identification, and then the UI, oh my God. It takes a lot, which is why there's a bunch of third-party vendors that will sell you chat, but then they own your data, they own the code, and you can't ever really move off of them.

Freestyle chat is completely open source. All of the source code for what I'm about to show you is completely open source. Now, what you can do is run npm install freestyle-chat, import the back end, just importing it, not calling out to some other client, not setting up anything, just importing the back end, then importing the front-end React components like you're used to, and then you'll be given a prebuilt live chat running in your app, fully configurable, fully rewritable, fully forkable, your data in your application that you own for free.

This is what Freestyle enables more than anything else. That right now, every package you use, it's great, but all it is is a utility. But when you build on Freestyle, you can share anything, and this is where we're going to be going in the near future.

In closing, we believe that Cloud State has the potential to do to databases what Node.js did to servers. Like how JavaScript has taken over the rest of a stack, we believe it can take over the data stack. And when it does that, it's going to make development better for JavaScript people everywhere. We'd love it if you could give our repo a star. That helps a lot. I am Ben. Please reach out if this is interesting. Thank you.