Tim Ryan 0:00 between these two. 0:00 I just described everything that may be true of AT Proto. 0:05 So GraphQL is a ubiquitous library, and you don't have to take my word for it. 0:10 You can just go to graphql.org and see the number of large companies that are using it, like Meta, AWS, GitHub. 0:17 In my world, GraphQL was so ubiquitous that it was sort of, like, obvious that at least someone out there would be trying to make a comparison of the two technologies. 0:26 Given how you could just pop open a web browser, a web dev console, and sort of see the truth that like most websites are using it. 0:35 You know, one major social media website is not listed in that previous list. 0:39 That may be because their CEO doesn't understand how GraphQL works. 0:42 Let's not make that mistake today. 0:43 Let's find out. 0:45 So, first when I was looking at this problem, I was like, all right, well, I'll search GraphQL and App Proto Bridge. 0:50 Surely someone will have documented this. 0:52 And no, every single one of these results is someone not answering that question or a mismatch. 0:58 The AI overview gives a description of what that would be, but that is not the answer. 1:02 And unfortunately, now the top answer for this is this talk, which means this has to be the canonical answer to that. 1:09 So let's try to do a good job. 1:12 I join you, ask you to put on your GraphQL colored glasses as I, a GraphQL developer, tries to grapple with the atmosphere. 1:20 The source code for a demo, if I have time, whatever, will be available at the bottom of this for the rest of the talk. 1:27 Quick intro to what GraphQL is if you're not familiar. 1:29 So there's a website, graphql.org. 1:32 There's an open source spec and there's a foundation which many companies have joined to work on it. 1:36 It was built by Meta in 2012 to address resource constraints on their mobile applications. 1:42 Open sourced in 2015. 1:44 And the foundation was launched in 2019. 1:46 You can see some things which are very similar to HTTPROTO. 1:49 Schema definition language. 1:50 It wraps REST much like xRPC. 1:52 And there's type-safe schemas like Lexicon. 1:55 Maybe two differences. 1:56 It controls how much data is fetched and ways to fetch data recursively, which I'll talk about. 2:02 First is the GraphQL schema language. 2:04 So here I've modeled a conference, an attendee, and a location. 2:08 You can see that it's very human-readable. 2:10 It was designed for frontend and backend collaboration. 2:13 Supports objects, interfaces, unions. 2:16 Each field individually can accept arguments and return scalars or other types, and other fields can accept arguments as well. 2:23 I think this is the difference between HTTPROTO and GraphQL. 2:27 Like Lexicon, it's forward compatible. 2:30 Unlike Lexicon, you don't need to query all of the fields. 2:33 So, you know, you could define a monolithic object like this, and you could only list the ID and the name, and you'll just get the ID and the name. 2:39 Name. 2:41 Let's talk about querying. 2:42 So here's an example of querying all the Star Wars films. 2:44 We'll get the first 3. 2:46 And it will return a list of film objects. 2:48 And all we're gonna do is pick up the title. 2:49 Not the ratings. 2:50 Not everyone's opinions about them. 2:52 But just return what's on the right. 2:54 And GraphiQL's query DSL has this, like, nice property where it kind of looks like the JSON on the right. 2:59 So people really love that in live demos. 3:01 And then we could go and we could add another block here. 3:04 Not only do I have the films, I want to add, like, oh, I want to get the first 3 characters. 3:08 From each of the films and the response will update accordingly. 3:11 One of the nice things about this, in GraphiQL world, is that, like, when you select an object and then you select subfields on it, you're doing this within the same request. 3:19 I think in HTTPROTO you have, you make it like a ref, and then you have to go resolve that ref with another network call. 3:26 It's all resolved for you and there's, there's, depending on how your backend is designed, this could be more efficient because you're basically doing a SQL join, not just two separate SQL calls. 3:35 OK. 3:36 The AT proto comparison. 3:37 I'm going to make an xRPC and I'm going to get an object which eventually wraps a post, let's say. 3:43 Now this definition is— sorry, one second. 3:47 Yeah. 3:47 So this definition is interesting because the post is sort of like the canonical DB format. 3:52 And there are pattern in Bluesky where you actually fork that and create a post view. 3:58 This is the thing stripped of, like, its like counts and follower counts, like counts, reply counts, and everything. 4:03 Because it doesn't have that information when you publish it. 4:06 So you need to create a lexicon view to sort of add that information in, and that's computed by the app view. 4:12 So it sort of changes it from the GraphQL world where the consumer defines what data they're getting to you actually have to publish this and have a lexicon-oriented data model to show what you want. 4:24 Let's look at the schema comparison. 4:25 So this is an example of a post defined in GraphQL. 4:28 Looks very human-readable. 4:30 Here is an example of a post you find in Lexicon. 4:33 It's certainly machine-readable, but I wouldn't say it's human-readable. 4:37 Is there really a big difference between the two, though? 4:39 No, I think they're pretty homomorphic, even though the one on the right is much simpler and they don't have, like, constraints around strings, etc. 4:46 And part of the reason for that is, like, well, yeah, you could throw around a bunch of annotations on the thing on the right. 4:50 But really we're just talking about data. 4:52 And if data could be homomorphic, that means you can bridge the two, which will be the part of the talk I end on. 4:59 So, I want to consider 3 scenarios or takeaways for HE-devs. 5:02 A is what GraphQL offers that is different from what exists in the Atmosphere. 5:07 Now, the second— oh yeah, and just as a top-line summary, it's like, these are the sort of things that I talked about already. 5:14 There's other things that I could get into, like generation via server definitions and, like, tooling. 5:18 A very robust ecosystem of tooling that's cropped up over the last decade and a half. 5:22 I think a lot of these are just because of the age of the protocol, not things that won't actually come to the Atmosphere. 5:28 Worth considering where developers are coming from when you're trying to give them a way to interface with AT. 5:35 So, question. 5:36 Is GraphQL federated? 5:38 On the largest open source company's website, they actually list Apollo. 5:43 They list that GraphQL has federation. 5:46 But I will actually give you the example of what are first-party APIs that you can consume GraphQL with. 5:52 And I went to this page and I kept scrolling and I only came away with GitHub, GitLab, Shopify, and Yelp as examples. 6:00 So really it's not federated if there are so few first-party implementations that they're willing to bank other people accessing. 6:07 And I think the reason for that is the NSID. 6:09 And the NSID means that I can actually publish something— let's take the Yelp review API— I can publish an object from my API which is the Yelp review API if they were conforming to that schema. 6:21 If they're conforming to GraphQL, you can't. 6:23 I'm lying. 6:23 It's not true. 6:24 They could change it at any time. 6:25 That helps when you have a lossy lexicon inside of your own applications. 6:30 But it doesn't accomplish federation. 6:32 And what they mean for federation inside of Apollo is actually federation across REST backends, GraphQL backends, et cetera. 6:40 Try to take all the different data sources you might have and put them into one pipe. 6:44 Which is actually really attractive for an individual application. 6:48 GraphiQL's role in existing applications to bridge to App Proto might be a lot of companies are using it, it consumes a lot of APIs, maybe if we introduce App Proto to those consumers, we can get more App Proto connections and integrations into public apps. 7:02 I'm going to skip to my pitch about, like, what a new application could consider. 7:08 8 minutes? 7:09 Yeah. 7:10 So, brief pitch for— I started this by working on a Craigslist competitor marketplace-style app, which I called Mothball. 7:17 No relation to Anasota. 7:19 Just, this was the pitch I came in with. 7:21 I was gonna build an expo app and be like, what is it like to build an application with @proto integration? 7:28 And I started with a GraphQL mock GraphQL, and I was gonna move it to the server. 7:31 And then I learned about @proto and now I'm down this rabbit hole. 7:35 So I was thinking low latency in mobile and web. 7:37 There's some strategic benefit there with GraphQL. 7:40 You could do sensitive off-Proto data. 7:42 And you could wrap non-AT services— geocoding, search indexes, et cetera— behind a single API. 7:49 That might be a case for using GraphQL as a front end for App Proto on new apps. 7:53 But I think the best case scenario is actually this middle ground where we bridge the two. 7:58 So now I'll stop there for questions, but while I show this demo really quick. Speaker B 8:04 I don't think we'll have time. Tim Ryan 8:06 The demo is just this button. 8:08 So here we go. 8:09 This is the lexicon. 8:11 XRPC request, and on the right I'm fetching live data from the Atmosphere. 8:16 Here's an example of doing multiple XRPCs in the same call from feed and from your actor. 8:21 Go check out my repo if you want to play around more with this code generation. 8:24 Thanks very much. Speaker B 8:25 Thank you, Tim. 8:28 Awesome. 8:30 Is our next speaker in the room? 8:32 Yes. 8:32 Amazing. 8:36 Welcome. 8:37 Our next talk is titled "Jacquard Magic: How to Make AT Proto Actually Easy with Rust." And your name, please? Tim Ryan 8:46 I'm Orwell. Speaker B 8:48 Orwell is here to share for us.