This welcome Nick, who will be talking about teleportal, a real-time collaborative editing
framework.
That's welcome here.
All right, thank you.
Yeah, so Teleportal was a side project that I've been working on for about a year now.
It's a real-time collaborative editing framework.
It's based on YJS, and it enables experiences like Google Docs, Notion, Figma, that you
multiple people can be editing the same document in real-time.
I don't need to explain CRDT, so this audience, you've seen several presentations on.
So this is an implementation of a sync server framework.
So I would really like to stress that this is not a sync server itself.
It's actually a framework, so this is tools that you can build into your application and
enable your application to use all of the properties that a CRDT has.
So this is a little bit of an overview of the architecture of how one of these sync server
works.
You have a number of clients that all interrupt with the server, over some sort of a protocol
using these transports.
You can use things like web sockets.
You can use HTTP and SSE connections.
The server itself is the main authority.
This is not meant to be like a peer-to-peer set up.
It's meant to be more the real-time collaborative editing sort of thing.
So you can have the server be able to enforce the permissions, things like rate limiting
at any sort of these cross document concerns.
Whereas the server itself is meant to just propagate the updates back and forth and shuffle
those between the clients and real-time.
So I've also focused on trying to build this in a way that scales with existing architectures
for applications.
For example, a lot of sync server implementations require you to have a separate server
that needs to have a separate load-down server for managing that all connections go
to the same server.
I wanted this to be a horizontally-scalable system so you can have pubs up connections where
the server can propagate updates between each other so you don't need to have the clients
on the same exact server.
They can shuffle updates between servers.
So Teleportal as a whole is a lot of things.
There's a lot of parts and components to this.
It's meant to be a library of all of these components so you can pick and choose what
exactly you want out of the server.
So you pretty much everything is based off of the actual protocol.
How it actually describes the actual message format and updates.
But everything else is optional.
You can choose whatever it is and I try to build the entire thing to be maximally optional.
So what that means is I don't care what storage solution you use.
You can use relational database, you can use KV, you can use whatever it is you like.
You can run this over any transport that implements a bidirectional protocol.
So for example what I've actually done is it'll always try to do a web socket connection
just because that's very reliable for the web.
But if it's not able to establish a web socket connection, what you can do is it will,
like for example, like a corporate network, there's a lot of rules and stuff about web
sockets that can be awkward.
What it will do instead is just fall back to another connection so it'll do an SSE.
So it will read the updates from the server as a stream of updates and then if the client
actually needs to send an update, the client can then do HDV post.
So because that's a bidirectional communication, it works for teleportal.
It runs on any Node.js, sorry JavaScript runtime, it's all built on JavaScript primitives.
So it's able to run on any sort of runtime so it's built to be a part of your application.
It's not meant to be this separate server that you then have to integrate the API with
and they control how you do off.
The whole point is that you can reuse your all system and define what that means in your application.
And reusing your existing logic rather than having to integrate and be restricted by their
source of APIs.
One really cool thing that I built that I just want to shout out is that I built a developer
tool so you can actually inspect all the messages that happen over the connection so you
can kind of like make it yjs a little bit more approachable.
Not everyone can just read binary so that that's helpful.
And yeah, there's a number of other things as an RPC system for actually like
shopping messages around, yeah, and I'm out of time.
But yeah, thank you very much, Nick, we're going to know where to go.