💻 Croquet: Edge computing for Frontend (!) Developers

Hello everyone to the Cloudflare Developer Series 2021. I'm Vanessa Freudenberg of Croquet and I will be talking about edge computing for all developers today.

Originally, this slide was about front-end developers and we'll get to that.

But it's also for everyone. And I will also talk about Cloudflare's Durable Objects that were introduced today.

And maybe you've seen Greg's talk right before me, so you know all about that.

So edge computing for front-end developers.

That doesn't sound right, but let me show you. So here is a game.

This is live. It's a screen share on my machine and I can, oh, I already died. So it's a little multiplayer game and hopefully my co-workers will join me any second now.

So this is a game that's running as multiplayer. And I died again. That is implemented completely with client -side code.

And you can actually scan this QR code here.

Oh, there's someone else coming in. You can take your phone, scan the QR code, I will do that too.

And you can play it yourself.

And in the lower right, lower left of this screen on your phone, you will see a QR code that can let anyone else join that session.

So you can see my co-workers having fun now.

So join that with your phone, with your PC, with your laptop, and you can see that those are really quite well in sync.

And the remarkable thing is this is implemented completely without any server code.

I can show you the code if you click on the View Source button here on the lower right.

This is actually a single HTML file.

It has about 500 lines of code. And it starts with some HTML. We include the croquet library as a script tag.

And then we just start defining our game.

So our game has a few ships, a few asteroids, a few blasts when you shoot. And there's a subscription here for view join and view exit.

And when a view joins, then a ship gets created.

And when a view leaves, then a ship gets destroyed. Everything else, if you look through the whole code here, there really isn't a lot of multiplayer stuff in there.

So this is how a ship moves. This is how an asteroid moves.

This is what happens when an asteroid is hit. So everything else is just regular JavaScript code.

And what's happening is that this code actually gets executed inside of a little virtual machine in your browser.

So the code that you see there on this single HTML page with embedded JavaScript, that's all you need for writing these kind of things.

And that makes this pretty much as much fun as writing a single user app.

If you're writing a single user app, then you basically start with an idea, you code the client, and you deploy it to a web server.

That's it. That is a little oversimplified. You have to usually debug it a little bit too.

But that's basically what it is. You test locally, you deploy, done.

Now, what if you want to make a multiplayer game? There is no built-in API in the web that allows you to do that.

What you have to do is actually hire a backend developer, or maybe you're a full stack developer.

You still have to design a protocol.

You have to code the client and the server. And you have to define the communication between the client and the server.

Then you can deploy the client to a web server.

There are many, many hosting services. But then you also have to deploy the app server somewhere.

And we know that Cloudflare, for example, makes that really, really simple.

But the thing is, for every single app you write, for every single idea you have, you have to go through this whole process again.

You have to kind of make up a URL that your application can talk to.

You have to design that protocol. You have to write a lot of code that actually is completely irrelevant, or it's just complexity added on top of your actual program that you want to write.

With Croquet, you don't have to write a backend.

You don't have to build the protocol to talk from your app to your server.

You don't have to deploy anything to the server. You just write your client code and you debug it locally.

And so multi-user apps with Croquet, the experience is a lot like writing a single user app.

And that's what makes coding with Croquet fun.

It also allows to just explore some ideas where you can quickly whip up a prototype to try out multi-user stuff.

Multi-user itself is hard. The user interface design is hard. How things should interact when two people do something similar at the same time.

All of that takes enough brainpower that you don't want to worry about, oh, how does that look at the backend?

So that's where Croquet helps you. And the way we do that, let me make that a little bit larger.

So in a traditional multi-user development environment, your code is running on the server.

So you deploy stuff to the server. And then that server has to communicate with the client.

It has to actually send a lot of data to the client.

And for example, if you think of the asteroids demo I just showed you, the collision detection happens on the server.

The server really has to send all the updates of where the asteroids are going to the client at all the time.

That's a lot of data you have to send down the pipe from the server to the client.

Just not even thinking about, you don't want to just deploy one server.

You want to deploy many servers so that all of your users worldwide have a low latency, for example.

With Croquet, on the other hand, you deploy your application code to a little virtual computer that's inside of the client over here.

All those computers execute in sync, and they are being synchronized using the Croquet reflector network, which is a cloud service.

But you as a developer don't ever have to think about how that stuff actually works.

So you can focus on your application. Also, the data, for example, the collision data, where all the ships are, where all the asteroids are, that is already on the client.

To render that stuff, you can already just simply reach into that state and render it directly.

Here's a little illustration of how that works.

There is a reflector, and there are messages coming from the user to the reflector.

And the reflector just broadcasts those to all the virtual machines.

So every one of these little virtual computers computes in sync with every other of the clients.

And that way, we have a synchronized computation instead of having to distribute the results of the computation to the clients.

And maybe that sounds a little bit complicated, virtual machines, but it's not.

It's really just JavaScript.

So to show you that, yeah, this is really not that hard, let's look at a simple example.

This is our Hello World. And you can see here, I'm live on this one too.

Just like before, you can scan this little QR code here. I'm going to go ahead and do that with my phone.

So that I'm in the same session. Oh, there we go.

Open in Safari.

And now if you see here, the number on my phone screen is exactly the number as in the screen share up there on top.

And this app is so simple. There's only one action that I can do, which is tapping this reset button.

And now it starts from zero.

So this is the simplest kind of thing you could think of. And conveniently, this app shows its own source code right here.

So if you look at that, this is the complete definition for a virtual machine that's running inside of Croquet.

It has about a dozen lines of code without comments. And what it does, it's initializing the model.

So that n in this case here is zero. Then it's subscribing to an event to set the counter.

This event is coming from the outset somewhere.

And then it's starting a loop. And what this loop does, it's reading the current value of n adding 0.1 and doing the same thing 100 milliseconds in the future.

So this is how this little counter here on top actually counts. And we also define the setter for the value.

That's the handler for the event that we defined here in the init method.

And it's really just checking the value type, assigning it to this variable, and then publishing event that, okay, we did actually change the value.

That's all. This little piece of code we put into a virtual machine and run it on every client.

How do we display the results of that?

Well, that's another little class that's right below here. It's even shorter.

So we call that a view. The view is executed on each client individually. And what this view does is it's getting the model, which is the shared state.

And then it's calling changed, which directly reads the state of that model, in this case n, and assigns it to the output, the inner text.

So this is a DOM element. Output is a DOM element, our heading on the top.

And it assigns this value there. Also, it does subscribe to the counter changed event, which was published up here in the shared model.

So this is the counterpart to this. It's subscribing and re-rendering whatever needs to be re -rendered.

And then to actually interact with this shared computation, we do have an on-click handler.

This is, again, the button is a DOM element.

On click, we publish counter set zero. And what that does is it invokes the set handler.

And that's how the counter gets changed. The cool thing about this is this is all one single page.

So you can actually download this simple app to your laptop.

You can modify and align. For example, you could change, instead of adding 0.1, you can add 0.2.

Or you can make it count backwards. You save that file on your disk.

You double click it. You don't even have to have a web server.

You just double click it to launch it in your web browser. And it will be collaborative.

It will actually count. So if you then open the same URL in a different web browser on the same machine, those two will be in sync.

So you can talk, for example, from a session in Firefox to a session in Chrome.

Now, if you actually want to check the QR code and join that session from your phone, you actually have to put it up somewhere on a web server.

That could be on your own local machine.

It could be somewhere in the cloud. And that way, without deploying any server component, you just have a changed multiplayer app and you change the server code for it.

Because the server code is really embedded in the application itself.

So that way, it's really a fun experience to make that. For example, the asteroids clone that I showed you, I coded up in an afternoon.

And it's actually on GitHub.

Because I'm not a front-end developer. Well, I'm a full-stack developer, I would say, but I'm not really, really familiar with the front -end.

For example, one bug is if you tap, tap, tap, tap, tap too fast on your phone, it zooms in.

I have no idea how to fix that. So if someone wants to send me a pull request for that, I would be very happy.

But this is really a fun way to program.

It's not just fun. However, it actually can be used for serious applications.

To learn about this stuff, you should go to our documentation website.

It's croquet.io.com. And we have tutorials there. We have a Slack channel. You can ask us questions.

We have engineers that can work with your team to get them up to speed if they want to learn this stuff.

And to show you one little thing of what's actually possible with this technology, let me show you this one here.

So this is a multi-user Wide Wide World is what we call it, W3.

It's written on top of Croquet using a game development framework that's called WorldCore, which is actually open source.

It's on GitHub under croquet.io, croquet -worldcore.

And if you scan this QR code, you will be in your own little world.

And if I am in here, I can build something. Like I can build a tower here.

You can see that. I can also tear that tower down again.

So boom, there, it's gone. And you see 500 little AIs running around. Oh, that's 499.

I probably just killed one. They are running around in this session. And they are following the path.

I built that road earlier. But if I dig a hole here in that road, or maybe I'm building a wall, then they have to walk around that.

And they do.

They adaptively adjust to whatever we're doing in this world. Same thing is if I start digging over here, you can see that the water is going to flow inside of the blocks that I just deleted.

So all of this is a very, very dynamic simulation.

If this was running on a server, then the positions of all the 500 people that are running around and the level of the water and all the voxels would have to be streamed continuously down from the server to the client.

That's why nobody is doing that.

So this technology here, Croquet, allows you to build these really complex simulations.

Because right now when I'm not touching anything, the only information that's coming down from the server is the timing that keeps the synchronization going.

And I'm not sure if my coworkers are actually in this world here at the moment.

They might be. One fun thing that you can do if you are actually scanning the QR code in this simulation.

Let me do this one. Is that you can put the camera onto one of those little AI characters.

So now we are following what one of those of them are doing.

And here on my screen. I'm actually following exactly where it is.

Oh, yeah. Okay. This is my green screen.

So the green doesn't show up. But you can see that I'm really in sync with that.

And try that at home. So take your laptop and scan the QR code with your phone.

And then hold your phone up to your screen. You will see that it's very, very perfectly in sync.

So this is a demo of a more complex app.

Oh, I think now my coworkers are actually doing something.

Yeah. They restored the road. Great job. Great job, folks. So in a way, Croquet actually goes beyond the edge.

It's not just edge computing. We move the computation that application developers are programming from the cloud, not only to the edge, but actually onto the clients.

And as you know, clients are getting more and more capable these days.

My phone has a processor that's almost as fast as my laptop.

It's an enormous amount of power in there. So they are really capable of running that stuff locally.

And we do still get the speed of the edge, the events.

When you interact with the application, they get sent to the edge. They get bounced back using our reflector network.

So that the interaction is actually very, very fast.

And there are lots of other things that Croquet does for you, like there's an automatic snapshotting.

We have end-to-end security. This is a very important thing because the client data, the user data never actually leaves the client.

Whenever we have to communicate with the reflector, for example, or when we store the snapshots, these are end-to-end encrypted with the password that the server doesn't even know about.

And we are very excited to actually use Cloudflare for our backend.

So in 2019, we had just four reflector clusters. And our clusters work in routing the request from any client to the nearest cluster.

Then I built a custom multi -cluster ingress. And trust me, you don't want to do that if you don't have to.

It's basically finding the session ID in a global database and then routing the request to one of the clusters that are around in the world and finding the exact reflector for that session.

Because even if we have users that are joining, say, from Europe and from the US, they need to actually connect to the same reflector because the reflector is the one thing that puts a definite order on timestamp so that all the virtual machines get the exact same events in the exact same order with the exact same timestamp.

That's how we guarantee the bit identical execution of all our virtual machines in a session.

That stuff is hard.

And there's a lot of custom infrastructure that you have to build.

And we have to run those servers all the time, even if there is no user in that region, because there might be a connection that's coming in there.

We would love to be able to deploy that on serverless, but it's impossible.

Why? Because with serverless, the connection from the client just reaches a random instance of your serverless function.

So with that, there is no single point where all the connections actually come together.

Enter durable objects at Cloudflare.

So durable objects, as Greg just mentioned, have a lot of features. But the one that is important for us at Croquet is that durable objects have an ID and they are addressable by that ID.

So when we have a session ID and our client connects to a random worker that's happening here, this is a random worker, this is also a random worker, then those random workers will take the session ID and look for the durable object with that ID and just forward the request there.

Cloudflare takes care of ensuring that there is exactly one durable object at the time that it gets initialized correctly.

And if something happens to that durable object, it gets destroyed and a new one reinstated in memory.

Basically, it comes up from the state.

So this basically replaces the whole infrastructure that I had to build on our current production systems.

So with durable objects, it's actually possible to build this kind of really interactive simulation where all the connections to a session are coming together in a single point.

And you know that Cloudflare has a lot of locations around the world.

So that's how we get a lower latency for more of our users.

And also, we only have to pay for the locations where actually there are connections at that time.

We don't have to pay for all the potential customers that could be there.

So that's an advantage that serverless always has. But now with the durable objects, we can use it for our backend.

And that's very exciting to us.

So if you want to learn more, come to croquet.io. We have our documentation there.

We actually have more examples like industrial applications, media applications, mobile applications, lots of interesting ideas.

I am Vanessa Freudenberg.

You can reach me on Twitter at CodeFrau. And thank you so much for our talk.

And thank you to Cloudflare for inviting me today and talk about this experience.

Thank you.