Monoliths, GraphQL, Next.js, and DevRel Insights  ## Metadata - Author: [[Build and Learn]] - Full Title: Monoliths, GraphQL, Next.js, and DevRel Insights - Category: #podcasts - URL: https://share.snipd.com/episode/206afe3c-0861-4c32-abe4-478546515b2c ## Document Notes ## Highlights - **Monoliths vs API-driven Frontends** - Colin and CJ discuss the trade-offs between monolithic Rails apps vs API-driven frontends with React or Next.js. - They weigh maintaining large JSON payloads and finding dev talent as key decision factors. Transcript: Speaker 1 Oh my gosh. What do you have here? Couple of things like flew across my radar. And it's interesting because we've been talking about this internally too. So like how, what's the best way to implement your front end and your back end and should they be a monolith and there's a lot that goes into this and so there was one one article that came Out today from someone that said why I'm over GraphQL. So like why not to use GraphQL anymore. Then there was another question the Rails subreddit around recommendations for connecting a Rails app to a Next .js app. And internally, we've been having conversations about how, where we should build certain features. Should it be as part of the Rails app and part of the monolith, or should Rails expose an API and then we use a Next. Front -end to consume that? And so it's something I've been thinking a lot about. And one of the core, I don't know, one of the core decision pieces that go into this conversation is finding qualified employees. And so I think a lot of people are tending to choose React -based solutions because there is this idea that there's a lot more React devs, and so you can build more stuff with it. And I think there's definite concern for picking Rails because they're not sure if they're going to be able to find Rails devs. And it's like a chicken and egg problem, right? Like maybe we're not supporting juniors enough to grow the community big enough and fast enough to make this like a really sustainable ecosystem. Or maybe it's like a mismatch in terms of the expectation around, can you find a Rails dev or not? And yeah, I don't know. Speaker 2 Have you seen, there's been a lot of conversation I've been listening to like fairly technical with Ian Landsman and Aaron Francis and some others. There was a post from Taylor, uh, well from, from Laravel talking, it was like trying to compare next JS and Laravel, which are very different things. And what you're talking about is very true, but it also is like how much of it is the shiny new with JavaScript stuff? Like JavaScript seems to always have a new thing and people are jumping around and he had a shot fired at it. Feels like an ad for clerk for authentication as a service companies. And whereas you go to jump into layer of all rails and it's batteries included. If you're, even if you're not using jumpstart, you can jump into device and all these different things. And you, I think a lot of JavaScript people when they're new to it, don't enjoy like how many files something might take to implement, but in a layer of L app and in a rails app where things Are stored and kept and it's like, what drawer is this in? And in JavaScript, yes, there's probably a perception of more react devs and things, because you have a lot more bootcamp grads and just a lot of courses and stuff teaching it. We talked about it last episode with the last RailsConf being next year. What does that mean for the perception of Rails? And you have all these React conferences, but I don't think most programmers are going to any of these conferences, right? It's a small subset of very online people who are also going to these conferences. And you have developers all over the world just being productive in their tools. It's an interesting argument. I don't know which one I'd go for. I do think like when we were at orbit, we were all Rails based. We started before I joined. Was a front -end JavaScript app with a backend API separate, and apparently it took them way longer to do anything because they had to make sure they built that contract between the front -end and the backend, and they had to implement it, and it almost felt like you were implementing the same features twice to get things done. Speaker 1 One idea that I keep coming to, whether you build your front end with React or not, is around this idea of using stuff that's built into the browser as much as possible. And what I mean by that is that like, when you're building a form that is going to submit some data to the server, right, there are conventions that have been around since the beginning Of post requests on the internet. And if you choose to build a form that follows the same conventions that the internet has been using for a very long time, then the code just feels so much more robust and reliable and dependable. And so I find when we start layering on these big, heavy front -end frameworks like React or, and I would even put in some regard like Rails form helpers in this bucket. But anytime we start adding layers into the front end, including Turbo, including whatever, we are introducing complexity that is going to be hard to track down when things break. It's going to introduce complexity around state management. And yeah, it just gets gnarly. And so we're finding ourselves in a world where there's just so many different options from the React side. What form library are you going to use? And then what validation library are you going to use? And how are you going to manage your HTTP request? So you're going to use React query, are you going to use a GraphQL thing? And then that's all just assuming React is the front end. Side component to your front end where like maybe your next JS backend is the thing that's actually calling your Rails API or maybe your next JS front end is the thing calling Rails API Or whatever the backend API is. But one thing that I really like about Laravel and Rails and Django and sort ([Time 0:05:14](https://share.snipd.com/snip/24c008f3-1f4f-43d0-91f5-7c44721eff6d)) - **Favor Browser-Native Code for Maintenance** - Using native browser conventions for forms makes code more maintainable and robust. - Adding layers like React or Turbo often introduces complex state management and debugging challenges. Transcript: Speaker 1 Idea that I keep coming to, whether you build your front end with React or not, is around this idea of using stuff that's built into the browser as much as possible. And what I mean by that is that like, when you're building a form that is going to submit some data to the server, right, there are conventions that have been around since the beginning Of post requests on the internet. And if you choose to build a form that follows the same conventions that the internet has been using for a very long time, then the code just feels so much more robust and reliable and dependable. And so I find when we start layering on these big, heavy front -end frameworks like React or, and I would even put in some regard like Rails form helpers in this bucket. But anytime we start adding layers into the front end, including Turbo, including whatever, we are introducing complexity that is going to be hard to track down when things break. It's going to introduce complexity around state management. And yeah, it just gets gnarly. And so we're finding ourselves in a world where there's just so many different options from the React side. What form library are you going to use? And then what validation library are you going to use? And how are you going to manage your HTTP request? So you're going to use React query, are you going to use a GraphQL thing? And then that's all just assuming React is the front end. Side component to your front end where like maybe your next JS backend is the thing that's actually calling your Rails API or maybe your next JS front end is the thing calling Rails API Or whatever the backend API is. But one thing that I really like about Laravel and Rails and Django and sort of these older monolithic frameworks in addition to all the batteries included stuff is because they've Been around so long, they're built around the same fundamentals of the basics that you get from the browser instead of layering on a lot of additional meta ([Time 0:09:02](https://share.snipd.com/snip/9e737fc7-9f75-4f53-abb9-7f20930066d6)) - **GraphQL's Pros and Cons Explored** - GraphQL allows clients to request only needed fields, reducing over-fetching. - But challenges with rate limiting and authorization make it difficult to maintain effectively compared to REST. Transcript: Speaker 1 Though. I think, yeah, I know we messed around with it a little bit at Panty Drop, but yeah, I think it was a fun idea, but haven't used it since then. Speaker 2 So debate, I think it's just, it's really cool to be able to do these queries that you can reduce and return only what you want. There's a lot of promise there that sometimes if, when you're doing rest, you don't get control over what comes back and you might have to make multiple calls to get what you need. And then you're building your own little map on your, on the side to keep track of what you need. What happens if one of those requests fails? There's all sorts of things that can happen there. So I think it's really cool. I almost wish that we could just in rest define what fields we want back and stuff like that, but then I guess you're like rebuilding GraphQL. So yeah, I hadn't had time to read this blog post, but I think a lot of people are over GraphQL. Speaker 1 Yeah, there were, I think there's just like a handful of gotchas with GraphQL that this blog post, I think articulates pretty well. And yeah, authorization rate limiting. If you just scan the headings here, we'll share the link in the show notes, but there is just a set of problems that you run into that are standard across the board. And yeah, I don't think anyone's really found like a great answer to those. But did you ever get your hands on OData back in the day? Or are you familiar with that? No. Okay. Have only been in Microsoft thing and it's basically like a GraphQL thing, but from the front end. And you could write like these interesting queries that were passed basically in query string and it would give you back like your filtered data. And I remember when I first saw this, I was like, this is so cool. I love this. And yeah, it's like similar idea to expand in a way, which is a feature of the Stripe API where you can pass, okay, I want this object and I want to expand this other thing so that it's included In the response. Speaker 2 Of expand is so good. Yeah, totally. Speaker 1 But it's also insanely expensive to maintain that because if you build your integration and you're expanding, but you don't actually need the expanded objects. It's waste. That's like increasing. Yeah, it's a waste. It's like increasing the latency in the overhead for the API and the maintainers, the API. One of the cool things that I've that I love about GraphQL is that I think there's this thing where you can say, here's the properties I need. And from the server, you can understand what the client is actually requesting. Right? So if the client only tells you I need three fields and maybe another client tells you they need three different fields, but maybe you're returning like you're, or you're generating Potentially 20. But that you can safely remove the fields that aren't included there, which gives you like these awesome performance gains so that you can just like strip down and understand that you're Not gonna break clients because they're being explicit about what exact fields they want from you. And that's a problem we have today because now we are using, we have a rest API the rail side and in order to avoid too much stitching together of different resources on the front end, some Of our REST endpoints return these giant blobs of here's your project and all the photos and all the tasks and all the statuses and all the people that are involved and all the whatever's With their avatars and all their like, work history and whatever. And so you get these like huge things. It's like basically just a Jason blob of your database between certain date ranges or something. And that also isn't great. In fact, we like ran into an error the other day where for cell and next. Yes. We're throwing an error because the payload was too big. It was like, I don't know if it was five. Yeah. It was like five megs or something just for some a TRPC Call and it was just crashing because there's just too much in the JSON blob. And yeah, it is a really it's a really tough problem to solve and Yeah, so that same rest endpoint, right if we want to go and thin it out or make it more optimized or cash certain parts of It Or whatever we have to be super careful because we don't want to break one of our calendars that's backed by that API. We also don't want to break the mobile app that's based on that API. We don't want to break the front end like marketing site that's based on that API. It definitely makes it more challenging when just using vanilla rest and ([Time 0:13:36](https://share.snipd.com/snip/b7ff7406-b29b-4539-bba9-1855b02bfc98)) - **DIY Solar and Wood Pool Heaters** - CJ is building a DIY solar pool heater using black irrigation tubing and a solar-powered pump. - He plans a second iteration with a wood-fired drum heater to keep his pool warm affordably. Transcript: Speaker 1 Is building something else. I don't know. What are you building? Yeah. Tell me. Yeah. So we opened our pool as early as possible. It was like the day that we didn't see any more freezing temperatures on the calendar. We opened it. But that means that it was like 40 degrees or something when we opened it up. And the pool here in New England stays pretty cold throughout the summer. And it's a very old pool. It's built probably in the late 70s, early 80s. And so it's very simple. It has a pump with a filter and two little inlets and outlets, no heater. And so it's been my idea for a long time to build like some sort of heater for the pool so that we can make it a temperature that is livable. And we're excited to go out and spend some time in. Right now it's very refreshing if you're out in the yard doing some work and you just want to take a dip, you can splash it. But yeah, pool heaters, like if you buy like a proper pool heater, it's pretty expensive. And so I had these DIY ideas around a couple different iterations of this. So the first one we're going to do is a solar based pool heater. So I got like a bunch of irrigation tubing, just like black irrigation tubing, we're going to coil it up and maybe we'll like spray paint the thing we're gonna mount it on black also and Then just like a solar panel will point it at the Sun and then we'll have it a little pump that sucks the water out of the pool it runs it through these coils basically of irrigation piping And then goes back into the pool and Yeah, the idea being that ideally the pump is also solar powered. I don't want to spend electricity on this, but But you also wanted it to be safe. Speaker 2 And yes. Is the plan to have it continuously pump? Speaker 1 I think it would, it depends on, yeah, I think it depends on the temperature outside. If the temperature drops below a certain mark, then it probably doesn't make sense to run it. And we do have a lot of gloomy days where it doesn't make sense to run it. Speaker 2 Yeah, it probably makes sense to have it heat up in a storage and then circulate out and then bring in new water. It's a little more complicated because if it's constantly circulating it probably isn't gonna heat up fast enough when it goes through the coils. Speaker 1 Yeah, it totally depends on how fast it's pumping through. Yeah. And how much storage. So if we end up building just a giant black PBC pipe or thing with big, maybe like three inch pipes or something. Yeah, exactly. So that's the first iteration. And then the second iteration is a wood fire one where we'll just get like a drum like a 50 gallon drum and then wrap it with copper and Then put fire in it. Speaker 2 There's some really good tutorials on this for hot tubs. Speaker 1 Yes Yes, that's where I got the idea is like the hot tub version. Yeah, that'll be fun, too I think like technically there's some physics where you can make it work without a pump right? We're like just the heat. Yep As the heat rises. Yeah. Exactly. Yeah. Speaker 2 You're not gonna get that with pure solar, I don't think, unless it's like really hot. Right. Exactly. Speaker 1 Yeah. There's also, I think like the examples that I saw at least of the hot tub version, the top of the drum was always level with the hot tub. And so the water could come out the bottom of the hot tub and then go back in the top of the hot tub, but the pool is in the ground. So like in order to get that same sort of like gravity fed piece to suck into the pipe, we would need to bury part of it or something. I don't know. There's definitely some physics that needs to happen ([Time 0:19:45](https://share.snipd.com/snip/2fa93679-a1f3-48f6-bb56-bdaa244d4135)) - **Reno Tahoe Relay Race Prep** - CJ prepares for the Reno Tahoe Odyssey relay race by training for an uphill 8-mile leg. - He balances running with health concerns and uses special gear to manage the challenging conditions. Transcript: Speaker 1 We've talked about you running in the past. I think even last year when you ran the RTO, we talked about it. The same crew? Do you know what legs you're running? Speaker 2 Yeah, it's tomorrow. I've got same kind of crew. I'm part of this beer running club called the McKeller Running Group, which has like meetups around the world. So we have a crew here. So I'm doing it with them because it's a pretty chill group. They just want to run. They're not worried about how fast we do it. But I am doing the hardest leg to share. So we will see how that goes. But doing the first the first run of the first leg is eight miles and six of it is uphill and it will probably be at The hottest time of the day tomorrow. So just gonna get through that one and then my other two are like at night and easy and We'll be good, but I've got a bandana that you put ice in it's like specially designed for that So I've Got that ready because it's there's a little bit of shade but not until you get to like mile So I got to run uphill in the sun for a good six miles. And I mean, it's like 1500 feet over six miles. So it's quite a bit, but yeah, ready for that. Took most of the day off tomorrow to do that and into the weekend. So we'll, we're estimating it'll take us about 24 hours. Like it usually does to do the whole thing. Speaker 1 And are you, are you practicing running uphill right now? Speaker 2 Is that, yeah, I live downtown and so most of my running is usually like, just getting it in is running on the river and there's no uphill whatsoever. And it's good to get out and get cardio, but you don't get any I forgot the phrase but like you basically earn your stripes on the hills and then when you go do races like usually they're Not that insane. So I've been doing a lot of trail running up above Reno where some of them is you can't run you have to end up hiking but you're still heart rates high. Anytime you look at like ultra trail races, it's a lot of hiking and then you run when you can and you've got like these really cool, like collapsible hiking poles that you need to take With you and stuff. So it's not that bad. The run tomorrow is just like a gradual mountain, like fire road, but it's good to go do those and then makes other things feel easier. That'll be good. But I'm actually moving up to that area soon. So I'll be able to like just run from my front door out into those trails, which is going to be nice. I'm trying to still balance the like how much time I spend away ([Time 0:24:44](https://share.snipd.com/snip/1bee8bc6-b558-414a-aa7d-c8390700d7c0)) - **Challenges and Roles in DevRel** - Developer Relations roles vary widely and involve balancing content, community, and internal advocacy. - Burnout is common due to the reactive and multifaceted nature of DevRel work. Transcript: Speaker 2 Tragg, but I've been thinking a lot about DevRel, which is interesting. So developer relations for anyone who hasn't heard that term, but really like advocating for DevRel internally and just making the case for, for this. And Tragg has this little cartoon that he put together on LinkedIn and the office meme of what is it that you do here is very timely because. Devrel is very different at every company. And I think I came across a quote from, I think it was Kelsey Hightower that was like, Devrel is whatever the person paying you says it is. And I understand that because that's who's paying the bills, but I also think that there's some like first principles that you have to think about. Yes, and it's, yes, it's whatever. Every company is different, but at the same time, there's still these tried and true things. And we're very different. I think we've talked about this before. Like we do a lot of product launches. We do a lot of working with engineers as they're developing products and features to make sure that they're going to have a good developer experience. And we don't do a lot of the content creations, going to talks type of DevRel, which is very, it's a different flavor. It's very valid. Some teams have the person who goes to conferences, the person who does content, the person who the internal stuff, maybe slightly sales engineer, dev rel type thing too. And there's only two of us at Discord. So we're doing like a roadshow where we go to all of our, all the different functions of the company and teach people what we do and how to like interface with us. And that's just making me think a lot more about what do we want it to be? What do we want to do in the future? What have we always done? What are we doing today? And so immersing myself in DevRel, meta world for a little bit of, go we're going to go to DevRel Con in July. I've been reading a lot of just blog posts from Slack and Stripe and all those kinds of things. I have my own opinions, but I'll start trying to evolve some of those opinions and maybe put them into action. Nice. Speaker 1 I definitely struggled a little bit with how to balance between all those different flavors of DevRel and not just try to do all of them at once and lean into the ones that you're good at. Also something that I learned from Trag when he was my manager was this fact about how common burnout is in dev rel and that like usually people only last 18 months or whatever and then They switch. They came into it from an engineering role or they're going out of it into an engineering role or they came into it from product manager type role or technical writer or documentarian. And then, yeah, and then maybe they leave or maybe they leave as a documentarian, maybe they leave as a product manager, but I think that he did a great job as the manager of making it a marathon And making sure that everyone was feeling productive. And I think his mindfulness around that was really powerful for our team at that time. And yeah, I've definitely seen some other organizations where that is not true. And they have a lot more churn in the DevRel team. But yeah. Speaker 2 Like at Discord, like we don't have a DevRel manager like track. We are embedded on an engineering team, which is great. Like I would prefer to be on engineering over marketing marketing is important. But unfortunately, like working at orbit, we saw DevRel teams of all sizes and types and making a single product for DevRel was hard when it doesn't look the same at every company and The goals are different. Even KPIs like we're, it hard pressed to define actual metrics for what we do. Like we know what we do. But then when you get asked what do you do, it's so many little things. Like oftentimes it's reactive comms. Sometimes it's proactive, long -term thinking. Usually we don't get as much time for that as we all probably want. The burnout is interesting because if you're an engineer, like I would say that's, that's a difficult job, but it's different in that you know what things you need to do. And maybe there's some surprises, but like for the most part you have maybe tickets or things that you need to get done, but you don't have community also to think about as much. I think you still should. You hopefully have a connection to the customer and stuff like that. But sometimes we just have to put out some fires in the community. And sometimes our tooling that something happens in our SDK, every SDK that we release, every new surface we release is like more surface areas. Yeah. Just trying to quantify that and think it'll help when we get to like performance reviews again, and just thinking backwards from that. What do we ([Time 0:29:25](https://share.snipd.com/snip/8d0981a2-345f-4391-bd1a-ff77dd930e49)) - **Creation Focus Helps DevRel Impact** - Creation-focused DevRel produces measurable public artifacts like videos and blog posts. - This focus helps justify DevRel’s impact better than reactive internal support tasks alone. Transcript: Speaker 1 In hindsight, I'm really grateful for the flavor of DevRel that I tended to lean towards was the creation one. And there's, that creates so many like publicly visible artifacts that at the end of the, at the end of the performance cycle or whatever, it was easy to be like, okay, here's 35 videos That I made and five blog posts and whatever. And which is much harder when it's, okay, yeah, I'm doing these internal docs things that we can't even release because the product isn't ready. That's, or, oh, I spent five weeks of my time this quarter triaging things in, yeah, in like Discord support while working with developers, trying to help them integrate. That's like much harder to show different activities. Speaker 2 Right. Docks is even tricky because it's like, there is that, can a developer do the thing, yes or no. But also different developers may not be able to do the thing just depending on their background. And they may not have used something similar. So like, I think like I got something similar when we really started SDK for activities. There was like a quote was like the docs were a little weird before. And now they're, now they're good. And I was like, okay, I would have put that in my performance review. I guess that's a good review. But, and I've seen like in Stripe you have, they've got all sorts of like things that each page where it's, was this page helpful? Was it missing anything? That kind of stuff I'd like us to do so that we can get a little bit better sense of the journey. And we know that if you land on the docks today, you need to go world build on your own and we need to do some world building ourselves. But trying to get into some generation of reference docks and stuff so that right now they're all handwritten. It's pretty painful. So if we can clear our plate of that, then it gives us more time to write out the customer like developer journey maybe to start getting into video we really want to do video but video as It's expensive to maintain expensive to create if anything goes out of date the suddenly the videos are out of date and so they're not as easy to go find where and when and all of that someone Speaker 1 Can crack that nut that would be great just make a product that makes a maintainable video that you can push updates to. Speaker 2 It's like a bunch of road signs, get video, right? It's okay, we're gonna rebase this one, merge. This was good up until here and drop in a new one. Maybe this is where like using a Vtuber avatar or something is useful. This is edit the script and drop in the new screenshots. We're done. Speaker 1 Yeah. Yeah. So have you seen the React video thing? I think it's called React video. There's some tool that lets you build videos with ([Time 0:34:17](https://share.snipd.com/snip/382feae6-b02e-4a81-8484-263499a1d042)) - **Automate DevRel Video Creation** - Use tools like Remotion to programmatically create and update maintainable videos for documentation. - Automate video production to easily push updates without costly re-shoots or edits. Transcript: Speaker 2 We're done. Speaker 1 Yeah. Yeah. So have you seen the React video thing? I think it's called React video. There's some tool that lets you build videos with React. Interesting. Here we are back on the React train. React? I don't know if it's video React. It's like it generates... Speaker 2 Remotion. Speaker 1 Yeah, that's it. Yeah. Yeah, remotion. This is pretty sweet. And my like, one of my ideas a long time ago was like, use remotion to build the video in code. And you could use like code snippets in all the different languages that you support for your SDK. Then write your script, and then you can have your script translated to other spoken languages. And then you can just spit out just like this giant multiplexed like set of videos that get uploaded and just, it's the same simple topic. But it's then and also then you could make a PR to it, right? Speaker 2 And then if you could drop in a new explainer new screenshots. Yeah, interesting. There's always another thing to do Yes, always What do you say should we call it there I think that'll do it enjoy enjoy the heat pump experiments I'm curious to follow along. ([Time 0:36:50](https://share.snipd.com/snip/376e8ecd-8170-47bf-b34b-22bb1134fd43))