Transcript
Moderator: This is a little bit more freeform. It's not just about APIs, but the topic for the track is "The Future of the API." I thought, we all deal with the future technology, it's always coming out. If you saw Charles [Humble] this morning, talking about InfoQ, we lean towards the left side of the graph: the innovators and the early adopters. Our three guests today have a lot of experience using the latest technology, either currently, right now with what they're doing, or just over their whole career, they've always kept up with the trends.
I wanted to ask questions about, how does one go about doing that? How do you stay relevant when there's this constant innovation? When there's something new that comes out, how do you decide, "That's for me?" How do you test it, how do you decide to abandon it and run away, and when is the time to go back to using SOAP and mainframes?
Rendle: Never.
Moderator: Ok, that's off the show.
Evaluating Technology
What are some practical strategies that you guys know that you personally use when you're evaluating technology? What's the thought process you go through, how are you choosing? Mark [Rendle], you finished your talk getting into gRPC. What if someone wanted to say, "I should consider, is it going to solve all my problems?"
Rendle: It will solve some of your problems. gRPC is great for a subset of APIs. If you've got two machines on the same network communicating with each other, and you need fast, stable communication between them, then gRPC is great for that. If you've got public APIs that you want people to be able to consume easily, that you want to document easily, then possibly not. JSON APIs, just regular HTTP APIs, are much more approachable. People feel much more comfortable talking to those. However, if you look at Google in particular, but a few other companies, they are now providing public gRPC versions of existing HTTP APIs for people who want to access those APIs from mobile devices on slower networks.
It's all very well for me to say, "Yay, we're getting 5G," but there are places in the world where the majority, like 99%, of internet access is from a mobile device, and they're still on 3G networks. In those environments, gRPC is a fantastic option for keeping bandwidth usage down and that sort of thing. It's certainly something that you should have a play with, something you should evaluate, and then, something you should apply selectively, where it is appropriate.
Li: Mark [Rendle], I had a question, actually, for this. You were just talking about gRPC, and I think it's a really interesting question in countries with 3G mobile devices. I was just talking at lunch with Jose [Nino], who's actually giving a talk on Envoy Mobile later today as part of this track. Jose [Nino] and I were talking about gRPC with mobile devices, but also HTTP3. I think we were talking about how HTTP3 is going to be, in my opinion, the killer use case for Envoy Mobile. We are wondering what effect it might have around gRPC and gRPC adoption, so I was wondering if you had a perspective on that. Rendle: Given that HTTP3, like everything else these days, is coming out of Google, then we're going to see gRPC 2.0, or something, which will take advantage of the new features, the extra stability and message handling and so forth, of HTTP. Is it HTTP3, or are they still calling it HTTP-over-QUIC?
Li: I think it is officially HTTP3.
Rendle: Yes, I would expect a new version of gRPC to come out that leverages all the HTTP3 goodness. Again, that's going to make working on the stable, intermittent networks with low bandwidth work even better. I don't know of anything else. The nice thing with Google basically going, "This is the internet, deal with it," is that it is in their interest to make it good, to make it fast, to make it work for as many people as possible. You generally do see them contributing positively to the internet ecosystem, and that benefits all of us. I don't work for Google, and if they offered me a job, I'd say, "No." That is my honest opinion.
GraphQL
Moderator: Michelle [Garrett], I'm going to ask you. You guys at Conde Nast are using GraphQL a lot, but there were other options in that space that could have been an option. How did you get to saying, "We're going to try GraphQL"? Do you wade in from the shallows and dip your toe, or do you just dive in and jump? A teaser for your talk later is fine.
Garrett: In the context of a product-development team – I'm a product developer – when we're evaluating a new technology, we'll usually do a spike or make a version of what it could be like quickly, just to have an experience of the technology. Ultimately, there are a couple of questions that we usually ask, such as, "How popular is this technology?" If I have questions, will there be people on Stack Overflow to help me? Is it maintained? Is this technology dead now, or will it die soon? How frequently are people responding to issues and updating their repository? Even if something is amazing, there's no point using it if it's not maintained.
When we were evaluating GraphQL, we were comparing it with some other things which were more custom, that were internal patterns that developers in the organization had already developed. Ultimately, we decided to err on the side of the most popular open-source standard, because we felt like we would be more supported. It depends on the technology, how complex it is, if you're able to fully take the plunge or do something more incrementally. Personally, I prefer to do things more incrementally, but that's not the case with all technologies. It's not always possible.
Choosing the Wrong Technology
Moderator: I love hearing the good stories of, "We went with GraphQL," "We went with gRPC, and it solved all our problems." I also really enjoy the good, "Oh, that was bad," story. Starting with Richard [Li], and I'll just work down the line. Give me an example of sometime that you backed the wrong horse, you picked the wrong technology and had to say, "No, we don't want to do that." How do you back out from there?
Li: My team works on Ambassador, which is this API gateway for Kubernetes built around Envoy. We originally prototyped it in Python, and it worked reasonably well. Then, one day, we discovered that all of our Azure customers couldn't actually update their API gateways. The way it works is that you create this Kubernetes manifest, and then, we read the manifest, and then, we tell Envoy how to configure it. It only didn't work on Azure clusters that were created after a certain date, and we were like, "What's going on?"
We talked to the Azure Kubernetes team, totally confused. Then, we learned that Azure had actually deployed an additional layer of proxies in front of their Kubernetes API servers, and the requests from the Kubernetes API server to our control plane were being dropped. They had actually patched this in the Go community libraries for Kubernetes, but not the Python community libraries. This was really the tipping point for us where we said, "Even though we like Python a lot, and we're not really Go people, the reality is that..."
This is to Michelle's [Garrett] point, too. You want to really look at the ecosystem. The reality is that Kubernetes is written in Go, so all the best supported libraries and everything is written in Go. We actually started incrementally rewriting parts of Ambassador, and all the parts that touched Kubernetes got rewritten first in Go. I don't know if we backed the wrong horse, but we made this technology decision, then we had to turn it around.
Rendle: One story – OData. OData had just appeared, which was like an early attempt at GraphQL, but very Microsoft-centric. It was incredibly easy to implement, because you created an entity framework model, and then you put a web API in front of it, and that was it. We had a customer, who I won't name. We said, "We should do an OData API," because then, people would be able to ask and construct queries and everything else. It passed far too much complexity to the consumers of the API, and made it difficult for them to work out the correct things they should be asking. I think we got about three months into that, and threw it all away and just wrote a regular JSON HTTP micromedia API.
It's interesting for me, looking at GraphQL, how it's solving the same problem that OData was trying to solve, but it does it in a much better, much more approachable, much more documentable way. I could do a whole talk of the bad decisions I've made.
Garrett: Yes, I have a story. Actually, one of the reasons that we introduced GraphQL in the first place was, we had spent a year basing our website application on what was essentially an internal framework that some people in the company had written. When we first started building the application, we were, "It'll help us get up and running really quickly," so we built an application based on this. Then, what happened was, a year later, we found out that they were no longer maintaining it, and it was basically an abandoned project. Unfortunately, it was also quite an opinionated framework, so our application was quite based around the patterns that were set by this internal framework.
What we took from this experience was that we should always err on the side of popular open-source standards wherever possible, because people leave companies, and people build really custom internal tools. Then, if they leave the company, that's quite unfortunate.
API Abstractions and Tools
Moderator: A lot of times, we'll see a new technology come out and really, what it is, is just a new abstraction layer. There's a class of problems that somebody is working at, at a really low level, and we can now come up with a solution that abstracts that problem away. There's always a trade-off, and the answer for any one of these questions is, it depends. I'm going to make you go one little deeper than, "It depends," and say it depends on what. How do you find that balance between the tool that offers you a lot of flexibility, versus you do it yourself, and it's all custom, you have all the flexibility to do what you want. If you used a tool, you might be more productive, but are you sometimes only able to do 80% of what you need? Is it enough?
Li: I think the key thing that is really important for technology folks and developers, for us to understand, is that we're trying to build a business. I think the way that I would assess this would be to understand if the functionality that we're doing is actually is core to our business or not. If it's actually a core part of our business and a source competitive advantage, then I would bias towards building it myself, or maintaining it ourselves. If it's not really core to our business, for example, if I'm Stripe, I'm going to use custom payments code. If I'm not Stripe and I just need to take credit cards, then, I'm just going to bias towards using Stripe and not writing my own. Even if Stripe costs money, it's totally worth that cost. I would imagine PayPal probably doesn't use Stripe.
I think it really comes down to where you choose to actually differentiate your business, and where you're actually building that competitive advantage. If you're building that competitive advantage elsewhere then my bias would be, you probably won't need that flexibility.
Rendle: There's a few things going on at the moment. You see people who are deploying an application into AWS. They create their own layer of abstractions over S3 and SQS and DynamoDB, so that if they want to in the future, they can move from AWS to Azure. They create their own layer of abstractions over all these APIs. If you are going to move from AWS to Azure, it's going to cost you hundreds of thousands of dollars, or pounds, or euros, whatever it is. My personal philosophy is, if something's out there that's been open-sourced by Facebook or Google or HashiCorp – who do a ton of mazing abstractions over things like AWS and Azure – if that stuff is out there, or gRPC or GraphQL, whatever it may be, the people who've built that have built it to solve a problem at multibillion-dollar companies, and they are incredibly smart people. It would be insane to think that you and maybe two of your teammates can do a better job than they did. As much off-the-shelf as possible, but at the same time, the stuff that is important to your business, the stuff that is making your employer or you money, keep that as separate as possible from whatever that layer of abstraction that you're using for APIs might be.
Try and keep a hard barrier in between. Don't pass your actual business objects out to be serialized, as JSON used DTO's, so that if something better comes along or it gets abandoned, then you can switch easily, and you're not unpicking this framework code from all the way through your business logic.
Garrett: I don't have much to add, but your answers were spot on. Completely agree that sometimes, you want to optimize for flexibility, for imaginary business needs that haven't arisen and won't arise. Think about what the business needs might be, before you try and adopt something because it's the most flexible, and then give up being able to get started faster, or have access to a better community.
GraphQL and Team Communication
Moderator: This is an actual API-focused question. APIs are about communication. Mark [Rendle] did a great job of walking us through. All these things have two servers or browsers, whatever it is, communicate, but there's other aspects to the communication. I have a different question for each of you, so I'm going to start with Michelle [Garrett]. How does GraphQL improve team communication? Not just, here's how this service [inaudible 00:15:27]. How does the team communicate?
Garrett: Let's talk about GraphQL. I think that one of the reasons that GraphQL is so popular is because it's really product-friendly. It's really friendly to product-development teams, because it helps front-end developers communicate really well with back-end developers, because there's a really clear contract between the front end and the back end, which is the GraphQL schema. I think the problems that people have, often, with REST APIs is that there's poor documentation, that you don't know what fields you're getting. With GraphQL, even if the schema isn't fully developed as an API, if the API team makes it known what their schema is, the front-end developers know what the interface is to build their UI.
I think that it's really improved the communication between front-end and back-end developers, or whatever the configuration may be. It has amazing developer tooling in the ecosystem. The fact that you can generate documentation based on the schema that's always up to date and always has the correct types for each field is a game-changer. I know there was Swagger for REST APIs, but I never really experienced something on the level of the GraphQL playground, tools like that. Generally, I think that people are really attracted to GraphQL, just because of the humanness of it and how intuitive it is to use. It really improves the way that people communicate, because of that.
Cloud-Native APIs
Moderator: Richard [Li], the human aspect, I wanted to pull back. You were talking about cloud-native API gateways. Your talk started with load balancers. The users of the load balancers were cis admins, and the developers just didn't care. They just wanted to trafficate their website. There's this problem that we've pushed down onto the development teams, and they need to understand it. Does a tool like the cloud-native API gateways we have now help learn and talk about what the needs are for how I do releases and other things?
Li: When you go to this full-cycle development model, I prefer to think of it as opportunities, because this was challenging. The opportunity is for developers to actually capitalize on all its operational infrastructure that they didn't have before, to really go and move faster. To answer your question directly, do cloud-native API gateways help with this model of work? I think it really just depends. I think we're in this process of trying to figure out, what are the right abstractions, what's the right UX for developers to access operational infrastructure, which is actually pretty different from how operators actually access operational infrastructure.
I think we're in the early phases of that. It's not clear to me exactly where we're going to end up, but I definitely think it's a trend where developers are going to be asked to actually manage operational infrastructure in different ways than before. How do we actually make it as nice of an experience as GraphQL, I don't think we're there yet. I think, ultimately, that's where a lot of this will end up.
JSON vs. gRPC
Moderator: Mark [Rendle], you had an example early in your talk about, "Here's a binary format for CORBA," or something scary from long ago that you should never, ever want to look at.
Rendle: GIOP, yes.
Moderator: Then, we came out with the XML, because we wanted the humans to be able to read it. Then we got to JSON, which was less human-readable, and now, we're back to gRPC, which is getting more dense. Have we swung the pendulum, and do you want it to swing back again, so that people can read what's going [inaudible 00:19:14]?
Rendle: No, we've come full circle. Generally, finding tech when you come full circle, it's because we've worked out that we should never have started travelling around the circle in the first place. I forgot to make the point at the end of my talk that gRPC is more like CORBA's GIOP than it is like anything else. I think we've gone along and we've tried a whole bunch of different things. We've come to the conclusion that out of all of them, the best one was that one we started with, which you find a lot. It's like a knight going off on a heroic quest, and then, he realizes that all we really want is to stay at home by his fire with his horse. That metaphor's completely gotten away from me.
Moderator: He rode off into the sunset.
Rendle: Yes. I can't see us going another route and going, "Let's go back to XML," "Let's go back to JSON." I think we're starting to settle. I think we're getting to the point where we're going, "JSON's great for public APIs and explorable APIs. gRPC is great for performance, and XML is actually really good for configuration files." Microsoft tried using JSON for project files, and, "No." It doesn't have comments. You can't have comments. This is one of the things I like about Protobuf, though, is that the way you distribute your API, the way people consume it, is through that dot-proto file. You have a web server, and people can get versions of the dot-proto file.
You can have an RSS feed saying, "There's a new version of that dot-proto file," and that dot-proto file can be 90% comments. You can just fill that thing with explaining what that field is, what format the string fields are going to be in, compared with WSDL, which was the description language for SOAP services. Nobody wrote WSDL by hand. That would have been insane. It was totally unhelpful. Yes, you could read it, but you're not going to do anything with it except pass it to a Java or a dot-net generator. Protobuf proto files, there's a lot more possibility to get documentation in there, although you still have to write it.
Database Schemas and APIs
Participant 1: I actually have two questions. The first question is, maybe it's a bit far-fetched, but well-defined database schema, in combination with a JWC interface, where the DB schema is considered as a contact between the consumer and producer, would you consider that as an API? If so, is it a good idea, these whole situations, or not?
Moderator: That sounds like OData to me, but with Java thrown in instead of Microsoft. That's just my head.
Rendle: I think, obviously, it is an API, but it's an API that only one application should be accessing. One of the definitions of microservice is, it has its own data store, and nothing else is allowed to access that data store. It may send logs off to some kind of data lake warehousing thing for a reporting system or so forth. Just going to people and saying, "Here's the database schema, here's the database. Have at it," is going to make your life very difficult.
If you want to refactor that database schema, if you want to make changes, if you want to add columns to a table, you can put in the documentation, "Do not do "select *" from customer," but somebody out there is going to do it. Somebody out there is also going to concatenate user interparameters into a SQL string and run it against your database. I would say, keep that access to the database through JDBC or ado.net, or whatever it might be. That's yours. Provide an API over the top of it, and there are things that will generate your GraphQL interface over a database schema. That's a much better approach, because then, you have control. If you want to change the database schema, you can compensate for that at the API layer.
Moderator: I like the point you got to about abstractions, and that having everyone directly access your database is usually a bad idea. A thin layer of abstraction, but you need a little bit more control. I think Michelle [Garrett] talked about GraphQL being a great use of that.
Garrett: There are lots of people who are using generated GraphQL schemas based on a database. Generally, I would say, try not to generate your schema and write it in a way that's human-readable. Not that databases aren't necessarily human-readable, but try and design schema that is more intuitive than just a generated version of a database. I think it is also a helpful tool. It can be some level of improvement.
Rendle: It's a good start point. Something to get you off and running, better than a blank screen.
Li: I completely agree with Mark's point, because I think the general design pattern especially, you see with microservices, is that you have the data store. You wrap that data store in a microservice, and you expose the functionality of the data in the data store through the microservice APIs, which gives you a little more flexibility around refactoring and access. If you're storing customer records in the database, you create a customer service, and then you have APIs to access that customer service that do the right thing. If you change your schema, the customer team actually really understands that.
RPC vs Messaging Interfaces
Participant 1: I had another question, if I may. When should you consider using RPC-like interfacing, instead of messaging, for example? Where does API fit in? When should you choose one above the other?
Li: The question, I think, is when should you use RPC versus messaging interfaces. I'll give one. One I think is a big architectural question. I would say, in general, what I see is, when they're building distributive systems today, most organizations start with an RPC-type interface because it's easier to reason about request responses. The mental model for that is actually pretty straightforward. When you start moving to event-driven architectures, you start doing a lot more async programming, it's actually pretty hard for developers to reason about, even though you can argue that there are a lot of superior semantics you get with a full async.
What I've seen is that people tend to start with RPC, and then, they run into some of the performance challenges and scalability challenges to RPC. Then, they go to something like gRPC, which still provides a lot of those RPC semantics, but packages them up in a nicer performance envelope. When I started in the microservices, I used to talk a lot about async, and I thought async's the way to go. Having seen the number of systems at scale that are basically fundamentally RPC, my point of view is, generally speaking, yes, RPC is totally fine. It's just easier for people to think about.
Rendle: I completely agree with that. I think if you implement everything as RPC, and there's something in there that should not be implemented as RPC, that will make itself clear fairly quickly. You'll go, "All this stuff here is ok. This one, we should come up with an alternative solution but certainly default to the simplest thing." The simplest thing is generally RPC, whether that's gRPC or just HTTP API requests, whatever it might be. Messaging gets really complicated, really fast, and it's also very hard to work with in development. It's very hard to mock a messaging asynchronous interface in things like unit tests and so on.
Large-File Transfers Across APIs
Participant 2: Just for context, currently, architects on a large private data science platform. One of the concerns, often, in API is that an API also involves passing around large files. gRPC, you can chunk stuff up, but it's pretty poor-performing at passing files around. Then, if not, from the front end, you're either stuck in multi-path forms, and sometimes, you want to pass around additional metadata with your files. Does the panel think there's anything that they can improve in that area? There are things like [inaudible 00:29:10] out there, which is a [inaudible 00:29:13] for restartable uploads of large files. Does the panel think there's going to be more protocol or specification that'll come along that's going to help with large-file transfers across APIs?
Moderator: I think it goes to a bigger question of, sometimes, you have one technology, and that's what you're using, and then you bump against the limits of it. That's what everybody's using, so you keep trying, but sometimes, it doesn't work out. That's one of those places where you have to recognize, "This isn't working." Maybe that's something I can carve off and say, "For all of our data, we're going to use one solution." For large files, do we find a completely different solution, and whatever fits, you do a spike and you try that?
Rendle: I'm not familiar with this particular problem space. I don't know how big is a large file. Is it a gigabyte, a terabyte, a petabyte? The data science.
Participant 2: Even just tens of megabytes become issues.
Rendle: This is just a complete idiot things. Stick it in S3 and pass a reference to the blog and hand that around, if you're transferring the actual file between lots of microservices. I see people worry that two things talking to the same S3 bucket is violating the microservice pattern. It's not, if you think of S3 as another microservice that somebody's built for you, that both those microservices are communicating with. You go, "AWS S3 is a microservice, and it can be accessed by other microservices," rather than thinking of it as the database.
It's very important, with all this stuff and everything everybody's going to be talking about today, don't get bogged down in the purist definitions of everything. Do what makes your system work best, work fastest, and serve your users the best, even if somebody on Twitter says, "No, you must never do that." That person on Twitter does not have your problem.
GRPC Web
Participant 2: Another quick one is, do you think gRPC Web is going to take off?
Li: There's gRPC, which is what Mark's [Rendle] talked about. Because of the state of browser support, they don't support trailers, and HTTP browsers can't access speech in RPC. There's this actual protocol called gRPC Web that browsers speak. You basically have a browser that speaks gRPC Web to a proxy, which then will translate the gRPC Web request, which looks a lot like gRPC, but isn't exactly gRPC, into actually true gRPC. The question is, do I think gRPC Web will take off? I think it depends on the use case. The main use case I've seen that drives people to adopt gRPC Web is that it lets you use the same proto for both your mobile clients, where you can actually implement a full true gRPC, as well as for your browser clients.
That's actually a pretty big win from a development perspective, because it's the same proto everywhere. I do know organizations that have done this. gRPC Web, though, hasn't really taken off as much as I would have expected, because I think the notion of gRPC for front-end is still pretty new. I think the main driver's going to be, as people start adopting and trying to do more streaming-type use cases, that those are going to actually start driving more adoption of gRPC. Short answer is, I'm not sure. I think that the use case for using gRPC Web is pretty clear, which is just consistent proto across all your front end. How much people care about that, I'm a little less clear about.
Rendle: One thing I think is interesting with gRPC Web is, in its standard form, you have to deploy a proxy container or standalone process. Then, your browser talks to that, and that talks actual gRPC to a back end. I believe the standalone proxy's written in Go. Microsoft, who are all in on gRPC now, because they really want to get rid of WCN, there's an optional library in their gRPC implementation for ASP.NET Core, which you put in as middleware in the actual gRPC application. It exposes it as a gRPC Web interface, just on a different port, but on the same process, the same application, the same container, whatever it might be.
I think, them having done that and looking at the implementation, which is really quite simple, people will go, "Hang on. We could do that as gorilla middleware in Go," or, "as express middleware in node," or, "as flask middleware." I think we might see that pattern becoming adopted across some of the other gRPC implementations, which would obviously make it much easier for people to deploy, and therefore, make it much more likely for people to worry about consuming it.
Garrett: I don't have a perspective on gRPC, but this is enlightening.
Jumping Onto Something That the Platform Is Not Ready For
Moderator: I do have a pre-written audience question from somebody who talked to me during the hallway track yesterday and couldn't be here today. What do you do if you're ready to make the jump onto something, and the platform that you're on isn't? The specific example was, they wanted to use HTTP2. AWS didn't have that support when they were getting theirs a year and a half ago, so they had to then introduce Envoy as something that could handle the HTTP2 requests. That one simple thing that they wanted to bring in and they knew they were going to get the benefits, brought in this extra baggage that they weren't prepared to deal with. What do you do in that situation?
Li: I think it just depends on your business need. If you have a clear business need for H2 and you think it's going to be a win, then I think you adopt the necessary infrastructure for it. In this particular case, I don't think it's actually that complicated. You're actually writing a dependency on Envoy, but you run your ELB, and then it's just TCP, and then you do that. I think at the end of the day, just really comes down to, how much business value is it for you to adopt H2, or whatever other technology. You want to make sure you're not adopting technology for technology's sake.
Garrett: If you really need a particular thing and the platform doesn't support it, then I guess, choose another tool or platform, since it sounds like it's worth the effort.
RPC versus GraphQL
Participant 3: In comparing directly RPC with GraphQL, what will you say that are the main strengths and the main faults of each other? Do you have any example of when you would choose one or the other, and why?
Garrett: I can talk about GraphQL, but I can't talk about...
Moderator: You can about GraphQL. I want to hear the pros and cons. What is the right use case to use GraphQL? When should I not use GraphQL? Large files, sounds like a bad use case for GraphQL. Then, Mark [Rendle] can do the gRPC.
Garrett: I think that the GraphQL is good for lots of things. Like any technology, it can be used for the wrong reasons or be abused. The main complaints I've had about GraphQL are things like, it performs badly, it's bad for performance. I personally have not had these problems working with it at Conde Nast, but in those cases, it sounds like it's that particular implementation of GraphQL which has issues. Maybe there are things going on behind the scenes, it's not the fault of the technology itself, although a common complaint in the GraphQL, how difficult caching is. Lots of people have issues with caching.
In general, I think that the developer-experience benefits of GraphQL have outweighed any potential negatives for us, just because it's improved developer happiness and productivity so much. I think that that's the main reason that people are adopting GraphQL.
Rendle: My take on it is, GraphQL, a graph query language, "graph" in this sense obviously means, enormous bunch of linked objects, as in, Neo4j or whatever. If you've got something like that, something like Facebook's graph or Microsoft's graph or Twitter or something, then GraphQL is fantastic for giving people access to the bits of that graph that they are interested in, and only the bits of that graph that they are interested in. RPC solutions, like gRPC, like Thrift, are much more, "You do this thing and let me know how that's gone." It's like functions. It just happens that you call this function, and then there's a network hop, and it does something, and then it returns the value for that function.
That returned value could be an enormously complicated object graph. Equally well, it could just be, "That worked," or an exception that you can catch and say, "That didn't work, because there's already somebody in the database with that email address," or whatever it might be. RPC is telling a server to do something, whereas GraphQL, I think, is much more about asking for information.
API Resolvers
Participant 4: I have a GraphQL-specific question, just about which resolver or back ends to use, but I've worked out the Java implementations. I've always felt that they were far behind the JavaScript ones that I believe are made by Facebook. Is that what people generally go with? Do they just use the node version for the resolvers and bolt it on to whatever their back-end technology is?
Garrett: GraphQL, you can work with it in multiple languages. As you say, there are libraries available in all sorts of languages, like Go, Ruby, Python, Java, PHP, lots of things. In general, GraphQL is super popular with web developers, maybe because of how product-friendly it is. The golden path will probably be JavaScript and nodes, and react. That's just what they are other best tools for, that's what I have used. Most people use Apollo. Relay has fallen out of favor. If you look at the graphs of popularity, it's quite low compared to Apollo, and Apollo really dominates the GraphQL space. Of the Apollo tools, the node and react ones are probably the best.
Tips for Using APIs
Moderator: Let's say you have your large, stable, revenue-generating system. My point that I made in the intros this morning is that you have this API. It's central to your system, and you're making money and you're productive, and you want to change it. Or it's legacy and it's WCF, but you need to keep it running, and you want to get it up to modern standards and use some of the latest tech. I know this is a leading question for of you. What are some tips you have?
Li: I think one technique – I've talked about this a little bit in my talk – is to refactor and produce a spin-off team, where you take part of your API and break it into a microservice. The beauty of an API is, you can maintain compatibility by putting the façade in front of it. Then, just service that API through a completely different technology stack. That's what I would recommend for you to experiment with instead of moving your entire API over to a new technology stack, if that's what you're looking at doing, is to move part of your API and put a façade in front of everything.
The other thing I'll point to is, there's a question around, how do you actually manage this transition when it goes to end users, especially if you put a façade in front? Even if you put a façade in front of it, you might have API versioning issues. The only thing I'd say on that is, if you Google Stripe API versioning, they have an excellent blog post around their API versioning strategies, which is much more evolved than anything I could actually articulate. I would recommend that you go read that.
Moderator: Or the InfoQ article about that. Michelle [Garrett], this is leading into your talk later. Give me the Twitter summary of, how do you migrate to GraphQL, and then keep evolving the rest of your system at the same time?
Garrett: Legacy APIs that are written in old technologies that you don't want to use anymore is a perfect use case for GraphQL, because you don't have to rewrite something in GraphQL. You can essentially put a façade over the top that is GraphQL, that resolves from the legacy API that is something that you might not want to actually do, that is something that you might not actually enjoy using. You have the ability to not rewrite something, but gain all the benefits of the new technology just by putting a façade on top. That's what I would recommend.
Rendle: Buy my stuff. I have been working on this for a year now, and I've got to the point where I can magically translate WCF to gRPC. The people that I'm trying to engage with, obviously, they have got teams out there who are using the WCF client. You're not going to be able to go to them and go, "We're gRPC now. Here's a proto file, get on with it." You do have to manage that transition. I think the key advice – and I'm writing up some documentation at the moment – is to unpick your caller logic and get that self-contained as a standalone component.
Then, you can either wrap that in gRPC, use the same packages and use it in your old WCF application, or whatever that might be, and your new gRPC application. Or, create the gRPC application, expose it publicly, and then modify the WCF application so that all those methods in there just call to the gRPC service and return those results back. The key thing is making sure that you haven't infected your very valuable code with somebody else's implementation and abstraction details of their RPC framework, whatever that might be.
If you always bear that in mind when you're writing a system, "This is the money, this is the thing we downloaded from Microsoft," or GetUp or whatever, and try and keep as much a dividing line between those things as you can. Then you can ask Google to have an HTTP API and a gRPC API. When they come out with whatever the next better thing is, then they'll be able to expose that as well, but still with this one core set of things. But also buy my stuff. Preferably the enterprise license, because that's really expensive.
Moderator: It sounds like another variation of the [inaudible 00:46:37] pattern, which I know Richard [Li] talked about, Sam Newman talked about yesterday. Several people mentioned of encapsulating the new stuff over here, and then you can slowly remove the connections.
See more presentations with transcripts
