EPISODE 1749

[INTRODUCTION]

[00:00:01] ANNOUNCER: GraphQL is an open-source query language for APIs and a runtime for executing those queries. It was developed by Facebook to address the problem of over-fetching or under-fetching data, which is a common issue with traditional REST APIs. Matt Bessey is a principal engineer and software architect. Earlier this year, Matt wrote a blog post titled Why, after 6 years, I'm over GraphQL. The post put words to many user's frustrations with the technology. And it went viral on Hacker News. Matt joins the show today to talk about GraphQL, the problems it solves, its security vulnerabilities, and why it might not be a good fit for backend engineering today. You can find a link to Matt's blog post in our show notes. 

Gregor Vand is a security-focused technologist and is the founder and CTO of Mailpass. Previously, Gregor was a CTO across cybersecurity, cyber insurance and general software engineering companies. He has been based in Asia-Pacific for almost a decade and can be found via his profile at vand.hk.

[INTERVIEW]

[00:01:14] GV: Hi, Matt. Welcome to Software Engineering Daily. 

[00:01:18] MB: Hello. 

[00:01:18] GV: Yeah. Matt, we're excited to have you on today. What sort of caught our attention at SE Daily was what ended up becoming a very popular Hacker News article that surfaced that you wrote. And the sort of topic was GraphQL today. And sort of you've been working with it for about six years. And this was sort of your analysis of where things were at today. It's a topic I've been following for a little while. And I think just when your article popped up, that was the time that I thought, "Yeah, I think it's not just me thinking some things. There are some other people thinking some things, which was very interesting. Before we just dive in, maybe could you just give a quick kind of background in terms of your programming history? Just sort of what led you up to the point that you actually wrote that article?

[00:02:06] MB: Yeah. Absolutely. Yeah. First of all, I was a computer science undergrad at Bristol University in about 2010. I wanted to be a games developer. And my elder brother said, "Don't do that. Or at least don't study that degree. Do something a bit more broad and keep your options open." And so, I owe him a lot for making sure I did that. Because in the end, I went straight into web development and been very happy in that world ever since for a good, yeah, 10-plus years now in industry. Got to work through the explosion of SPAs and React becoming the dominant force. And, yeah, things like GraphQL then popping up to work well with that tooling. And then kind of as DHH would say, "Watch the pendulum swing back in more recent years towards kind of traditional server-side rendering approaches and putting a priority on simplicity rather than using the big tools that big tech have created for their big problems that we don't necessarily have. 

[00:03:04] GV: I think before we got to get into the detail of the article, there's probably a lot of people listening today who have never – most of us, including myself, have never experienced the whole even thing of you write something and it gets daily top 10 on Hacker News. Why did you actually write this article? And what was the sort of thinking behind the why? Yeah. Curious about that.

[00:03:28] MB: Yeah. The motivation for writing it, I guess it had been kicking around in my head for a good year or two. I think, at Immersive Labs, we'd kind of fallen out of love with GraphQL over time. But we used it for about four years there. And I used it for a few more years in a previous role. And, really, we felt that we'd had a turning point where it was slowing us down. Not speeding us up. That we were constantly – it's the topic of discussions at backend state of play meetings. And all the time, dominating over other things. 

And at that point, we started looking at alternatives for a greenfield project. We had the fortunate position of having a well-defined new project. I won't get too much into it. But, essentially, a good place to go. Maybe this would be a good chance to try different approaches. Yeah, did a bunch of research. Played with OpenAPI. And we're pleased with the results that we saw.

[00:04:24] GV: Yeah. Again, before we get to detail. Just, again, how does it sort of feel I guess to have something that actually ends up getting upvoted quite so strongly? And I can't remember what it was. But maybe top five or top 10 in that given day. How does that feel? 

[00:04:42] MB: I'd be lying if I said I didn't hover on the HN front page for a few hours occasionally refreshing, watching it dance up and down. Yeah, I've certainly never had anything like that before. I tried to follow that article up for a few weeks later and I literally got zero. Whatever lightning I got in that bottle doesn't seem repeatable so far. But I didn't expect it by any means. I'm really happy to see the level of traction it's gotten around. Certainly, yeah, the nicest thing really has been speaking to colleagues who I haven't worked with for five, six years who turn up in their company engineering chats and reach out going, "I know that guy." Yeah, it's been pleasurable.

[00:05:21] GV: Exactly. I think that's nice. At the end of the day, that's it. You can sort of expect to just keep sort of writing things and everything gets sort of attention. I think that what I personally I love about Hacker News is just it feels quite meritocratic maybe. I don't know if some people would sort of – but that's kind of how it feels that you can have had zero interest from anyone on anything that you've done before potentially and suddenly. 

[00:05:46] MB: Yeah. I totally agree. On that topic, I would say one interesting thing I noticed in the aftermath of the article was I kind of read through the Discourse on the various platforms that it had gotten a lot of traction on. And I've always kind of felt anecdotally that the quality of Discourse on Hacker News is significantly higher bar than Reddit and certainly YouTube comments. No one's reading YouTube com – I hope no one's reading YouTube comments for engineering advice. Yeah, I got to see that Discourse play out on all those platforms and see really how high-quality. A lot of challenges. I didn't necessarily agree with everyone. But a lot of really good, thoughtful takes on the article on HN in particular.

[00:06:27] GV: Yeah. I completely agree. It's why it's for me. I have no affiliation with Hacker News. But it's definitely a daily for me. And I totally agree, I actively go into the comments and like to understand how people are thinking about things. And particularly, actually, for your article, yeah, I thought a lot of the sort of top comments and rebuttals were really interesting. We've talked just about the fact it was an article and it's quite popular. Let's get into it. 

At the end of the day, you focused a lot on GraphQL. Or the entirety of the article was GraphQL today. And for everyone today, it's still going to be different reasons why they might choose it for a project today. Why they may even retrofit it today. But at least from where I sit, many years ago, it was almost if you didn't consider GraphQL or if you didn't adopt it, that was the why. Why you're not using GraphQL? After six years of experience with GraphQL, let's kind of get into it. What were the overarching factors that led you to sort of reconsider its use in projects that you're working on at the time? 

[00:07:37] MB: Yeah. The high-level I guess is – or the executive summary is incidental complexity for the backend in particular. I think there's a lot to love about frontend experience of GraphQL. I don't really have much – yeah, I don't think there's much to say about the frontend that's negative. It is a delightful experience for frontend engineers who don't want to talk to backend engineers, which I think is a bit of a separate, not healthy thing that we can come on to later. 

But, yes, there's just a ton of incidental complexity for the backend engineers. It's very hard to write performant GraphQL. You can write things that are performant and then become not performant because your client changes how they function in the future. And without you changing a line of backend code, suddenly your backend is a thousand times too slow. And similarly, it's very hard to write secure GraphQL. We found massive amounts in the cybersecurity industry. Perhaps we feel this more than most with internal pen testing and external pen testing. But we would reliably get security issues that were completely unique to GraphQL and only have to be solved for GraphQL. And as a result, yeah, we just found ourselves – I mean, we're going to say GraphQL a lot in this podcast. But we found ourselves talking about this thing that is kind of just supposed to be a tool in the tool box way more than any other tool in our tool box. Yeah. That's kind of the negative side of things. 

On the positive side, the rest of the ecosystem improved a lot. Everything outside of the GraphQL world. GraphQL kind of popularized or made us see how good having a strongly-typed, statically-typed client is or client generation is for frontenders. Being able to hit that dot and see every property that is in your API response and be confident that they're definitely there in the age of TypeScript was a fantastic experience. And so, yeah, the rest of the world improved. The cracks started to show a bit more for GraphQL and that's what kind of caused us to evaluate other options. 

[00:09:35] GV: Yeah. I think what you touched on to start with is a really useful point, which is I guess a lot of this does relate to who's consuming the API and who's producing the API. And as you kind of touched on the consumption part, the I.E. frontend developers, that's probably why my feeling is probably GraphQL was pushed more from the frontend team saying this thing will make life so much easier. And, "Hey, backend teams, how can you make this possible?" 

And however that happened, then that's been kind of adopted. Or adopted is a sort of polite term. Maybe some teams were almost forced. Backend teams were forced to kind of use it. One of the key areas you just talked about was the security side. And given, at the time, you were working in a cyber security company. Let's talk a little bit about attack surface. Can we just sort of – maybe if you just give a brief explanation of attack surface. We have covered it in other episodes. But can't assume anything in terms of what our listeners have listened to before this episode. And then how does GraphQL differ to REST APIs in that sense? 

[00:10:53] MB: Yeah. My description of an attack surface I guess would be the more ways you have to call an API, the more ways you have to attack it. And every feature of an API of a product or whatever is also a security risk of that thing. And so, when I think of a attack surface, I mostly think about the number of things you can do with a tool, with a product. If it only does one thing, then it can probably only be broken in one way. Maybe not one way. But far fewer ways than something that has lots of ways. 

A very shoehorned example would be if you have a house with 20 doors and 100 windows, you're probably going to get burgled more than someone who has one door and four windows. What do they say in America? Burglarized, if that's more your speed. Yeah. In REST, there's a very finite way of a number of ways to call your system. You can call them endpoints or routes. But you have a set of routes that they are fixed for the most part. Maybe you've got some dynamic ID sections in your routes. But there is a finite set of those routes probably defined in your route or somewhere in your backend. 

Whereas with GraphQL, the QL – we're probably going to be saying this a lot today. The QL stands for query language. And that means that there are many, if not an infinite number of ways that you can call the API. And, therefore, many, if not infinite ways that you need to think about how to defend against unexpected uses of your API. And maybe infinite sounds absurd. But for example, even just say you create a brand-new GraphQL server that has no – you've declared no types. It has no fields. You haven't done anything. Even just the introspections schema alone, the system by which clients can get that nice typed client generation out, even that has an infinite number of ways by my reckoning. Because it has cycles in its graph. You can pull a type and then you can ask for what other types could that type be. And then what other types could that type be? And recurses forever. Even before you've written your first field, you've already got an infinite API surface. Perhaps a little exaggerated, right? The loop doesn't necessarily add infinite ways to attack it. But it certainly expands the number of possible attacks that you might have to deal with. 

[00:13:15] GV: Yeah. I think that's a good way to describe it. Some of our listeners won't be familiar with APIs kind of at all. And, yeah, at the end of the day, a REST API, you're sort of calling a very specific address you could almost say. A very specific address with a very specific sort of purpose. And what is returned is largely governed by the server. It's a little bit difficult to know how to – if I say game the system. I mean, we're talking about hacking basically. But game a REST API, quite difficult. With GraphQL, as you call that, Matt, QL, query language. All these permutations of what you could pass in. And that was supposed to be sort of the reason it was great. Oh, actually, server, you don't need to create 100 endpoints. One endpoint with 100 possibilities. But the possibilities of course were not 100. They were probably 100,000 or more. 

And just a sort of sidebar, I once interviewed an engineer and I sort of said, "What are you most proud of?" And they talked about this REST API that they had created that was actually following, I believe. At one point, there was an app called Ghost and their API allowed you to pass in parameters. And these parameters – which a lot of REST APIs do. But the sort of flexibility with the parameters was quite high. And it sort of looked almost a bit like MySQL inside a REST API endpoint. 

And I said, "Oh, wow. This is very interesting. Did you think about the security considerations with this endpoint?" And their answer was no. And, obviously, I sort of understood what GraphQL was as well. But I thought that was very interesting. Just that it maybe has a little bit misunderstood why REST is what it is. There are two sides to it. The consumption, the projection. Yeah. And I think you touched on that well, Matt, in terms of what the differences here.

The article you wrote, it mentions authorization as a sort of significant challenge in GraphQL. Maybe, yeah, could you just sort of elaborate on some of the complexities in implementing what we might sort of call proper authorization via a GraphQL API? 

[00:15:22] MB: Yeah. Again, I think it's useful for us to start with the REST world, the traditional, and then compare how it works in the GraphQL world. And if you bother doing it. In REST, you generally – I guess we can come on to your example there where you have heavily parameterized endpoints. But if you have a simple enough endpoint, like you get /articles, /123, gets you article 1, 2, 3. You authorize mostly on each endpoint. If I hit that get, you know that controller has a fixed implementation that the user doesn't can't influence what it does. And so, we can say, "Right. We need to check that this user can look at article number 1, 2, 3. That's one and done." 

Now we might nest data inside of it. For example, if you've got an article with a comment section, then we just put the comments data in the article's response so that we don't have to fetch things twice. But that's a backend decision. The frontend doesn't control that. And so, as a backend, you can say, "Well, I know that if you're allowed to see an article, you're also allowed to read all the comments on the article." Again, I don't need to do any more of. They've gotten through the front door of this end point. From here on, we can assume that that person has been authorized. 

But GraphQL, QL is query language. If you take an example, say, the equivalent example in GraphQL, you'd have a query with a top-level field called article that takes a parameter or an argument rather of ID. Article ID is 1, 2, 3. That's fine. We have an authorization check on that object's resolver in the schema. It will check that you have permission to look at article 1, 2, 3. The problem is, since it's a query language, we can fetch any other resources that are exposed by the article type in the type system, which, yeah, may include comments. But it may also include, I don't know, banned comments or flagged comments, spam comments, all these things that are like admin-side things that wouldn't have been exposed in your previous REST route but are theoretically exposed in GraphQL. Because you can – anywhere that's on graph, you can get to as a query. And that goes recursively. If you manage to get to an author, maybe you can now get into personal information about that author that's in their private profile. Et cetera. Et cetera.

Yeah, that's the issue that you have with authorization in GraphQL is that it has to be done realistically. You need to do it on every leaf of the response on every object that comes through. And, certainly, I think it's obvious that you need to do it on objects. An object is kind of a row in a database generally speaking. But what might not be obvious is there will also be times you need to do it on individual Scala values in that response. 

For example, again, going back to the account type. An account has an email. And maybe that's private information. There's a display handle that's public. But there's an email that's private. And so, we can't just say, "Can I view the account?" Okay. Then I can stop auth now. All of the fields that is exposed is a fair game. I have to do auth checks on every single leaf to be confident that this person is allowed to see that stuff. And you can see that this is a lot more work than the odds that you have more REST end points than you have fields on types is pretty low. Yeah, it just ends up being a lot of work. 

In my last role, I just spent a lot of time on performance in the last year or two looking at APM traces of slow GraphQL requests. And most of the time, I would find that authorization was the slowest thing that we were having problems with. Because you can't rely on humans to remember to do these things. In my view, you need a framework that ensures that you are secure by default. And it's a human's job to say, "No. I know better than you, framework. I'll disable auth in this case." So you end up with authorization calls happening everywhere. If you're returning a list of 100 things, every single item in that list needs to be authorized individually. And if those things are also pulling more data, you end up with this sort of exponentiation of one query is doing a thousand authorization calls. Each of which may end up hitting the database to work out the answer of can they look at this. And so, you end up with, yeah, your classic N+1 thousands of queries. Just to answer, "Can this person view this data that we've already fetched?" We did that ages ago. That was actually quite fast. But making sure that they're allowed to see it is way slower. 

[00:19:57] GV: Yeah. This is just a really interesting and great point. I've often found we're sort of almost talking about zero trust here a little bit when it comes to how GraphQL looks at it, which is, "Hey, you've got access to this endpoint. And you sort of have wide access on that endpoint." But after that, what should you have access to? And I've often thought the airport analogy is quite good for that. Where you have a boarding path and you pass through security. Let's look at that as sort of you've accessed the endpoint. Great. Well, what can you now do? You're actually only – that boarding pass actually says, "Well, actually, you're only allowed to get on this one flight at this one time and has a one seat that's assigned to you." But, technically, you could go try a whole bunch of other places. And the time that it would take for the people to check and say, "No, this is not where you're supposed to be." Or, "What are you doing?" 

And if we take the REST API example, that's – although I don't say I approve of the method, it's effectively the private jet. It's sort of saying, "Hey, you have this direct access to this thing. And you kind of head straight through. You get on the plane. And that's it. You didn't need to pass through 100 gate checks effectively to kind of get there." I think, yeah, it's a really interesting point where – and from the developer perspective, as a backend developer, every time you sort of expose an endpoint from the REST side, you're almost being forced to kind of question yourself on, "Well, hang on. Who should have access to this very specific thing?" 

Whereas with GraphQL, you naturally are going to maybe miss some cases or sort of think, "Oh, well, this is fine." I think the example you just gave was article and comments. And instead of the, "Oh, actually, they shouldn't have access to comments. Or they shouldn't have access to the flags on comets." Yeah, it becomes a sort of afterthought. I think that's a really good example. 

Just sticking with security kind of for a second. Yeah, the article also touches on query parsing vulnerabilities. Can you maybe just sort of explain this issue a little bit sort of further? And what are the solutions there? 

[00:22:04] MB: Yeah. Absolutely. Again, QL, query language, it's the running theme of the security side of things. If you implement a Graph API, you have a schema of valid queries within your API. If I have an account field, then I can fetch the account field, that kind of thing. Very basic. But there's a level below that in terms of validity, which is things that are syntactically valid. There could exist a GraphQL schema for which that query is a valid query. However, for your schema, that is not a valid query. 

An example would be something like – actually, before I come to the example. Go into this a bit more. Query parsing vulnerabilities are of this nature, where an attacker deliberately crafts a query that is syntactically valid but – I don't know if this is a real term. But schematically invalid. Waste your server time working out that that's the case. Or processing parsing the query and then letting you know in what way it's invalid. 

For example, this is one that we saw in an external pentest. With three characters, you can add an error to any query. And that is if you're familiar with GraphQL, we're adding a minimum viable directive to a field. If we add to the end of a field request, we say space at A. What we're doing is saying apply the directive called A to this field. Normal examples of directives are things like at if. And then you parse an argument. And so, you can selectively not include fields in a query. 

To be honest, we never use directives. This is one of those things where I'm like maybe they just shouldn't have included this feature in the system. But regardless, it exists in the spec. If you add space at A to your query, then it's going to generate an error saying there is no directive called A in this schema. And the problem comes when – you can have – there is no bound on how many directives you can have on a single field. You can just say fetch account at A, space at B, space at C, space at D. 

And so, we had someone do this with following rinse and repeat for something like a thousand directives, which is not a ton. But a thousand is not a big number in computing. But each three characters caused the server to build an error to be returned to the client. Because in GraphQL error, query errors, that's in the spec. If your query has errors, you tell the client so that they can work out how to fix those errors. Really useful feature for debugging. Not so useful when your malicious attacker deliberately puts thousands or tens of thousands of errors very cheaply into a query body. That might only be like a couple of kilobytes of text for them to generate. 

Meanwhile, your server is now generating enough error response JSON that it out of memories the Kubernetes pod and crashes the entire server. I'm not exaggerating. We saw that. We found it very easy to get Rails to generate 2 gigabytes worth of error JSON. And, actually, we reported this to GraphQL Ruby's author. Shout out to Robert Mosolgo. I'm sorry, Robert. I've caused you such headaches over the last five years. But we did pay for pro. I don't feel too bad. 

And in GraphQL Ruby's case, this is a solved problem. That the mitigation is a healthy client. Won't generate a thousand errors. A healthy client will generate three. Have an upper bound on how many errors you'll pass. And then exit early, bail, and just give them back the errors you've generated so far. Yeah. Robert added that to the GraphQL Ruby gem. I can't remember if it's a default argument or a default config. Or if you need to opt-in explicitly. But, yeah, if you look that up, if you're worried about this kind of thing. And there are docs for GraphQL Ruby. 

And if your library doesn't do that. Sorry. I guess you just have to try and implement your own manual GraphQL password and work out if there are too many ats in this query. Not fun. This is I think another great example of GraphQL-specific incidental complexity. Particularly if your library doesn't have a get-out-of-jail-free card. 

[00:26:25] GV: Yeah. I think I kind of just love the detail here. And, yeah. Obviously, with the fact that it has these sort of interoperability issues with some really popular frameworks, I.E. Ruby Rails, maybe just kind of sends the point home that, potentially, for those that were not fully understanding what was going on, it was causing more problems than help at a certain point in time. 

You do mention in the article as well that GraphQL can sort of add significant complexities to a codebase. I think we'll sort of roll that into the fact that you also talk about versioning of APIs from a REST perspective even is not a sort of easy challenge, I don't think, for any developer thinking about sort of what's backwards compatible and what's not. And how would you sort of compare that when it comes to how GraphQL implemented its sort of way of looking at versioning? 

[00:27:20] MB: Yeah. This was an interesting point. I think I probably undermade this point. Some of the responses I got around the versioning stuff were a little critical of my phrasing here. And I think they were fair to do so. I think the point people were making was why would you ever want break – what would you want to support breaking changes? What does it even mean to support breaking changes? I think I need to clarify what I meant here a little bit. 

If you control all of your clients, you can know that I don't need to account for the fact that I'm not Netflix. I don't have a TV that's running a three-year-old version of the Netflix app that I have to support [inaudible 00:27:58]. I can roll out a JavaScript update to all my browsers. And I don't worry about people not running JavaScript more than 3 days old or something like that. You've got an auto reloader. 

If you are in that camp, which I think is the vast majority of companies. Maybe not the vast majority of developers, because there are a few very big ones. You have to worry about these things. But the vast majority of companies, maybe you're just building internal tooling. Maybe you're building external tooling that you can just ensure that there's no one running more than a week-old version. Breaking changes easier, right? You need to support a week of, say – let's give an example, right? If I'm going to rename a field in my API, in the REST world you might say – I guess we wouldn't call it fields. But rename an attribute in my API. In the REST world, you might copy the entire endpoint. Change the name in the new endpoint. Move your clients to the new endpoint. Eventually, delete the old end point a week later or something like that. 

Facebook didn't like that. I get it. If you have to support that version one for like 3 years, it's not really a tenable approach. You're going to end up with thousand versions of your API. All of which currently need to be maintained healthily. I get why, with GraphQL, they designed the language for I think continuous evolution is maybe the term they use. Where, basically, they just say don't. Don't do it. If you're going to do a breaking change, if you're going to change the return type of a field, you just can't. 

If you want to rename a field, that's a bit easier. You add the new field with the new name that you want. You leave the old one around forever or for a very long time. If you want to change the return type of a field, you just can't. Because you need to support the old client who has the old fields, the old return type of the same field name indefinitely. And so, they didn't provide any tooling to do it. And in fact, the docs basically say don't version your GraphQL APIs. Which I think is good advice once you're in that camp. 

But, yeah, it's good advice for GraphQL people. If you're not already on GraphQL, it's a worse system. The version system I think for many people is the simpler system to maintain so long as you cannot have this sort of runway thing where you've got 12 versions of each API because you're supporting old clients. As long as you've got version N and version N+1, and that's it, you're always deleting your N and increasing to N+1 over time.

[00:30:35] GV: I completely agree. I'm sure there maybe some that are listening today that, for their absolutely valid reasons, don't agree. In a past life, I have a lot of experience with the Shopify API. And I always thought that their approach to versioning was very fair. They would stack through the sort of time frames of it wasn't sort of N and N+1. It was almost N+4. But I think that was being very generous where they would say, "Look, if you are using this version, then we have created –" I think it was four months or even longer. You've got at least – no. It was longer than four months. It was maybe 9 months or something. But they came up with a system. They said, "Look, every version, you can assume that in this amount of time. Let's call it 12 months. That is the time that it will be deprecated. Kind of plan on that schedule." And I think that was a good way to look at it, which was assume that you're always going to have to think about upgrades or deprecations in a certain time frame. 

Yeah. I don't think the GraphQL approach kind of makes sense in a ton of production places. Unless maybe that you're Facebook and you have a lot of internal communication around what's going on. I don't know. That's something that I think we'll always maybe never completely know is sort of same – obviously, same problem with React. How much of React is exposed from a sort of knowledge perspective inside Facebook? And then how much is sort of exposed as a "open source" for the community? What is the information difference there? 

I think we've covered like a lot of just interesting – let's just call it quirks and features. Some people might sort of recognize that reference to GraphQL. But I think what was also interesting is you mentioned sort of like the future and where are things going beyond GraphQL and REST itself generally. And you talk about Open API. I think you specifically mentioned 3.0+. Can you just talk a bit about that? What are the advantages to the approach? And sort of why might you move in that direction? 

[00:32:38] MB: Yeah. Absolutely. I feel like I should start by saying I took a career break shortly after – I'm still on the career break shortly after writing that article. I got to the exact moment of the hype curve where you're like, "This is going to solve all the problems." And then stopped before I got to the kind of maturity and the trough of disillusionment or whatever they call it. 

I'm probably overhyping the solutions. And I just want to be upfront about that. I hate people who are like old thing has all of these problems. New thing is good in these ways. I won't even consider what problems a new thing might have. And I think by virtue of my lack of experience, I probably am one of those people to a degree with Open API. I can certainly say it doesn't have the problems I saw in graph. But I'm sure there'll be new problems that I do have to encounter. Sorry. Massive asterisk preamble. 

[00:33:32] GV: Always accepted on SE Daily. Always accepted. 

[00:33:35] MB: Yeah. I've been checking in with the team who adopted Open API for this world. And as far as I know, they're really happy with it. They're still really happy with it. The reasons that we were looking into it when I was with the company and what's still holding true today is, we've talked about QL means query language a lot today, getting rid of a query language removes all complexity stemming from the query language. And security and performance related makes backenders lives much easier, faster to iterate. And this kind of thing, it's generally faster to do something once and not have to come back to it a couple of months later because it's no longer performant. Now that it's being used in a different way while still giving frontend developers those nice typed responses. The Open API has huge tooling ecosystem to generate clients of every programming language under the sun. Similarly, to GraphQL. We managed to keep that. 

We have TypeScript React codebase with Rails backend. Managed to keep that nice hit the dot, know exactly what's going to – what's available in the API response of Open API. I think they were using – if it's of interest to the React folks, they're using Orval. Orval is a RESTful client generator for Open API that integrates really nicely with React query and all of the new sexy service state management patterns that are getting popular in React. Feels astonishingly similar to GraphQL considering it's kind of eon simpler to implement on the backend. 

Yeah. One of the criticisms or one of the positives that people say towards GraphQL is, "Oh, well, it lets the frontenders work without constantly having to speak to the backenders." We talked about that a little bit at the start. My view is it's just not true for greenfield work, right? A lot of the time, your ticket involves new data. If it didn't, we'll just be moving deck chairs around on the Titanic. We build new UIs for new features. You're going to have to talk to the backender at some point. 

At least I'm used to working in organizations where either people are full stack or your teams are cross-functional. This idea of like a backends team and a frontend team I think is an anti-pattern. It's not conducive to rapid iteration. If you feel that you're missing those things, I would say maybe the issue is not the technology that you're using. It's the team topology. 

[00:36:08] GV: I think that's a really good point understating it. That I think there was maybe a trend for people to sort of call themselves full stack for a while even though, unfortunately, it sort of meant basically you're a little bit thin on both sides sort of. And so, I think, unfortunately, full stack got a bit of a bad name. If that's just from where I sat. If people were applying for jobs saying they were full stack, you had to really dig in, "Well, hang on. Where do you actually –" basically, I used to say if you have to pick one, which is it – and you can always pick one. Say, "Oh, well, I'm actually backend." Or, "I'm actually frontend." 

But, yeah. Nowadays, I do think given the number of the way that frameworks have kind of continually added the high-level. If we want to call it that. In terms of going from low to high. I think it's very possible for people to be pretty deep on both sides. That's just my personal opinion. I think it's just about kind of that mindset. You have to decide. I still meet quite a lot of programmers who they just say, "Oh, I can never do –" I'll slightly go on one side here. I do think that it's backend program saying I could never do frontend. I hate I hate CSS. I hate this. Yeah. 

Actually, it's not too difficult. And, also, if you understand that side of things, then you will definitely – if you know what you're designing to be consumed. You're the consumer of a thing that you're producing. Then, actually, it can work out pretty well. Even if you don't need to write frontend every day. Just understand the consumption side of it to be a better backend programmer, for example. 

[00:37:43] MB: Yeah. I totally agree with that. That last part especially. Your job is to create a system that honors a contract between you and someone. It helps a lot if you have empathy and understanding of the needs of that someone. That's one thing I think GraphQL got really right, is it popularized that way of thinking of GraphQL best practices is forget what your internal data model is or your abstractions and all these things. What is the API your client would want? And then you kind of work backwards from there. You build the fields. And then you implement the resolvers for those fields. There's nothing stopping a person doing that in other systems. It's just that GraphQL I think made it clear that that was how they envisioned its use. And so, I try and encourage people to do that. And REST API, you can still start with what should the JSON look like and then work backwards from there. 

[00:38:33] GV: Yeah. I think that's a good place to sort of leave it between the two. At the end of the day, there is no right or wrong answer. Very simple. I think your article was very good just illuminating after a good amount of time what actually is the reality when – I think as sort of mentioned towards the start of today was there was a period of time when it was almost sort of blasphemous if you did not implement GraphQL or you didn't even consider it. Well, what's REST is old, old, old. Very interesting that basically things – and if you check out the comments on the article as well, a lot of I think anecdotes of sort of we moved back to REST was what I saw. And I found that very, very interesting. 

Do you have any I guess plans to like write more on this topic? Or sort of I think you mentioned at the beginning, you put out another article and it got sort of no upvotes. And that's just obviously inevitable the way things go. But shouldn't discourage writing. Yeah, what are your plans for writing more? 

[00:39:35] MB: Yeah. I died on a hill that no one else wanted to die on. I think GitHub releases rubbish. And that people should keep writing change logs. I'd be interested to see if your listenership agrees with that policy. But anyway, now I'm just trying to re-platform myself. It was the first article I'd written in a number of years. I think felt important. So much at a crude. I don't think I'll be writing again in such depth anyway anytime soon. That really was four years of knowledge, plus, to knock that out. We'll see. I'd love to – I certainly enjoyed the experience. And it's felt very good to provide value to be crude about it. But I don't think I've got another Hacker News front-pager in me for a while. But we shall see, I guess. There's an RSS feed in that website somewhere. If anyone's interested, feel free to subscribe and follow me along. 

[00:40:28] GV: Yeah. I mean, I think that's a great place to leave it. People should never be afraid to post an article because they think they then need to write – it needs to be then a monthly thing or a weekly thing. I think it's great if you have something that, as you just said, is four years of knowledge. I feel I need to distill this or would like to distill this into an article and could be useful for other people. I think that's the best form of articles. Again, I think that's where Hacker News really shines. Where, basically, people, whether they are maintaining a sort of longtime blog or it's actually just a sort of you go into their website after reading whatever it was that got popular and you realize, "Oh, this is kind of one of two articles. Great." I think, again, that's what makes Hacker News a little bit unique I think in the content space. If you want to call it that. 

[00:41:17] MB: Totally agree. I think there's too much. I have been trying to get out of the Ruby world lately. And it's a whole other topic of conversation. And upscale more on TypeScript and the JS world. It's made me realize how there's just so much short-form video content. I don't really understand why this medium has become so popular for programming. I think watching a person talk is like maybe the worst way to learn programming. It's one thing to do a live coding thing. Great. I love that kind of thing. But this popular stock image six-minute video telling you why JavaScript framework of the year is going to make you a perfect programmer, I really don't understand it. And I would love to see more people spending – let's make less content, but longer and much more in-depth. And less hype-driven software engineering. That's my plea to the world.

[00:42:10] GV: You just eliminated a format I hadn't really realized existed. From what you just described, it does sound terribly. It makes sense to me either. Yeah, I like that call out. 

[00:42:21] MB: Don't go deep on YouTube software engineering. That's what ' I've learned. And, also, people just reacting to reading blog posts on Twitch. I don't really get it either. But anyway [inaudible 00:42:30]. 

[00:42:32] GV: There we go. Anywhere that people can sort of find you, follow you? That kind of thing. 

[00:42:36] MB: Best place – to be honest, I'm not terribly active on any socials. But I am most active as a tech person on Twitter, X. I don't know what we're calling it on this podcast. You can find me @Besseydevs. 

[00:42:53] GV: Awesome. Well, I just want to say thank you so much for coming on today. And I really like these episodes where we get to talk to the person that wrote the thing on Hacker News. And I'm sure a lot of listeners either have read it already or now we'll go read it. And I think it's always great to sort of get further context and get to hear from the person. Very much appreciate you coming on today. And look forward to sort of following you in the future and see what else comes out. 

[00:43:20] MB: Well, yeah. Thank you. And thanks very much for having me. It's been great.

[END]