I Ship a Production App With No Backend – This Is the Architecture | Mikkel Malmberg, Tether

This talk explores the challenges of scaling applications that experience rapid user growth and the associated costs of server reliance. The speaker discusses the concept of peer-to-peer architecture as a potential solution to these issues, emphasizing how it can distribute the load traditionally managed by centralized servers. He introduces unique user identities defined by cryptographic keys instead of conventional database entries, allowing for user profiles to be controlled by these keys. Furthermore, the session highlights the development of a chat application called Keet, as well as a framework designed to simplify peer-to-peer app development. The speaker underlines the importance of maintaining a shared truth among users through logging and deterministic functions, akin to blockchain principles. He concludes with an invitation to engage with the emerging platform called Peer, which aims to enable decentralized app deployment and operation.

First, I want you to close your eyes and imagine imagine a user in your app. Can you believe it? It happens. All this time building, suddenly they showed up. This is the dream. This is the dream you spent so long. Now they're finally here. The graphs are graphing. The users are using. Are they users? Are they bots? Who even knows? Who cares? It's happening. The dream is

real. You finally put it in the hacker on your Twitter profile and expect uh to wake up to peer levels levels of wealth and fame. And then the next day you do wake up and um suddenly the users are there. Plenty of users, many users. You build an app, it's sort of a maybe a chat thing. Maybe it's like sharing media files. There's a lot of media

storage. The bills start showing up as well. You get a bill from your like hosting provider called triangle. It's like 20k out of nowhere. Like, what? What? How? Was it just images? Then your uh database provider super maze another bill. Doc, your auth service thing charges by the seat. But bots do bots need seats? Do bots have bots? Who knows? But all [snorts] these users um using

your app. This is the dream. Like, shouldn't this be a good thing? Suddenly it starts like weighing on you. How am I going to pay for this traffic and all this usage? Um and this is where uh peer-to-peer can come in. Because what if all those users were actually like a good thing that would help you? Um But before that, like the problem here is that everything

runs through the servers. Uh but what even is a server? Um It like in the traditional sense it's more or less three things. Uh let's just say it's three things at least. Uh so, there's all the post requests coming from the users. They go through to the server. The server like validates them, make sure everything's all right, and it stores the data. And then of course on

the other end there's all the get requests, like people reading the data. So, it stores the data, make sure that the data is valid, and then it um delivers the data, I guess. It holds the truth and the data. Um but it's it's fine, like we can trust this be I mean, at least we do. We do trust this because yeah, we do. Uh and um But

also this is this becomes like a single point of failure, right? If the server has a bad day, if this happy server guy goes down, GitHub, what happens then? Then everything goes down. Nothing works. but then you remember building thing here that you once went to a conference and there was this handsome guy, smart guy, brilliant guy, talking about peer-to-peer. Then the next day there was another

guy also talking about >> [clears throat] >> And he [laughter] mentioned how this would solve some of the some of these problems. So, does the same things. Like we don't you can't remove these things, you just redistribute it. Um And this um we do this with like just plain cryptography. So, um the first thing we have is like what even is a user in this space? Like

in a traditional sense, it's like the table row, HTML table row on on DocuSign or off provider or it's like a row in your database. What's cracking? Is it my beer? a row in a database. So, that's the traditional user that we think, but in reality like a um, a user in this sense like the keys. The keys that you use to sign them the the things

that go into the shared system. So, before you have a user, you have a set of keys. And then we can uh make it so that uh we um, make up this thing called a profile. User having profiles is like an avatar and a description and a username or whatever. And we can make it so that these keys are the only keys that can control this profile

in the in a sense that you you become the the user becomes that profile and the the keys determine who can uh modify it. And you can have multiple keys controlling the same profile like your mobile and your desktop. Anyway, we have users again now. And then all the users, of course, um, gather around things. So, in the chat chat app example is probably the room for

example. We're building a chat app Tether called Keet. You should use it. I'll bring up a QR code later. Um in a documents app, it would be the document. You know, like imagine a DJ app, it would be the DJ set. Whatever it is, you probably always have something together around. This is the I'll call it space in this sense. And we can make it so that

only users that are invited to a given space will have access to it and we could even make it so that there's like roles and permissions and all that. So, you have to be a moderator to I don't know. You define it. Key is that you can sort of build any app that you can imagine almost, in this uh shape where it's distributed instead of server-based. And

so, what happens is that all users Is it muted? Doing the Is it the key? No? It's just echoes [snorts] of Yunus's audio effects. Anyway, so um We have users participating by uh sending messages. Everything that happens in our system we determine is like messages. We know this from like uh I don't know Redux or something. Like you have the actions and then they go through a

reducer or anything and then we have the state coming out of the other end. We can do the same thing but distributed. So, every user uses their keys to sign the messages and we can encrypt it all and everything. And then uh as long as we share the same truth. But, how do we get to that truth? Um We can um We have the logs that all

the of all the user messages. Like all the all the things that have happened in our app is like a giant log of things. And then if we run it through the same function here called apply, uh which is sort of if this smells a little bit like uh blockchain, it's because it is kind of like blockchain. If you run the same messages through the same function,

you can do it however many times you want as long as it's like deterministic, you'll get the same result. And so, if we run the same messages through the same function, we'll get the same result meaning like we can trust each other as long as we get to the same result. Yes. Uh that's of course means deterministic, so we can't use dates for example in the apply

function. We can't use randomness and all that, but um yeah. yes. And this is of course like stuff that you don't probably think about so much when you're building against servers, it becomes then uh important when you do it uh for peer-to-peer. Um But in a sense What was I thinking about? Yeah. So, I I think I want to go back actually to this one. So, um

just a point that I maybe forgot to make, but it it's your profile. So, you can hold the profile, but in a sense like anyone can hold the data. It doesn't matter who holds the data because it's uh encrypted likely and you hold the keys to it. So, we say my profile, all my data, all my notes are in like a tiny safe. I can give you

the safe and I can give another one a cup. Okay, it doesn't match completely to the physical realm, but still like if I'm the only one with the keys to the safe, it doesn't matter really who carries it. Um and this is the same with here with like the profile. I can My profile can be shared between anyone. We have stuff even like in Keep with like

a an inbox. So, when you get a friend request, a user puts a friend request in your inbox. And then the inbox can like live wherever, but you're the only one with access to it. was the point that I think I forgot to make. And all of this is exists already. It's what we are using to build Keep, the chat app. It's kind of done. It kind

of works. Not kind of works, it works. Keep does everything that you would want from a messenger app. Uh and um what we're now now starting to slowly go into is to like take all the learnings that we have learned from building Keep and then uh putting them into sort of a framework-ish SDK kind of thing to make it easy for anyone to build peer-to-peer driven apps.

So, you don't have to think too much about the apply methods and apply functions and everything, but give you some like good conventions for building stuff. So, uh you can stand on the shoulders of um Tether, I guess. Um so, this isn't final. This isn't what it's necessarily going to look like, but this is a sort of the direction that uh I want to go in, where

you have like a space manager. So, the space in this case is like um the thing that you gather around, the the room for the chat app, the document for the documents app. then you can um um add commands and you can add collections and all that. So, for a chat app, for example, we define a schema for what things look like. We It's a chat, it

has collections. It One of them is our messages. They have like fields, like anything you've seen before. And there's commands as well. So, it sort of looks like a Redux thing. We have like actions and uh they result to the same state. You could also So, this is like key to the chat app, but you could also imagine like a In this case, I call it bunk

docs. This is a Google Docs competitor, where we have roles, too. So, a nobody can do anything, an editor can do these I I've toyed with like a Yjs. Do you know Yjs? It's like a multiplayer library thing. So, you can use TipTap, but have multiple editors on the same thing. So, I've written like an adapter layer that puts Yjs onto this. And of course, a a

document has metadata. We can add that and we have commands again. And this is So, this is a demo of uh a test app of bunk docs running on the simulator and electron here. Yeah, yes. You get the drift. But just to say like everything's kind of possible. Uh it's just a matter of like structuring it in this uh special way. Do we see it to the

end? I guess. All right. That's enough. We get a little bit of tuna action. And emojis don't work. Okay, we will Um So, this is uh imagining like the Dropbox the the good parts, I guess. Uh how it how it used to be with like you just share a folder and anything you put in that folder you can have on all your machines and you can invite

people to it. It's the same kind of thing. It has a the the space here is the individual folder, then use is like a keyword for so sort of a middleware layer where you can uh use all the building blocks that we have uh built for our app as well. So, we have support for like blob storage and in this case drive, which is hyperdrive uh one

of our modules uh where you can yeah, get a drive and it's uh automatically shared between the participants. Uh so, we have files, we have commands, so on and so on. Here's a demo again of Dropbunk running on my machine and uh VPS. So, we init in a folder, we get an invite. We press the trackpad too hard and then Yeah, you can probably imagine what The

demos aren't as fun when you don't like do it. We just show it. Okay. Yeah, we join it. We go to the thing. Click randomly. What's going on? Keys? All right. Yeah, um what happens next is I I create files and they sync. You can imagine. You know I'm calling this peer-to-peer today. We don't know actually what to call it yet because it isn't really a thing

yet, but it's it's an effort that we want to do. Peer in this case is what you heard Dave maybe talk about yesterday, which is sort of the um distribution layer and the runtime for much of this. So, even down to like deploying your app is happens on peer-to-peer. Meaning that it's like you you it's unrestricted by firewalls and all that. We have some hole punching technology

it's called finds a way through all of the common routers and everything. Um so, that's what really what like peer-to-peer shines is when um yeah, you we're working like there's a a case for like if the internet goes down, right? But people are still together. They turn on Bluetooth. They can still share the messages on Bluetooth because there's just the transport layer all of the like the

math behind it still works. So, just to end it like Peer is the platform to build this on. It exists. You can go read the docs. Going through a bit of a transition, but it's there. It exists. It works. Teller is the one paying the bills because we like this idea that apps should be able to do this and work like this and be like unstoppable is

the thing I think. If you want to follow me, I'm maker. If try Keet, you should. There's the code. And then that's the the actual Thank you. >> [laughter] >> Yeah, thank you everyone. Peace.