Sophia
00:00:00.000
GraphQL comes with all the stuff out of the box. You don't need to, piece together a bunch of disparate packages or frameworks, it's all just native to the tooling. And you get a lot of value adds from all of this tooling being native. This is DevOps Paradox, episode number 3 0 6, understanding Graph QLS role in modern APIs.
Darin
00:01:18.067
Here it is in 2025. And we're still having conversations around GraphQL. Will it ever just die? Viktor, what do you think?
Darin
00:01:30.920
I mean, you don't like it. I don't like it. We still question why does it even exist? We've had, other people on talking about it, but it's like, why, why GraphQL?
Viktor
00:01:41.709
I don't work with it much. I I understand We are using it ourselves. It's just that I have a theory not based on any informed knowledge that might be completely wrong. I think it exists. As a fix for the cases where people don't want to fix the root cause of a problem.
Darin
00:02:08.460
Well, let's see if we can get informed today. On today's show, we have Sophia Willows on with us. Sophia, how are you doing?
Darin
00:02:17.536
Are we okay? I guess I'm completely off base. It looks like Victor's trying to use it some, not directly. There's a specific use case for it, or is there a specific use case for GraphQL? Where does that fall in sort of, how does that play out?
Sophia
00:02:33.909
Yeah, great question. I don't know that I would say that there's, any one specific use case for GraphQL. I think, it really depends on the specifics of what you're trying to do. Our use case, at Rai is we're a developer tools company. We ship an API to other developers who build on top of our, API. And we really like, a lot of the things that you get for free from GraphQL. Things like, the, schema language. the type system, stuff like this.
Darin
00:03:08.624
I mean, that seems like a lot of work for something that REST is probably just more than okay fine with. I mean, I mean, I understand that there's use cases for it. I mean, even in GitHub there's, until something shows up in the CLI, the normal way you deal with is in GraphQL, but man, it's just a pain in the butt to work with it.
Sophia
00:03:28.248
Yeah, I think this is true. so, you know, one of the things that I like to, the way I think about GraphQL is, there's a much higher Floor to get up and running with them. So with REST you can, create, a server. You can expose an endpoint. you don't have to worry about things like an open API schema. You can just sort of take in a raw, untyped request body and return a response. I think a lot of people really like that about REST. It's very sort of a la carte. You can add on things like Schemas or Playgrounds, nice error handling as you go, whereas with GraphQL, you're forced into doing these things right from day one. if you're a full stack engineering team and you're building something like a SAS application, and that SAS application has a front end that talks to your And that, uh, if you're building a backend and your always going to be the only consumer of that API, I think REST is a really great solution because you might not need a lot of the complexity that GraphQL, comes with, but I think that, in cases where you're building developer tools like we are, it's not really optional for us to avoid things like, And, uh, having nice schemas and strongly typed requests and responses. We'd have to do that one way or another. GraphQL comes with all the stuff out of the box. You don't need to, piece together a bunch of disparate packages or frameworks, it's all just native to the tooling. And you get a lot of value adds from all of this tooling being native. So for instance, if you type a field in your GraphQL query, GraphQL just out of the box will give you a really helpful error message, which says, I can't query this field, let's say you typo title, and you spelled it T I T E L, and it'll come up with a suggestion, did you mean title spelled correctly? and so I think, uh, it's very contextual and it depends on what you're doing, but I think there are a lot of use cases, particularly in developer tooling, where, Yes, there's a lot of complexity that GraphQL comes with, but you'd need to eat this complexity one way or another, if you're trying to ship an API to external developers anyway.
Darin
00:05:50.218
It seems like to me though, as a business, I wouldn't want to provide something easy for developers to easily consume because I'm trying to sell something, so I want to be able to sell them even more. So if I make it simple for them out of the box, minus the pain of working GraphQL, that just seems like it almost seems like we're solving for the broad case instead of the exact cases.
Darin
00:06:22.448
Well, I mean, I'm not going to be able to make as much money as a business then. Because if I give them something simple to use, then they can go off and do whatever they want. And that's just going to make my, project, my product, just like everybody else. It's like, so what, how, I mean, to me, it, it, it's just a yet another me too type product. I'm not saying that specifically about your product, but I'm just saying in general, it's like, if everybody did GraphQL, just to make it easy for everybody, it's like, okay, yeah, as, as the producer of that, that widget, yeah, it's, it's a pain for me to get going. But then other people just use it. I'm just trying to be contrarian here because I just don't, I mean, I understand the purposes of it. I've used it when I have to, but it, to me, it seems like if, if somebody can do anything they want to with GraphQL, then that backend had better be strong enough to support whatever the whatever's are. Whereas if I'm just going down REST or some other variation, I've got really tight guardrails.
Viktor
00:07:34.760
Is that the case? I thought, and I might be completely off the rails here, right? But, one of the things that you can avoid with GraphQL is making infinite and a number of requests so that you can group them all together afterwards as a consumer and what's not right. Cause. You can still do everything you want with REST as well,
Sophia
00:07:57.376
I guess there are two sort of through lines here, right? I guess, Darin, to your point, because GraphQL puts the onus on the requester to indicate exactly what data they want, and because GraphQL enables you to, Traverse relations, there is this problem where, a consumer can produce sort of like an arbitrarily complicated query that recurses on itself. And if you haven't built protections into your back end, so you know, you aren't limiting the complexity of incoming queries, or, you're not rate limiting at all. this can definitely be, a problem, for sure. And then I guess, Viktor, your point is, there's sort of a, a corresponding issue on, uh, The REST side, which is less of a concern on GraphQL, which is in REST because you define all of your response payloads up front. Oftentimes what ends up happening is someone will try to integrate with your REST API, they'll need some related data, and they'll end up waterfalling a bunch API requests one after another to assemble all of this data and then group it together. So I think you can make the case for either approach, really. Like on GraphQL, you have certain performance trade offs that don't exist in REST. And in REST, you have certain performance characteristics that you don't need to deal with so much in GraphQL because you assume that people are just going to make the one single request. My position would be it's easier to solve these problems in GraphQL, in the general case, as opposed to solving that waterfalling problem. And I think that's all I have to say GraphQL. I hope you enjoyed this video. If you did, please give it a thumbs up. And see you in the next video. Whereas in REST, you pay the cost of everything in your response body, regardless of what the consumer's using. So in theory, you can solve waterfalling issues in REST by expanding the amount of data you've returned on your endpoint. but you can't do that indefinitely. because you have to pay for everything in your response body. Whereas in GraphQL, yes, you have additional complexity around, limiting query cost or avoiding, n plus one queries. And unfortunately the way GraphQL is designed, it makes it very easy to build services in a naive way, which are, vulnerable to these pitfalls. but there are well known technical solutions for these problems that you can, Add on top of your server and you don't need to worry about them quite so much once you've solved them.
Viktor
00:10:37.189
Is it equally valid or useful when it's public facing and internal facing? In terms of, I imagine that if you have some APIs that are externally facing, you do not necessarily know what are the needs,
Viktor
00:10:55.809
right? While if it's internally facing, then And again, this might be me talking without understanding it well enough, then you can actually tailor made APIs themselves to be, okay, so this is what you need. You don't need 57. We're gonna aggregate it in a backend and whatever and give you straightforward thing. Am I too simplifying it or?
Sophia
00:11:18.859
Yeah, I think your intuition's correct. So, the way I think about this is exactly along the lines that you describe. So at Wrye, like, we have public facing GraphQL API. And one of the reasons why we picked GraphQL, there are many others, but one of them was, at the start of the project, like, we didn't really know, like, what, interesting use cases or access patterns our customers would come up with. We didn't want to, sort of, curate, response bodies, ahead of time before those use cases had crystallized. And GraphQL, gave us a really good way of shipping an API. Letting our customers decide, like, what access patterns made the most sense for their integrations. because it was impossible for us to know up front. but we have a lot of, like, internal APIs and microservices that talk to each other. And there, like, we do not use for inter service communication. We're leaning more on REST and gRPC. Because you just don't get as much benefit from the client controlling the response body in an internal use case where you actually do have pretty close to perfect knowledge of what the consumer needs and what the producer needs to provide.
Darin
00:12:36.432
How did you decide to break glass or was that your design from the beginning is for anything that was inner service, you decided to go gRPC or REST. Did you actually go down the path of GraphQL and all of the things, and then you decided to break glass?
Sophia
00:12:52.334
no, we, so I, yeah, so it's always been from day one, there's been an external facing GraphQL API and there have been internal REST APIs and, and gRPC services. I have seen it been done before, at a previous job where, every single part of the API, whether it was a external facing or internal facing was GraphQL in my estimation, it was a bit of a disaster because, there is like a non trivial amount of overhead associated with, GraphQL. you need to, parse your query documents and there's this very heavy sort of type checking system in place on all of your, inputs and outputs. This doesn't really make so much sense when two computers are talking, when you own both sides of the request. and that value add of GraphQL where you can request all the data you want in a single request, and the server will sort of aggregate it for you in order to avoid water falling. That also doesn't make a whole lot of sense in a microservice scenario where, Your services probably have, like, one millisecond network latency to each other anyway. Whereas, when you're talking about an external developer who's, sort of making a request from outside of your, VPC, they may, be looking at, like, 30, 40, if they're on the other side of the world, maybe even latency. And so, avoiding request waterfalls, is much more important comparatively. at Rye. It's always been, we've always had this sort of, distinction, in place where, anything internal, like we avoid GraphQL, the, costs don't outweigh the benefits, and, and I think the benefits are pretty minimal in that particular use case. And then externally, where, uh, we do care about a lot of the, uh, Benefits of GraphQL, and we're not so concerned about, some of the, cost because we'd have to pay the cost of, you know, defining a schema regardless of our technology choice. there we use GraphQL. So yeah, it's, it's always been, in our DNA and it's always been an intentional, engineering decision that we've, ran with.
Darin
00:15:03.237
I'm going to be a little more contrarian. So what we're saying here is GraphQL is great for things that we just don't care about. My words, not yours,
Darin
00:15:15.272
right? Because we say, because the way I'm hearing it is machine to machine. We want that to be as fast as possible. We don't need any overhead. So we'll go with the classics. Going, just going back to the standard RPC type stuff, right? But as soon as we introduce a human to this, we don't know what a human's going to do because a human's going to do what a human's going to do. So we want to not have to visit that ever again. So we don't care if it's performant for the human or not. Again, my words, not yours,
Darin
00:15:48.992
but that's what it feels like, right? Because I mean, that sort of makes sense because going back to what you were saying way earlier, we don't know what they want yet,
Viktor
00:15:58.004
I have a similar situation with Kubernetes where there are cases where I actually literally need to make hundreds or thousands of requests. to its API to get what I want. That can easily last minutes, To me that sounds like a good use case, but actually performance would probably be better on both sides. If Kubernetes could accept GraphQL and say tell me what you want, I'll do the work for you. Am I off here as well, or?
Sophia
00:16:35.083
that's possible. I'd need to see the specific, use case, but you know, if you're making hundreds of thousands of requests, like at that sort of scale, then, GraphQL's, ability to, avoid the need for multiple requests and, and request everything in one go. At that scale, probably it, it makes sense to use GraphQL even for, machine to machine communication. Sure.
Viktor
00:16:59.115
I don't know, this is even worse, this was outside of machine, to machine, kind me, me
Darin
00:17:10.207
And even if you would do GraphQL and you were just wrapping basically the rest APIs that exist in Kubernetes, that seems like the worst of all possible combinations. It's like, so, so I'm trying to figure out, okay, I mean, I sort of understand the right places. I mean, I get the basics of GraphQL, but again, if everything's a nail and all you have is a hammer or whatever the saying is, all I have is a hammer. So everything's a nail. Thank you. There it is. do you see people taking GraphQL the wrong way? And throw it on the other side, where do you see people taking GRPC the wrong way?
Sophia
00:17:45.310
there are a lot of ways in which people use, GraphQL the wrong way. you know, my personal opinion on this is, people use GraphQL, uh, Uh, in the wrong way, it's very easy to use in the wrong way, they come away from that with a very negative impression of the technology, and it spawns sort of, like, a lot of these thought leadership pieces we see, like, GraphQL versus REST, uh, where the conclusion is, is almost always I think that's it. that's it for this video. I hope was informative. I really hope you found it useful. I hope you new. I hope you enjoyed I'll see you next time. Bye. Bye. Bye. I think it's a huge mistake for your GraphQL, schema to be like a one to one mirror between, uh, a one to one mirror of your database schema. And I see a lot of people doing that where they're, essentially just shipping their database schema. There are a lot of, like, uh, libraries out there which make it really easy to do that. So if someone's using Prisma ORM there are a bunch of GraphQL server plugins which will consume your Prisma schema and turn that into a GraphQL schema. Really, really easy to expose your database models one to one. And it's almost always an anti pattern. You generally want to be designing your GraphQL schema around use cases and things you want, and sort of functionality that you want to expose to your consumers. As opposed to designing it around the data that you're storing on the backend. a really sort of concrete example of this would be as an example, like if you have a sort of a blog application, you'll have a bunch of posts, and posts might belong to categories. If you were building a REST API, you might have sort of a get category, end point and one of the fields on that end point might be the list of, post ideas that are inside that category. And if a consumer wanted to check is a post inside a category, they would fetch the category and check if the idea is in that list. Bye. You don't really want to do it that way with GraphQL. You don't want to export a list of IDs. You don't want to expose your junction tables. You know, presumably you've got some like post category, have a table which handles that, many to many mapping. You generally want to be sort of thinking about, like, what is the use case I'm trying to support? I want to be able to quickly check if a post is in a category. You would have on your category GraphQL type, a has post field. Or on your post type, you would have an in category field. And the cool thing about GraphQL is that So what you can do with this is fields can take arguments, they can resolve to sort of like dynamic values. And so you can encode that use case of, is this post inside a category directly into your schema and move that business logic, that your consumer would have had to implement, into, your API. And because you only pay for what the consumer specifically requests, it's free to add this to your schema. Ignoring, of course, a maintenance burden. So that's one big thing, is you really don't want to be shipping your database schema unmodified to your consumers. I would say that, like, you don't really want to be doing this with any API technology, but it's especially true for GraphQL. You want to treat it as, like, an abstraction layer over your underlying storage engine. The second place where people, misuse GraphQL is, again, like if you are a full stack engineering team, you're building a SaaS app, you own the front end, you own the back end. It's difficult for me to see much benefits in using GraphQL. Just so if you have sort of like a couple microservices that are talking to each other, it's hard for me to see the value of GraphQL because you, you know, own both sides of the integration, and you're probably not getting much benefit from the investment in GraphQL at that point. gRPC, I don't see as many problems with people using, gRPC, is quite a simple technology. it doesn't have as many gotchas to it, as GraphQL does. But I will say, I would sort of encourage people to make, sort of pragmatic decisions around their technology choice. gRPC is a little bit more complicated than making HTTP requests between your microservices and it's harder to debug because it's a binary protocol, it's not plain text, so your calls are not going to come up as sort of nicely in your traces as HTTP request would. And so it's just important to think a little bit about. The performance characteristics of your system, what kind of load are you expecting to experience? Most people using gRPC could probably sub in HTTP requests and be just fine because most systems are not at a scale where you need the extreme performance of something like gRPC. So,
Darin
00:23:06.355
I think it feels like GraphQL and GRPC are the, the antis of each other, they're both super complicated and you better pick the right one when you really need the right one, whereas right in the middle is just http calls or rest. If you wanna just call it that to keep it simple, that will work either way. But you may hit rough spots on either edge as you go in one direction or the other. If you want ultimate flexibility for the end user, GraphQL, because gRPC, it's the same problem as REST. But if you're needing extreme performance, then you're gonna go gRPC at the cost of there's this one way and this one way only. You want something new? Well, we have to go write it. Send us some more money.
Sophia
00:23:54.376
Yeah, I think that's an interesting way of looking at it, and yeah, I would agree that, if I had to put these things on a spectrum, gRPC would be at one end, HTTP in the middle, GraphQL at the other, for sure. Definitely in terms of, like, that sort of performance versus flexibility trade off space.
Darin
00:24:11.956
Stated differently, just because you can doesn't mean you should. And that's, that's true for both ends of that, whereas if I picked REST, I can always do that. I just may not be happy because it's sort of a middle solution, literally, a middle solution. one of the things I love about REST and any other platform. Just basic network calls. There's a lot of other things I can do because it's a lower building block. Whereas GraphQL, that's full stack for lack of a better term, not full stack development, but it's, it's a, it's a full stack, literally. I guess I've just been around long enough. Full stacks in the end always caused me problems as a developer, as an operations person, because when it breaks, everything's broken. Am I too far off on that one?
Sophia
00:24:59.995
I think it's right, I think you're, instincts are right to be sort of skeptical of very heavy, abstractions, in libraries. And I think in general it's a good, guiding principle as an engineer to, understand the fundamentals and, and keep things as simple as possible for as long as possible. You know, you should do the simplest thing and, and nothing simpler. Have a great day. something that is true in our industry today is that, we have a lot of, complexity in the tools that we work with, and it's, some of it's unnecessary, but I think, a lot of it is, sort of necessary complexity that we get from, A lot of value from. So for instance, to sort of, I'm going to talk When I was getting started, there was this big discussion around whether or not we should use typed languages. So when I first got started, untyped languages like Python or plain JavaScript, Ruby were all very popular. if you were to go, like, 10 years, before that, statically typed languages were, very much in vogue. And over the past, like, Five years, I want to say, I went from, having multiple discussions with people around, should we use JavaScript versus TypeScript? Now everybody just uses TypeScript and it's sort of assumed that this is the right thing to do. And I think empirically, certainly from my perspective, it feels like static type systems, are worth, the upfront complexity and friction that they add. It feels like you get ROI from defining your types and being forced to think about data flows like very quickly. Essentially the first time you need to revisit any code you've written, you're getting benefit from it. And I kind of see versus HTTP in much the same way for things which you are exposing externally. So if I'm just building something internally, I might not put the effort in to define a schema and hook up like an open API validator. But if I'm shipping an API to other engineers at a different company or at a different team, always going to spend effort on things like defining a schema, regardless of the technology choice I'm using. and if I am building an API and putting that effort on, like, I would rather use something that's sort of reasonably standard, like GraphQL, as opposed to, inventing a lot of like my own, customs. Something else that we haven't really touched on is like, yeah, like REST is very flexible and it gives you a lot of options and it's composed of like very basic building blocks. But one of the downsides of that is every REST API feels like a little bit of a snowflake. pet example of mine is the Dropbox API where they have a file upload endpoint. And you upload your file as like an octet stream, this obviously prevents you from posting a JSON body with things like the desired title of the file. And so what Dropbox do to work around that is you stuff your JSON body into a special header, in order to get around, like, that transport layer limitation. and there are plenty of examples of, like, fairly strange things going on in, REST land. whether people are making creative use of HTTP status codes, Or whether people are interpreting HTTP verbs differently or, some people are very, religiously RESTful and everything's sort of resource oriented whereas other people will ship RPC style APIs over REST. one of the things that you get from using GraphQL is sort of, A general level of standardization. Errors are going to look and feel similarly across GraphQL APIs, regardless of who's built them, because like a first class citizen in GraphQL and they're described by the spec. Whereas REST APIs, yeah, there are some sort of general guideline documents out there around what makes an API RESTful. But everybody inevitably puts their own spin on it, as someone who's on the other end of your API integrating, that can be quite a frustrating experience.
Darin
00:29:20.597
You said the one word spec or specification. Isn't that the key part to this? If we would just follow either the GraphQL spec or follow the OpenAPI spec, wouldn't all these things, these problems just
Sophia
00:29:36.055
in general the answer to your question is yes. If we could all decide on a way. to structure our REST APIs, then everything fine. But building consensus on exactly what the ideal REST API should look like very difficult, and everybody has their own sort of take on what an error object should look like, as an example.
Darin
00:29:57.847
How did GraphQL come to that consensus? Because it seems like I could have basically, maybe not all the problems that I would have on an OpenAPI definition, but it feels like I could still have a lot of them. error was solved with GraphQL, right? There, there is one way to express an error in Um, status codes are going to be this, the status codes, no questions asked. But from that point forward, I mean, it seems like it's still going to be the same as what I'd have in any kind of open API endpoint.
Sophia
00:30:28.544
not necessarily. So, the level of standardization in GraphQL goes a lot deeper than just, like, what does an error look like, and, what HTTP statuses are we going to use. So even things like, for instance, Stripe does not use, put requests for, update operations. They use posts. And there's a technical reason for why they do that. They have integrations. They have, customers who use tremendously old stacks that I apparently don't understand the PUT verb, so all of their updates are done, via POST. HTTP verbs don't exist in GraphQL. Like there are just three primitives. There's a query, there's a mutation, there's a subscription. so nobody bike sheds over should this endpoint be exposed as a PUT or a POST, like what is the correct verb to use? Because this concept does not exist in GraphQL. And similarly, things like, how does the type system, work? this is well defined, in GraphQL. it's sort of a, a minimal type system that, works, well with any sort of modern, programming language. One of the issues with OpenAPI is my understanding is that it has a lot more built in, types than, uh, And, GraphQL does, and not all of these types are going to work in every single programming language, whereas I think GraphQL takes a more, conservative approach, I think that's generally true for the GraphQL specification, overall, so circling back to errors. You don't have, tens of different status codes. Uh, you just get back, like, a list of error objects which have a minimal structure. if people do have custom requirements, there's a mechanism for adding, extensions. which is just sort of an arbitrary, key value map attached to the object. and I would say that that's sort of one of the big differences between, GraphQL and something like, OpenAPI or, Microsoft have their own standard as well, that I forget the name of. the GraphQL specification. It errs on the side of being, as minimal as possible, in order to support, like, the widest possible, number of, consumers and, producers. It's, sort of designed to not be too large. Too invasive, so long as you buy into the technology in the first place.
Darin
00:32:57.018
It just feels like I'm still not convinced. the only thing that makes sense to me is we don't know what people want. I basically want to just expose my database to the world. Again, you said, don't do that. And I agree with you, but that's what people will do. No matter how many times we tell them that, that is what they will do. it's just basically what we used to do with stored procedures behind REST calls. It's the exact same thing. this is a story that's been going on for 30, 40 plus years. And I don't think it will ever change. We just throw new front ends on it just to think that it will. how do we not do that yet again? what is going to be the successor to GraphQL that thinks it's going to solve the problems and it's still going to be the same thing all over
Viktor
00:33:42.856
Are you now trying, Darin, to solve human stupidity as a problem? Is that where you're going with this?
Darin
00:33:49.886
Well, I'm going to take it back. To what Sophia brought up, we're talking about Stripe, not supporting put, having to do post because their consumers have systems that are so old that post is all that they can do. Well, guess what? That's what makes Stripe a multi, multi billion dollar company because they chose to not force put down people's throats. And it's like, yep, we'll do post. Great. There'll be more money for us. we've seen this too many times. We know there's going to be a successor to GraphQL, just like there's a successor to REST. GraphQL is basically that for certain use cases. The next thing we'll say, Oh, this will be better than that. And then we'll get a whole new wave of GraphQL versus NuX versus REST. Is that already starting to pop up or am I way ahead on this one? Yeah,
Darin
00:34:50.225
Why not? What do you think, Sophia? what's going to be the successor to GraphQL? Does it exist yet?
Sophia
00:34:57.629
It's not clear to me exists at moment, but I'm that there is someone cooking but I wouldn't be able to tell you what it is, at the moment. There's a great, XKCD, actually, which, uh, you've just reminded me of, which is about standardization and, and sort of the thesis is that someone notices there are, you know, 20 different ways of, encoding text, let's say, and he decides, You know, we need a universal standard to simplify things and sort of the end outcome is you have 21 mutually incompatible standards.
Darin
00:35:32.268
Is that what our whole industry is boiled down to is all we do is create standards and pray that something actually works in the end.
Viktor
00:35:39.993
know, we keep working on standards until they become a big ball of mess. Like you have Ottel, right? We speak often about Ottel, right? OTL is a standard that is widely accepted in the observability area, and it's such a mess that nobody can effectively use it without going crazy, simply because everybody agreed and everybody's suggestions were included in it.
Darin
00:36:07.234
we just need one company for the world to do one thing. that's the only way we'll ever get a true standard. I don't know. So Sophia works for Rai, and you've talked that it is a developer tool platform, for lack of a better term. what's the right way to explain what Rai is and what it can do?
Sophia
00:36:27.572
So we're an API company and the way to think about it is just like Stripe lets you process payments, Wrye lets you sell products from the internet on your application. So if you have something like a wishlist application, you want people to add products to a wishlist, and someone else can come in and purchase them on their behalf, you would reach for RISE. So you can give us the URL of any product on the internet from any store. We do the hard work of, turning that into structured data. You can add that product to a cart, you can check it out. Your Rye cart can contain products from multiple different stores at the same time. You can check out like a Gymshark product and an Alloyoga product and all in the one cart. and we handle all of the, complexity behind that, checkout process.
Darin
00:37:19.226
Well, that sounds cool. So that means I could buy, you said, I could get a yoga mat and some aloe. Could also get, um, I don't know, some worms so I can go fishing too. I don't know. Will that, does that work?
Darin
00:37:39.211
because you have goat yoga, right? Okay. Instead of worms, I need to get some feed for my goats, right? So I can have goat yoga all at the same time.
Sophia
00:37:45.931
Yeah, totally. You can definitely do that with Wrye. the merchant is in our network, we kind of have like this sort of, network where merchants can install an official Wrye connector. And when they do that, you can even earn commissions on the goat feed that you're purchasing through our API earn some revenue.
Darin
00:38:05.088
If somebody steals that idea, I get a commission. Well, put it that way. So all of Sophia's contact information will be down in the episode description. Sophia, thanks for being with us today.
Sophia
00:38:15.533
Thank so much for having me. We hope this episode was helpful to you. If you want to discuss it or ask a question, please reach out to us, our contact information and a link to the Slack workspace or at DevOps paradox.com/contact. If you subscribe through Apple Podcast, be sure to leave us a review there. That helps other people discover this podcast. Go Sign up right now at DevOps paradox.com to receive an email whenever we drop the latest episode. Thank you for listening to DevOps Paradox.