3 ms·
The article did not make me understand that at all. > Since we're making a new app, we're going to want two things: an app server (which hosts our API & fronte
by jmusall 2mo ago
The article did not make me understand that at all.
> Since we're making a new app, we're going to want two things: an app server (which hosts our API & frontend) and a view server (which collects data from the network for us).
Yes, the user data is decoupled from the apps, but aren't both stored on some kind of instances? Also:
> Why are we listening to the event stream if we're the one making the write? Because we're not the only ones making writes! There are lots of user repos generating events, and lots of apps writing to them!
Who is hosting this event stream? Aren't we making some kind of federated network by deciding on our app server which event streams or which users/apps pushing updates to listen to?
- danabramov 2mo ago>Yes, the user data is decoupled from the apps, but aren't both stored on some kind of instances? There are two main kinds of "nodes" in atproto: - Hosting aka "personal data servers" (PDS). This is dumb JSON hosting that you can query by HTTP or watch by Websocket. Super cheap to run. They don't talk to each other. You can have one per user, or one per many thousands. - Apps. These are your normal webapps. (But they ingest data from everyone's hostings.) They also don't talk to each other. So yes, there are "instances" in the sense of "boxes which run software" but the topology is completely different from Mastodon or such. Data flows from hosting into apps (and then apps write to hosting). There is no hosting-to-hosting or app-to-app connection. Hosting is app-agnostic, and apps are hosting-agnostic. To make all of this practical, there are things in the middle that make the situation easier for app developers — either relays (which combine event stream from many hostings), or caches like Hubble[1] and Constellation[2] (which let you query the entire network in one request). >Aren't we making some kind of federated network by deciding on our app server which event streams or which users/apps pushing updates to listen to? Ideally you would listen to every relevant event from the entire network (and filter out every irrelevant one). It isn't hard today — you can either use an existing relay or run your own for ~$30/month or pool with someone. The discovery mechanism is that (1) a hosting can request any relay to crawl it, and (2) a relay can discover more hostings it hasn't crawled yet by following links — similar to how Google crawls the web. [1]: https://atproto.com/blog/introducing-hubble-a-public-mirror-for-the-whole-atmosphere https://atproto.com/blog/introducing-hubble-a-public-mirror-... [2]: https://constellation.microcosm.blue/ https://constellation.microcosm.blue/
- giancarlostoro 2mo agoLol reminds me of "ITS SERVERLESS!" Which always cracks me up, as someone who does find serverless useful for very strategic scenarios, naming things as though they don't require a computer somewhere to function has been one of the weirdest trends in tech.
- Longwelwind 2mo agoThe name "serverless" doesn't mean that there are no servers. It means that, as a developer, you don't need to manage the server. It's abstracted out for you.
- giancarlostoro 2mo agoI know what it means, I pitched serverless as a new tool to a former employer back nearly a decade ago, I had to thoroughly research it because the manager would of said no if I had no idea how it worked, funnily enough, he said yes before I could finish my entire pitch. The name still sounds silly.
- mort96 2mo agoI don't see the connection. The article is full of talk of servers: app servers, view servers, database servers, event log servers, ...