Show Notes
swyx: [
00:00:04] it? I pronounce that, right. It's it's my Chinese and English initials. And it's just a branding that I'm leaned into because it's unique. Yeah. I think it's great.
Loren Sands-Ramshaw: [
00:00:11] Yeah, definitely unique. So for those of our readers who don't yet know you,
swyx: [
00:00:15] Who are you, what do you do?
Cool. I'm Shawn. I guess I work on developer experience at Temporal. I should be more assertive. I am head of developer experience at Temporal.io. It's a Small startup that does microservices orchestration, which is a very, very fancy name that basically runs an open-source framework spun out of Uber that we can go into more details, but really, I've done.
I sort of migrated from finances, which is my first career. Then I went into Front end. So I did a JavaScript bootcamp then went into front end D started doing some speaking and writing in 2017 and got noticed by Netlify. And that's how I got into developer education, which is what we're here to talk about, I guess, and then started getting into graph QR because it was all tied into the react world.
At the time. You could not ignore graph QL and Gatsby and Apollo and all the other ecosystem in, in, in place. I did. Then I then went to AWS to do the same job, essentially where they have amplify an app sync apps think is AWS has graph QL gateway as a service, which we can talk about. And I recently left to join Temporal.
Loren Sands-Ramshaw: [
00:01:18] Going back to when you were getting noticed you were like writing blogs and doing talks and getting out a spot Netlify how did you decide to get into developer education?
swyx: [
00:01:25] I didn't, there wasn't actually a decision. It was just like, let's just try this. And see what happens. So that the context was that the boot, the first job I got out of bootcamp was at Two Sigma, which is a well-known Quant hedge fund in New York.
The problem was that I was in a, I didn't know it, but I got into a bad part of Two Sigma where they were severely underusing their engineers to the point where four days out of five, we were not doing anything like specifically not standing on our desk. Cause we had stand up desks. And.
Explicitly given to have the okay. To do whatever we wanted, whatever because we just didn't have work. And that was, it's a, it's an enviable position, right. For for a lot of people like, Oh yeah. Paid around and do whatever you want. That's that sounds like a great job, but I don't think it's a very good job for a junior.
Like someone just starting out. Right. You're not going to grow up very much. So it's like frustration. Really that I was like, okay, I'm not getting any learning at work. My, my team lead was like not doing his job. So I just started blogging and, making my own mentors, like, externally New York city has a pretty vibrant meetup scene.
So I just, started doing my own talks, even though I didn't feel like an expert. And then I started doing blogging and I think the first one that really picked up for me was. When react announced that it was working on async react like concurrent mode as it is known today, but back then it was async react.
So it was announced at a conference in JS conf on March in March, 2018. And I remember that night because it was a big shock to the react ecosystem and it was like a sweeping change. They touching every single part of react. So I just stayed up all night to write a walkthrough of the talk, the demo, and just really like went through everything at it.
And that was the first blog post that. We've got really some notice for me and that really still bald since then. And since then I've kind of enveloped everything into this principle I've learned in public. Like when you find something interesting write it up in your own words and share it with people.
And at least the people involved in working on the thing will probably read it. And if you're saving some work and if you have some unique perspective than other people will find it helpful as well.
Loren Sands-Ramshaw: [
00:03:26] Was there a moment where you were like, I'm going to write my own blog posts instead of reading other people's.
swyx: [
00:03:32] I've been doing it, unsuccessfully for like the two years prior. So there was no one single moment. It was just like focusing it on something that people actually cared about. It turns out that, you want to write things that people want to read. And that's that was a pretty big insight for me.
It's not, it didn't seem like that big of an insight until you look at it. The vast quantities of developer blogs out there. And a lot of them are sort of very inward facing. They don't really answer the question of why should you care? And so I, I definitely had my mentality changed around like, okay.
Like it has to be an intersection of things you're very interested in and things that other people are interested in and you can't just have one or two.
Loren Sands-Ramshaw: [
00:04:07] Speaking of things that people are interested to read, you have a great book on the coding careers. That's called the coding career handbook.
One of your first. Customers really like the parts of it that I read. What was that like coming with the idea of the book and writing it and
swyx: [
00:04:20] publishing it. So there's a fun story for the reason the name is so awkward. I still don't like the name, but I just had to go with it because I didn't have anything of anything else.
The reason was the original name was cracking the coding career because there was a successful technical interviews book called cracking the coding interview. And the whole point was that it w I wanted it to be apparent in the title that once you're done with the interview, once you landed the job.
There's a huge gaping hole of what's next. And this th this book is targeted at the what's next. Unfortunately, Gail McDonald, the author cracking Cody career actually got in touch with me and mentioned lawyers. So I had to change the name before lunch. So, by the time, like I already had my Twitter handle up and all that, and I was just like, all right, I'll just stick with this thing.
But it is an acronym. Yeah the. Point I think is that people, I think my most successful writing, like it or not has been my non-technical writing which the learning public essay has reached, hundreds of thousands of people. And I constantly get shout outs every single day about people starting to own journeys.
And it's something that I really. Believe it, even though I hate, I'm not like the Tony Robbins type, I don't want to be like a lifetime life coach or anything. I just think that this worked for me and it will work for a lot more other people. So I was like, okay. I just, I should probably just write down some more advice on, on, on what I think that people need, because.
I think what really crystallized it for me was when you look at career ladder. So I did a study of every public career ladder out there. So career ladders are these things where it's like, all right you're junior, you're expected have these qualities or senior, you expected these qualities, staff, principal, whatever.
And and everyone has some version of these in some companies are actually brave enough to publish them. And so if you just study all of them and you realize something really interesting, which is that when you look at the way that people are promoted and graded about 75% of the grading criteria is non-technical.
Seventy-five right. It's like, all right, you can call it. Great. But what about your communication? What about your business impact your mentorship and all that, which is like surprisingly not the type of thing that you learn in college or bootcamp. And no one tells you to do it, but suddenly it's 75% of your evaluation, like, well, okay.
And I think that just reflects the reality that we are less coders and more code enabled humans and we can code, but we're humans first. And so we need to apply all these sort of soft skills. I hate the word soft skills, but that's the common commonly accepted terms. So I use it Two two, we need to teach each other, lessons from these things.
I am not saying I'm the world's foremost expert at them. I have things to work on myself and it's a very difficult thing to, to come on and say like, I have something worthwhile for you, even though I'm imperfect. But I don't base my advice on myself. I also base my advice on.
Hundreds of other people that I've interviewed and collect collected the book has like 1400 references to people smarter and wiser and more accomplished than I have. And that, that's just what research does for you. And hopefully you can decide yourself which of these ideas you agree with and which are not.
And that's all I ask really, I think it's really hard to write a soft skills book. Because your sort of character has to be impeccable. Like the moment you're like, Oh, I had a bad interaction with this person. Therefore, the entire book is wrong. Like, I'm sure, if you want to take that view that's fine for you.
But I view ideas as sort of independent, you can sort of pick and choose. And if this book, has 40 chapters and three of them make sense for you then that, that would be a good investment of time for me.
Loren Sands-Ramshaw: [
00:07:39] I liked it like the field of life coaches and career coaches and therapy and stuff.
And I really appreciate the knowledge that you've put into the world with that book. So thank you
swyx: [
00:07:49] for writing. Well, yeah. Thanks for asking about it. It's kind of, it's still awkward that you can hear me like being very hesitant about like, talking about this thing, but people like it.
I think that, everyone wants to hire seniors. That's the truth. There's a huge glut of bootcamps producing juniors. There's lots of people self-teaching. And then from junior to senior, somehow you magically, hope to. Find something that works. And then once you're seeing her every once a hi, everyone wants to hire you.
So I guess if I had to narrow it down, like I need to make it. Easier for people to up-level whether or not they can use the book as a guide or they can join the discord that I have and interact with me directly and ask me questions and all that. These are all passed into upscaling, more people from junior to senior.
And I think people don't do it. It's just, it's a very awkward thing to do. But that's an interesting challenge. I really
Loren Sands-Ramshaw: [
00:08:37] liked the boot camps. There were like nine months. You can go really deep. It'd be cool if I was like a graduate school version of boot camp. So you go to the bootcamp one, and then later on you go to the boot camp two.
swyx: [
00:08:46] Oh, there is a Recurse center, which is the self guided one in New York. Yeah. A lot of pretty famous people have come out of the recur center because they do it's essentially like graduate school. Like you propose your topic and then you sit in a room with a bunch of other people who are very self motivated as well.
And you produce something to impress each other and the kind of people that actually self-select to go there are very intellectually curious themselves. So they work on pretty cool stuff. And it turns out that once they graduate, they will actually go on to do some pretty interesting things as well.
So, that's a comparison, but like the thing is that doesn't scale. Like they, they admit like maybe a few dozen people there's tens of thousands who will never do it.
Loren Sands-Ramshaw: [
00:09:23] Also. There are a couple more ideas in that area that I have where like, Having it be more of a norm for companies of like even medium size to have like a junior teaching mentorship program.
swyx: [
00:09:37] Yeah. Yup. More apprenticeships, especially for people from non-traditional backgrounds. I find, I see so many companies that have, Campus recruiting for colleges. But actually, what about everyone else? So, yeah. And then in the mentorships, it, th the thing is like, it's perceived to be a cost.
And we need to turn that around and turn the tenant equation around and say like, actually you're getting. To upskill talent, there's that cheap, that becomes very valuable once you put, once you invested in them. And I think some companies are getting into this mindset. So Stripe is having direct integration with the university of Waterloo.
And I think shop, sorry. Stripe is integrating with the university of Limerick, I think in Ireland. And Shopify is. Has a has a degree offering with the university of Waterloo. And it's just amazing to see all these innovations, but they're just sort of piecemeal. And then, they'll improve a few dozen people, a few hundred people at a time, but it's a slow process for sure.
Loren Sands-Ramshaw: [
00:10:28] I would think of it makes sense for there to be like a lower part of the market where like, like the, maybe under the entry-level for expected junior does, there's like a gap where people can do like. Traditional apprenticeships where it's more of a stipend or like an internship kind of thing where you're not being paid like a normal dead salary, but you are learning a lot.
Yeah. And maybe like that would be low enough that it would be profiled.
swyx: [
00:10:52] They are doing that at they are doing that at Lambda school, which is the online bootcamp. The problem is Whenever you talk about paying people perhaps less than an average developer salary the, there people online who get very angry about that.
And I, it's not my place to say. Who's right and who's wrong. I defend the right of consenting adults to agree to whatever contract they want, even though, some, some of them may be exploitative in retrospect, but we have to let people make mistakes. And we have to let people experiment with new forms because all we know is the current system.
Doesn't work well in, in some way we need to try new ideas. We need to make it safe to try new ideas. And and so Atlanta school was really trying. And I think what they have right now is they'll guarantee you they'll give you a student for a month.
And they'll pay the full month of it. So it's totally cost free to you, except that you have to give them, stuff to do. And I think that's a really beautiful experiment. So I don't know, some people get angry about that. I'm like, you're, you don't know what it's like to be a bootcamp student.
I would've killed for that. When I was a BlueCat student,
Loren Sands-Ramshaw: [
00:11:51] I have friends who haven't found a job after boot camp. So, hope that
swyx: [
00:11:56] system works fine. Yeah. Nothing is better than sort of just getting into a real work scenario and like, stop jumping on the artificial hoops with like in video binary or whatever.
And just get into the real work. And after three months, six months, nine months, you're a dev. And. You know that w yeah. Every, everything else is just gate keeping. So whatever.
Loren Sands-Ramshaw: [
00:12:14] So you think of algorithm, coding interviews? I had an interview with Toptal, and I didn't know they were going to do data structures and algorithms.
So I didn't study and like, I haven't studied it in over 10 years. And I got an a in my courses at Dartmouth, so like I knew it at one point.
swyx: [
00:12:30] But I totally did you burn, did they give you a grade? Did they give you a number? Like how bad? I know they just like stop
Loren Sands-Ramshaw: [
00:12:35] asking your questions.
Yeah, yeah. So tail, the reason that'd be so stringent is the marketing, right? They're like we, they have to have a rejection rate to, to show off. Because that's part of the marketing appeal. I totally get it from their angle, but then also, like you don't need them. So, whatever.
Loren Sands-Ramshaw: [
00:12:49] What are your thoughts around different education mediums? Like how did you decide to do a book versus a video course? And do you have any plans for doing books or courses or.
swyx: [
00:12:59] Inefficient. That's an interesting question. The reason I did a book was because the MVP of a book is a blog post, and I already done like three, four years of blogging prior, and people already knew me from my blogging.
So it was very natural progression. So I didn't really question it. I also know that I take a lot more time to do video than I do writing or, yeah. No, let's just put it, let's put it the other way. Like, I don't think I'm ever on the world's most natural speaker. I have a lot of false starts.
I've thought I'm sinners and I'm still working on it as you can probably tell. But yeah. And so when it comes to writing, it's SEO, searchable, it's you can edit it anytime and reformat things, and it's not it's super cheap. You can add hyperlinks, which I love dropping references.
Right? Like when I. Have references in a podcast or a talk. I can't drop a hyperlink in my mouth and you can click on it and it just leads you right to the source. I really liked that. And it annoys me when podcasts say, like, we'll put it in the show notes on any deal. They don't it's really super annoying anyway.
So writing solves all of that. It's it's perfect. Medium. It's very scalable. In fact, I have a whole chapter on why writing is great. Everyone, every developer should write. So yeah, I mean, no, no contest on mediums. That's it. One of the downsides of writing is that the moment you call anything, a book, what's the normal price of a book it's nine to nine to $59 or something like that.
Like you can go to maybe 99 or whatever, actually, I don't know how much the
Yeah, got it. Yeah, there's a range. Right. And it's basically constrained by the format rather than the value of the knowledge contained in the book. So if my book happens to. Yeah. Increase your the slope of your career by $10,000 a year. The Mexican charge is 59, which is what I charge that's absurd.
Right. And other formats, like video courses, that's automatically like 200 to $300. Irrespective of like the actual value of the delivers to you. And so that's a really bizarre way to do things. So that, that was one, that's one argument for why you might want to do other formats.
So apart from this book, I actually considered doing a reactant types, of course, because my other one of my other side gigs is that I run the react and TypeScript cheat sheet, which is. The de facto community docs for react and TypeScript. And it's a, it's a much bigger deal now with them back when I started.
So I teach, a thousand people a day react to TypeScript and it's been a completely volunteer behavior volunteer activity. And if I, sold 1% of those on a video course, I probably make a living.
It's something that I thought about. Th the only reason I don't do it is because I don't want to be a teacher. I don't think I'm a, I've a very ever temperament to be a good teacher. I don't think I have the patients. I want to do other things with my life apart from teaching.
So I think I'll just leave it to someone else, or maybe collaborate with someone.
Loren Sands-Ramshaw: [
00:15:44] Let's move to the backfield topic. What is your
swyx: [
00:15:47] take on evacuation? Greatest thing since sliced bread. Is that what I'm supposed to say? So I had a talk about this Hawaii where like kinda compared it to like, I hate I wish that people would start comparing graph QL to risk.
Like we have to, because that's kind of what we. What the paradigms are and how people mentally place them. But rest doesn't go away at Graco has a protocol over rest. And so it was like, it's, it's not either, or it's like one and the other. That's it. My sort of galaxy brief summary of graph you all is that instead of creating a dozen different end points that are all kind of dumb you create one smart end point and then you have contracts that can specify whatever that end point does sort of on, on request.
And I think that's a really simplified take, but it really. You were there at Apollo day. And I think the Apollo folks have a really good present explanation of this. It really starts to come into its own when you start having multiple devices to support. So you have mobile and desktop and web Sr and, and Sorry.
Well, mobile native and desktop and mobile web and on whatever other devices that you may have, these are all have the different data requirements. And there's a combinatorial explosion. They have all these lines crossing over from different services, into different devices that you could simplify by just having one single sort of smart endpoint.
And everyone connects to that one smart end point. It speaks to the right contract and that smart endpoint has. The means to resolve all the data from each individual data source then that's essentially graph QL. Like you could do this in a bunch of different other ways as well. And there have been many, many other attempts like graph QL is, is, it's not new.
They're there. And I think the creators of graph you all are pretty upfront about like the inspirations that led to. Craft you are like all data, which I never really tried any of these. So outside, I don't have much sympathy. All we know is that graph QL is successful. Now it has the network effects now, and therefore it's a much better bet than the other formats.
Which is an argument by like it's success, it's popular. Therefore it should be more popular like that kind of argument, but it's true. There's some amount of validity to betting on things because the ecosystem is better. And so, so that's really smart.
I have another take, which kind of combines into one of the questions that we prepped for is what I dislike about it. So, I think that it's very, very easy for front end developers to wax poetic about graph QR, because it makes their lives a lot easier. And the people that we kind of leave behind, or we sort of punt all the tough questions too, are the backend developers for whom It turns out it's not true.
It's not always true, but net, it turns out that it's more work for them, whatever it is from like, figuring out how to do off figuring out how to do like rate limiting or like query complexity, limit limitations and like, Inserting all the validation steps or like joining schema is, and the federating them, these are all the tough work that was maybe sometimes shift done on the client side has all been shifted onto the backend.
That's really unfortunate for graphical adoption. Like the main bottleneck of graphical adoption is backend. That's it there. And I wish we would stop. Okay. I wish front end developers would stop selling graph QL based on how easy it makes their lives, because it's totally unsympathetic to graph to back in people back.
And people are just like, you guys are not thinking about the security risks. They're not thinking they're not talking to them in terms that they are thinking about. And I wish that more evangelism, more graphical individualism was more sympathetic to the backend perspective.
Loren Sands-Ramshaw: [
00:19:08] What are your personal
Oh, graphical. I, this is the common answer, right? Like it's I feel like graphical is kind of like the common ground of all of them. Cause like, you can, it's a raffle or it's a postman or whatever it is. It's the common tool and it's so good and actually got a lot better. We graphical Explorer sorry, graphical Explorer.
And that's the little side tab that the added and I think, their plans were a graphic for 2.0 in graphical. And it. It's just such a introspective tool that has embedded documentation in it. Like, it's just, it's everything you want out of a documentation tool and of API documentation that rest never really got to, like the best you got.
It was open API and even that's kind of like a sprawl and it doesn't have embedded like try this, it, it does, but like it, it's just not as smooth as graphical. So yeah not really galaxy brain take here. But I think, yeah once you make experimentation and modification a lot easier than you, you move the pace of development faster, at least on the front end.
So, I definitely like that a lot. The errors kind of bother me a little bit with, areas being 200. Okay. That's a common sort of gripe among people who don't like graph QL, but you'd learn to deal with it. You just, yeah.
Loren Sands-Ramshaw: [
00:20:16] Any advice for
Nice. We're learning people that are in graph. Y'all I think the thing that you do in the book where like you explain the validation and set it, set things up from scratch you should do that. You should go through the exercise. Actually even set up a server using just pure graph LGS without all the fanciness that maybe Apollo server does for you.
And just, yeah. Fundamentally understand like, or, so like, I guess the advice would be like stripped down the tooling as much as possible and build your way back up instead of just starting at the tooling and never going down the stack a little bit. So, did you know that you can query Aggreko end points just with fetch?
Do you know how to do that? If so then great. Then what's the next step after fetch? What does caching actually do for you? So on and so forth, like these are all this, these are the steps that you knew you need to sort of work through to, to build up to a complete understanding of graph you are so that when things go wrong, you know how to fix it.
And that's one thing which I really encourage because graphene is a complex system. It's client side is service side and there's like, This complex chain of events that go through it. And sometimes the errors can be a bit too loose. If you don't really know what's going on under the hood.
Loren Sands-Ramshaw: [
00:21:19] Yeah. I don't a friend who I was a junior dev working at a company that like had a Apollo in place and like their view of craft kill was if I add this like fragment or this query to this component, then. I'm going to get the data. And so they don't have the understanding of like what's happening, how it's all getting collected, where the cash is doing.
Which is definitely helpful. When things go wrong.
Loren Sands-Ramshaw: [
00:21:48] What are your, yeah. So you had a chance to read parts of the guide. Thank you so much for being here. I really valued your feedback. What
swyx: [
00:21:55] were your favorite parts of the book? So I noticed that you do something unique, which I don't see a lot in a lot of other books, which is every code sample has like a good tag.
Is that what you do? And you can just view the defer or go straight to the, get, get tag from that sample. And I actually really liked that. Sorry. So this is really tiny detail, but then like, I appreciate that. Cause I read a bunch of other books as well. Like I got another, a book here.
And on top of this monitor that I'm looking at you on, I have a bunch of other techniques as well. I really enjoy reading technical books as a way to level up. And so like when you can actually follow through on the code and download it and run it yourself, that's a really nice detail.
Overall, like, I think it's, I think it's a very comprehensive, like 500 something pages, which is huge guide, and it's the kind of detail that you would take months to really pick up on. And, you get it within a Yeah. Within a few days of just reading this book.
And so I just really appreciate it, like all the research and all the piecing together of things. Obviously you had to make some tough choices, like, picking on picking Apollo. But I don't think these are controversial at all. These are just like, the industry standard things that, that you would at least expect people to be familiar with.
Even if they go with the alternative. And then going into like each individual client and framework, I don't use react native sorry, I don't use Vue or react native, or I think you have some other native iOS, even that you went into there. I don't use any of those platforms. I'm just a web person.
But I know that, when the time comes, I can just pick it up and start there. So that's a really good perspective as well as like the broader ecosystem, right? Like, Apollo Federation, which is like a fair, fairly new thing. And then talking a little bit about history as well, which I think is one of the most significant graph your companies out there.
So, so yeah, it really like combines, condenses a lot of research that's done by you and John Resig and that's pretty well, this very much worth the sticker price.
Loren Sands-Ramshaw: [
00:23:36] Thank you. So the tags is particularly difficult because I have a tag for each section of each coding chapter.
And those are chapters six through 11, and then for each version of the book has a different tag of version. So it's like the react chapter is maybe 40, 40 tags with each, with a version number. And then each time I changed the code for the next version of the book, I can make another 40 tags. It's a big process.
Yeah.
swyx: [
00:24:05] I was thinking about, is react the best pear to graft you all like, does it, is it an accident of history that it just happened to also come out of Facebook? That's. Which is why we use it together. I always wonder that because, we act it's very weird with its effects and all that.
It's kinda clunky to, to use. So you basically have to use a third party library, like, or goal, or Apollo client to wire to that. I don't, I'm not sure how I feel about that. Like I was just like, Ugh. Anyway, we can talk the frame, talk about frameworks in a day, but yeah, I appreciate it that all the guys are in there and you took pains to, to cover other devices.
Like, like I said, like, one of the main benefits of adopting graph is that you can support multiple devices, multiple frameworks in paradigms pretty easily. Okay.
Loren Sands-Ramshaw: [
00:24:47] Any visions
swyx: [
00:24:48] for the future of death off? Oh
Loren Sands-Ramshaw: [
00:24:51] well just probably like, having the backend story be. More developed. I think it was both pitching them and then
swyx: [
00:24:56] also the software supporting them. I have a pretty good coverage of this in the book where you talk about differ and idea, the two directors, which I never remember stream yes.
Street. So like all these spec level things are very important because once it's in the spec then multiple, different parties can implement them. And we because right now everyone's kind of haphazardly kind of. Hacking their way around it if they need it. And once it's standardized we can really build some rails around it to make it a lot more reasonable and, things like the, for like, they need to be in there just cause once your graph gets big, like you, you need to, query things at different paces and have them all in one quick one single query.
Yeah. So, so more standardization of stuff. Like I even, I don't know. I don't know how you feel about this, actually. I should ask you a do, but I think that graphic, I wish that graph y'all had a date time. Standard type.
Loren Sands-Ramshaw: [
00:25:41] Definitely. I think it's a,
swyx: [
00:25:43] some stage in the spec. Okay. Super annoying. It doesn't happen.
Yeah, so, I think Lee Byron has had arguments for why did kept it out. And definitely simpler is better for the initial success of graph. You would prefer would not be where it is today. If it had done all the things it had to really, really scope down and just solve a specific problem for Facebook and the early adopters.
Then it got big and then people want more out of it. This is the natural way of things is how it always goes. That's it. It's super annoying to work with the time in in graph QL and everyone has their own really weird spec. And we should probably standardize on that. I think relay seems to, relay seem kind of dead for a while.
And then it had a little bit of resurgence and people really like the the cursor format which which I think you briefly touch on as well. There's, there seems to be some amount of need for standardization of like, the way we do pagination, the way we do a bunch of things like even authorization as well.
I don't think it's really it's too. Left to influence that it's too hand-wavy. And so, yeah, which is, which kind of goes back to the solving backend developers, pain points, like having best practices that are sort of, well defended and in production at well-known companies that really gives a lot of assurance to the rest of us who are just trying to figure this out and trying to evaluate like, Oh, Hey, I have this thing that has worked for 15 years.
That's that happens to be rested. I can ship faster with that, or I can deal with this cutting-edge thing, which like I might make a critical mistake on. Sorry, my cat and my Comey. Exactly. So, nine times out of 10, the, I was going to say no, because it's just like, are you a dev just trying to play it a new toy or are you trying to ship, do you know how to ship things, which I've always worked in, nothing's broken about it.
So you really need to pave the path, which is something that obviously I do for a living, but Graffio has a lot of smart people working on that. Yeah. Did I answer the question about the future?
Well, Federation used to be a big sticking point and then they actually, came out with it. So I think it's less of a talking point now. And hopefully I, I haven't used it in any sort of work setting, so I don't know how actually people feel about it. All I know is that it was there were multiple competing solutions and now there's an official one.
Loren Sands-Ramshaw: [
00:27:48] So, I guess the last thing on graphica was app sync. I'm curious. But what kind of companies you see you saw using it? I guess I quick over here for people.
swyx: [
00:27:57] Okay. Absolutely. So graph yall tends to end up as a gateway meaning that it starts to wrap around other rest API starts to wrap around your other data services.
And then you start to that's as natural. In my view, state of where it should lie in your stack and then your front end sort of starts to query against the graphical gateway rather than your rest or API gateway. In Amazon's terminology, it is literally called API gateway, the most unimaginative name possible.
So, the graphical version of that is called app sync. Not graphically I'll get waived for whatever reason. And it really does essentially the same thing. You can define resolvers and resolve against data sources, whether the rest or a third party, or even then I can include a dynamo DB database, which there's a specialized schema for that.
We can, which is really intuitive to set up. And I, I think so, people are using that Amazon music, 30 million monthly active users, it's is based on that think there, there are some clients, I, big sort of consumer brand clients. And then there are a bunch of smaller smaller of a well-known names.
Like, orange theory is another one that, which we talk about a lot which is a gym that converted to like an online fitness training company during COVID that has like, that does like 2 million, monthly subscribers a month or something like that. And. And yeah, I it's used in production by the kind of companies that use AWS and they may not necessarily be, well-known names to developers, but they are successful businesses in an off their own.
Right. We also have a bunch of non-profits, which I really enjoy because it helped them get to market quicker. I feel like I, I still am still performing my role as AWS spokesperson here, but like, it really, I really enjoyed this cause like during COVID, a lot of people had to go online and a lot of nonprofits actually built out their apps using app sync and they got to market in like three weeks and, started serving people.
Like some of them were like homeless shelters. Some of them were like sort of critical medical care facilities and and. When you see the pace of development solve by, by, by this, by the service like you, you can get naturally very excited by them. And sorry. So let me get to the point.
The point is that you want a service, a graph, your service and either someone at your company is going to build it and it's going to be. Weird and funky and kind of, custom to your company or it's sort of, specked out and developed and scaled by someone like AWS or her Sera or Apollo, w whoever else does the graphic as a gateway service?
Because I, it could, because I just said like the backend stuff is the hard part. So when on, let someone else do that for you, that's the SME pitch. So yeah. Sorry. I feel really weirdly passionate about this just cause like it's a really fascinating investment. It'll be, this is the only big cloud to invest in graph you off.
As you're in Google and awareness on this and now Facebook is in the cloud. So, so, I feel like it, it has, maybe it doesn't get enough credit for like the amount that is really investing in making graphical a thing and making graphical easier for people to, to put it into production. I would say it's not the easiest thing in the world because it still has to encounter a lot of AWS hurdles, like, how do you deal with IAM policies and billing and all that which has its own sort of nightmares and EWS.
Nothing's perfect, but it's a trusted brand and it serves people who are familiar with AWS. It serves them well enough. Oh. One example. I think I really liked was a Yan tweet on Twitter. I don't know if you, if if you come across him he's actually done a bunch of tests and actually helped to help a bunch of clients build with ASIC.
And one of the interesting things is that graph Jaan natively has his subscription sort of. Paradigm association method, method which you can implement it with like long polling, whatever. But yeah, the high thing was serverless has been using has been developing serverless, which with WebSockets like having the scalability, serverless with the persistent connections or web sockets absent has this built in.
And so it's much easier to to develop sort of live apps, w. With the live reaction functionality that that website has give you with seeing them without, and to go pure serverless with API gateway. I'm sorry, I'm throwing a lot of jargon at you, but if you're in the AWS ecosystem, you know what that means?
Loren Sands-Ramshaw: [
00:31:42] No, I've. I've used it on one or two. What did they call it? Consulting gigs. And I
swyx: [
00:31:48] remember not understanding the UI
Loren Sands-Ramshaw: [
00:31:51] very well, like you're not feeling intuitively, but then being able to do most with like CloudFormation via the amplify CLI.
Yeah, that's a that's the common starting point which is like, if you just have a pretty common use case, I definitely recommend using a CLI then the more. Custom you get I would recommend checking out co CDK, the CAGR development kit where you can programmatically create confirmation resources to attach onto your API gateway.
And that's the migration path. You start with the CLI started out, building something simple, a proof of concept get familiar with the graphical schema definition, language that maps onto your resources. Like. And that's ultimately what you want. Right? You want your, the graphical, SDL SDL that you write to to do as much work for you.
So that means provisioning infrastructure in the backend and doing Kojin and the front end. Right. That's what, that's the ultimate dream of like do one thing, one source of truth. And it flows both ways. Right. And that's what I think, is. Building towards I'd definitely say it's not perfect.
Like, like exactly AWS will never win any awards, but the bar is very low for AWS. Like, all you have to do is to be in better than existing services that AWS has is not trying to win the world's best API for, compared to all the other startups out there. It just has to serve existing AWS customers.
Very well. So, so yeah that's kind of my perspective on that. Like, and like the core gen goes all the way down to the front end. So, EDSS has this sorry. Amplify has this idea of the data stores, which is on-device cache of your remote data, which is powered by your graph, your schema.
I remember
Loren Sands-Ramshaw: [
00:33:16] When Twitter figured out that JB amplify a client was based on a public client, but also had a lots of added things like offline.
swyx: [
00:33:25] Data. Yeah. And th this kind of thing is only possible with strong typing, right? Like w which is essentially what graph provides for you, strong typing of your backend schema.
And so once you have that, you can produce a front end replica of that, and then it works offline which is the kind of thing that you basically only possible by vertical integration. And if you don't, if you piece things together yourself, then you're on the hook for building all of that.
Which is pretty rough. So like, I just think it's amazing that they want an investment that's going into this. I feel like it's really rough to make easy and get right, because the surface area is massive, but but I think that the vision is correct. I think the vision of like, let's make this graph, Gail schema do everything.
Drive make it the source of truth and drive the whole app. And when you do migrations it's very easy to see what to regenerate the clients regenerate the backend infrastructure. That's the way you want to do things. Because if everything's disconnected, then you're essentially doing a lot of things twice.
Like, you change the schema. All right. Then you write the resolver then. Alright. Provision the infrastructure, the backend. These can all be done in one step. If you had tight integration any
Loren Sands-Ramshaw: [
00:34:25] final message you'd like to give to the readers in the graph? Yoga.
swyx: [
00:34:28] Enjoy the book and ask the authors for coverage of relay.
Cause I feel like there's a lot and no fault to you. Like I think graphic equals ecosystem is big enough and you already did a fantastic job of covering all of these things. I just feel like, Apollo is one perspective on what graft Cal could be. And there are very, very smart people that I really, really respect that love relay and I don't know anything about it and I wish I could read more about it.
Loren Sands-Ramshaw: [
00:34:51] I planned on adding at least a little bit about relay pursuant to your feedback. So thank you for that. And thank you for joining us today, Shawn.