WEBVTT 00:00.000 --> 00:10.400 This welcome Nick, who will be talking about teleportal, a real-time collaborative editing 00:10.400 --> 00:11.400 framework. 00:11.400 --> 00:12.400 That's welcome here. 00:12.400 --> 00:18.120 All right, thank you. 00:18.120 --> 00:24.200 Yeah, so Teleportal was a side project that I've been working on for about a year now. 00:24.200 --> 00:26.560 It's a real-time collaborative editing framework. 00:26.560 --> 00:33.560 It's based on YJS, and it enables experiences like Google Docs, Notion, Figma, that you 00:33.560 --> 00:35.960 multiple people can be editing the same document in real-time. 00:35.960 --> 00:40.440 I don't need to explain CRDT, so this audience, you've seen several presentations on. 00:40.440 --> 00:44.320 So this is an implementation of a sync server framework. 00:44.320 --> 00:48.440 So I would really like to stress that this is not a sync server itself. 00:48.440 --> 00:55.360 It's actually a framework, so this is tools that you can build into your application and 00:55.360 --> 01:01.640 enable your application to use all of the properties that a CRDT has. 01:01.640 --> 01:06.360 So this is a little bit of an overview of the architecture of how one of these sync server 01:06.360 --> 01:07.360 works. 01:07.360 --> 01:14.560 You have a number of clients that all interrupt with the server, over some sort of a protocol 01:14.560 --> 01:16.120 using these transports. 01:16.120 --> 01:18.360 You can use things like web sockets. 01:18.360 --> 01:23.120 You can use HTTP and SSE connections. 01:23.160 --> 01:26.800 The server itself is the main authority. 01:26.800 --> 01:30.560 This is not meant to be like a peer-to-peer set up. 01:30.560 --> 01:35.760 It's meant to be more the real-time collaborative editing sort of thing. 01:35.760 --> 01:42.760 So you can have the server be able to enforce the permissions, things like rate limiting 01:42.760 --> 01:46.760 at any sort of these cross document concerns. 01:46.760 --> 01:50.840 Whereas the server itself is meant to just propagate the updates back and forth and shuffle 01:50.880 --> 01:53.600 those between the clients and real-time. 01:53.600 --> 02:03.320 So I've also focused on trying to build this in a way that scales with existing architectures 02:03.320 --> 02:04.320 for applications. 02:04.320 --> 02:11.480 For example, a lot of sync server implementations require you to have a separate server 02:11.480 --> 02:16.360 that needs to have a separate load-down server for managing that all connections go 02:16.360 --> 02:18.040 to the same server. 02:18.040 --> 02:24.480 I wanted this to be a horizontally-scalable system so you can have pubs up connections where 02:24.480 --> 02:29.920 the server can propagate updates between each other so you don't need to have the clients 02:29.920 --> 02:31.240 on the same exact server. 02:31.240 --> 02:38.200 They can shuffle updates between servers. 02:38.200 --> 02:41.320 So Teleportal as a whole is a lot of things. 02:41.320 --> 02:45.920 There's a lot of parts and components to this. 02:45.960 --> 02:51.840 It's meant to be a library of all of these components so you can pick and choose what 02:51.840 --> 02:54.960 exactly you want out of the server. 02:54.960 --> 02:58.920 So you pretty much everything is based off of the actual protocol. 02:58.920 --> 03:06.840 How it actually describes the actual message format and updates. 03:06.840 --> 03:09.920 But everything else is optional. 03:09.920 --> 03:15.480 You can choose whatever it is and I try to build the entire thing to be maximally optional. 03:15.480 --> 03:18.680 So what that means is I don't care what storage solution you use. 03:18.680 --> 03:24.360 You can use relational database, you can use KV, you can use whatever it is you like. 03:24.360 --> 03:29.320 You can run this over any transport that implements a bidirectional protocol. 03:29.320 --> 03:34.880 So for example what I've actually done is it'll always try to do a web socket connection 03:34.880 --> 03:38.000 just because that's very reliable for the web. 03:38.000 --> 03:43.120 But if it's not able to establish a web socket connection, what you can do is it will, 03:43.120 --> 03:46.720 like for example, like a corporate network, there's a lot of rules and stuff about web 03:46.720 --> 03:48.880 sockets that can be awkward. 03:48.880 --> 03:54.640 What it will do instead is just fall back to another connection so it'll do an SSE. 03:54.640 --> 04:00.520 So it will read the updates from the server as a stream of updates and then if the client 04:00.520 --> 04:06.000 actually needs to send an update, the client can then do HDV post. 04:06.000 --> 04:11.720 So because that's a bidirectional communication, it works for teleportal. 04:11.720 --> 04:20.680 It runs on any Node.js, sorry JavaScript runtime, it's all built on JavaScript primitives. 04:20.680 --> 04:26.240 So it's able to run on any sort of runtime so it's built to be a part of your application. 04:26.240 --> 04:30.240 It's not meant to be this separate server that you then have to integrate the API with 04:30.240 --> 04:35.520 and they control how you do off. 04:35.520 --> 04:41.680 The whole point is that you can reuse your all system and define what that means in your application. 04:41.680 --> 04:48.880 And reusing your existing logic rather than having to integrate and be restricted by their 04:48.880 --> 04:52.400 source of APIs. 04:52.400 --> 04:56.400 One really cool thing that I built that I just want to shout out is that I built a developer 04:56.400 --> 05:00.200 tool so you can actually inspect all the messages that happen over the connection so you 05:00.200 --> 05:05.920 can kind of like make it yjs a little bit more approachable. 05:05.920 --> 05:11.360 Not everyone can just read binary so that that's helpful. 05:11.680 --> 05:17.520 And yeah, there's a number of other things as an RPC system for actually like 05:17.520 --> 05:21.920 shopping messages around, yeah, and I'm out of time. 05:21.920 --> 05:30.680 But yeah, thank you very much, Nick, we're going to know where to go.