Welcome back to another episode of The Rabbit Hole, everybody! Today on the show we are talking about one of our favorite recent subjects, GraphQL. To help us in this important task we have enlisted none other than Azat Mardan, GraphQL expert and author of React Quickly! Azat is going to help us answer the question of why GraphQL has taken over APIs in 2018 and tell all about his preferences around the framework and how it might help developers in their work. We talk about requests, caching, testing, security, and turnaround time and Azat really unpacks all the advantages and a few disadvantages for our listeners. We also discuss exciting new features and Azat ruminates on what the next few years might look like for GraphQL too. For all this and much more, come with us down The Rabbit Hole!
Key Points From This Episode:
- A little about our very special guest, Azat.
- The advantage that GraphQL offers in terms of requests.
- The long list of companies that have made the switch to GraphQL.
- Caching issues in GraphQL.
- TypeScript versus Flow.
- The benefits of testing and play in Graphiql.
- Some information on Prisma and why Azat is excited about it.
- What GraphQL offers in terms of pagination.
- The security benefits in GraphQL.
- Some of the difficulties in teaching the GraphQL framework.
- Schema stitching and data loaders in GraphQL.
- The most fun parts of writing a book on GraphQL for Azat.
- The time and speed advantages of working in GraphQL.
- Times when it might be a good idea to avoid using GraphQL.
- Looking at the future of GraphQL and what to expect for the years to come.
- And much more!
Transcript for Episode 90. GraphQL Takeover with Azat Mardan
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsey Manhattan. I’m your host, Michael Nunez. Our co-host today.
[0:00:09.8] DA: Dave Anderson.
[0:00:10.8] MN: Our producer.
[0:00:12.0] WJ: William Jeffries.
[0:00:12.8] MN: Today we ask why GraphQL has taken over API’s for 2018 and 2019.
[0:00:18.9] DA: It’s that time again, it’s the next round in the debate.
[0:00:22.7] MN: W talk about GraphQL for some time now a couple of episodes I think dave has the list.
[0:00:28.5] DA: Yeah. We ask in episode 52 is 2018 the year GraphQL takes over and then we have some hot takes with Steven. Our very own Steven friend of the show. Little tough love for GraphQL.
[0:00:42.6] MN: We’re going back to the positives, right back today.
[0:00:45.3] DA: Yeah, pro con.
[0:00:46.8] MN: Yeah. Today we have a special guest, we have Azat Mardan, how’s it going Azat?
[0:00:50.8] AM: Hello everyone, thank you for having me on the show.
[0:00:54.1] MN: Thanks for stopping on by. Azat, tell us a little bit about yourself.
[0:00:58.5] AM: Where to start. First of all, I’m top selling,, bestselling sometimes author of John script and JS and books. You might have seen some of my books on amazon.
[0:01:10.3] DA: Yeah, I think I’ve actually read one of your books at react quickly for react in GraphQL.
[0:01:16.1] AM: Thank you. It took only two years to write that.
[0:01:23.2] DA: There’s a modern feat, wow. Its’ kind of amazing because it was pretty digestible stuff, it didn’t take two years to read thankfully.
[0:01:33.9] AM: Just a disclaimer, I didn’t build any production apps with GraphQL or having traffic unlike I did with Node.js and DocuSign I really like GraphQL and I’m really excited about GraphQL and sharing whatever I learned in the process of writing that book, they’re like, first.
[0:02:01.1] DA: Yeah, I think it’s interesting, it definitely captures the imagination right now like you know, everyone has an opinion. I saw a thread on twitter from Nikolas burk one of the guys from Graphcool in Germany and he was having a conversation with some people, stout defenders of REST. They’re really passionate, it was fascinating, there is almost a values based discussion going on.
[0:02:24.6] MN: Right.
[0:02:25.2] DA: There’s REST people and GraphQL people and yeah, I think there are definitely benefits to both and I value and understanding that but GraphQL is pretty great, it’s pretty awesome.
[0:02:39.2] MN: Yeah, we’re here to talk about that today. We’re doing all the positive things and trying to get some of the benefits.
Azat, do you have a benefit you would like to start as to why GraphQL should be the framework everyone should use for 2018?
[0:02:53.3] AM: Yeah, sure. Let’s start with you have to make fewer request when you work with RESTful APIs as most of us do. I hope no one still uses [inaudible]. RPC or something like that.
[0:03:07.4] MN: Ouch.
[0:03:08.2] DA: I’ll never tell. I have done in the past but it’s all GraphQL for me, you know? Or REST, yeah. That’s true, having to – being able to get the data in a lot fewer requests, that’s a pretty nice benefit especially for something like a mobile application where every time that you send a request over the wire, delays and user experience you’re waiting but you also spend that battery.
I guess in a nutshell, GraphQL is sending a query for data over the wire so it’s getting back the data in the shape that you ask for it. That’s the nutshell version. Yeah, it’s also interesting how a lot of companies are switching to GraphQL right? There’s a new GraphQL foundation that’s being put together.
[0:03:58.7] MN: Anyone know the name of it by any chance?
[0:04:00.2] DA: I think it’s called GraphQL, The Foundation. Or the GraphQL Foundation I don’t know. Lead Byron is going to be having it up. Azat, do you have any companies that you are really surprised that switched over to GraphQL?
[0:04:13.1] AM: Yeah, actually I have a list in front of me when I was preparing for the last show. I’m surprised New York Times didn’t do it. Usually every time I go to news agency or website, they have so much junk on their websites pop ups and its’ so slow. I’m like, wow, New York Times, they use React and GraphQL well, maybe things are getting better.
[0:04:38.0] DA: Yeah, they’re definitely a serious company that has serious demands. I’ve read some of their engineering teams blog post on how they’re using it and it’s kind of fascinating. They have a lot of metadata in fields that they have to deal with.
[0:04:55.3] WJ: Are they using that when they serve up regular articles? Because those articles get in just a crazy amount of traffic.
[0:05:01.0] DA: Yeah. They do I believe. I was talking with our colleague, our beloved Adam, and he used to work at New York Times and he was kind of pining that he did not have GraphQL when he was working there because they had some really challenging things with a lot of different clients that were consuming data from feeds in XML form and those are the days that you're talking up before Azat, right?
[0:05:29.9] AM: Yeah. If you go to a lot of other news sites the amount of Javascript they’re trying to basically put down our throats and just incredible. Going back to the list of companies like the list of companies that’s reached to GraphQL, it’s huge. We’re talking about a general usage. You can install Chrome extensions and the websites and most of t hem you will see GraphQL there.
But also for public APIs which is an even more interesting use case because when you think about public API, developer experience matters in the more because you don’t[ have that communication with the API and documentation is to be really good and really up to date.
Companies that use GraphQL for public APIs are Dell, GitHub, Facebook and [inaudible] and others. GitHub really surprised in it because there are version four, it’s GraphQL only. They don’t’ even support RESTful API in their newest version of version four.
[0:06:34.2] DA: What? Why would they? It’s trash, it’s over. Yeah, V4 GitHub API is really like the gold standard. Basically, the team that I’m working on right now, if we have a question about how we should design something, we’ll take a look at the GitHub API because it’s quite robust, they did a really good job with that API at designing it.
[0:07:00.2] MN: That’s a pretty in depth list like you know, you have all these companies are moving forward using GraphQL and replacing REST. I need to start picking up some of this GraphQL knowledge, pick your brain Dave.
[0:07:15.8] DA: It’s over now.
[0:07:17.8] MN: Before I’m left in the dirt.
[0:07:19.3] DA: What am I going to do with those REST formation? No, that’s an interesting thing though. In that thread, I mentioned earlier with Nikolas, the people who are in the REST camp were talking about how they wanted to be respected still and like their skills still have value and that’s true. You can’t get away from REST. It is so ubiquitous, it’s everywhere.
[0:07:42.9] MN: How does GraphQL deal with caching? Is it a much biter alternative to REST?
[0:07:49.0] DA: Bobby. Yeah, it’s much better. There’s a bit of a learning curve about how the mechanism starts or how it’s used but you know, the Apollo client is a really great tool.
[0:08:03.1] AM: Yeah, I wanted to add that GraphQL itself doesn’t do anything with caching.
[0:08:07.6] MN: Okay.
[0:08:09.5] DA: Yeah, that’s true, GraphQL does not.
[0:08:13.3] AM: Then the GraphQL ecosystem of clients such as Apollo, Relay Modern and I’m not sure other language of the other clients and implementations. They do pretty amazing things with caching and for example in Apollo and Relay Modern, you get it almost for free.
[0:08:30.4] WJ: As between Relay and Apollo, which do you prefer Azat?
[0:08:34.4] AM: Apollo. Only Apollo, Relay Modern is too complex. It requires an extra pre build step so we need to compile our GraphQL’s inquiries before we can actually run them. Which - I understand why they did, it’s a pretty brilliant, it’s a very genius thing to have because it allows you to pre-fetch some data and make the performance better.
But not all applications need that so that’s an extra complexity which Apollo doesn’t have. The learning curve just so much easier with Apollo. That’s why I picked it for my course, to use it in the course.
[0:09:13.2] DA: Yeah, we had a similar struggle when William and I were both working at the same client and trying to decide which direction to go with that. Some folks were interested in exploring Relay.
We ended up going with Apollo because of the simplicity and because there was a large team that we had to all learn this new thing at once and Apollo was closer to paradigms that we were understanding.
[0:09:41.0] WJ: Redux.
[0:09:42.2] DA: Redux, yeah. Redux right. It kind of grew out of Redux and became its own thing. A bit further from it now but yeah, it’s pretty intuitive. I’d like to try Relay, one day.
[0:09:56.2] AM: Another difference, if I remember correctly, I haven’t used Relay Modern and they changed it. Relay Modern is, you don’t have to use React with it but Apollo is very React specific, you have to use react with Apollo.
For example, some people who use [inaudible] or angular, I feel sorry for them but they can Relay Modern.
[0:10:17.3] MN: Wow.
[0:10:18.9] DA: They cannot, right? Yeah? That’s interesting.
[0:10:22.0] WJ: Have you run into any problems with cash and validation Azat, using GraphQL?
[0:10:27.8] AM: Yeah, I ran into some.
[0:10:28.8] WJ: Using Apollo, I suppose?
[0:10:30.7] AM: I think that was actually what Relay, I get about that and just the different implementation.
[0:10:38.9] WJ: This is the thing I remember us running into.
[0:10:41.5] AM: Instead of actually using caching, I would just fetching on demand in that particular case.
[0:10:47.3] MN: Yeah, right, just like setting the option like let me not deal with the cash right now. Yeah, we did have that problem and it continues to haunt people. But I think for the most part, we have figured out, just have to design your requests and responses properly.
[0:11:06.6] AM: Those I’ve mentioned that don’t have that much like higher level advanced experience, you probably know more about those edge cases and memory. I’m more kind of the [inaudible] guy.
[0:11:21.5] WJ: You just literally wrote the book on it.
[0:11:24.8] AM: It’s actually better to write books about Hello Worlds; they don’t change that question.
[0:11:30.5] MN: Note to self.
[0:11:32.7] DA: What are some other benefits that you find really compelling to switch to GraphQL?
[0:11:38.3] AM: People like TypeScript or Flow, more people like TypeScript.
[0:11:42.1] MN: Yes. I like – I don’t know why people use Flow, use TypeScript. If you’re using flow, stop. Use TypeScript.
[0:11:51.1] WJ: Shots fired.
[0:11:53.9] AM: Like TypeScript because of typing. GraphQL gives us typing for the data and strong typing has a lot of benefits as any other technology such as [inaudible] or some other typing such as Java. With strong types, we have better and the systems are more robust because the client and the back end, they can communicate more predictably with the schema.
Also, we can do some type of optimization such as Relay Modern doing and also, we can enforce better validation which improves security. Some restful APIs, they try to do JSON base types but the standard is all over the place so why bring them the real way when we can just use GraphQL, that’s the greatest standard.
[0:12:45.0] DA: Yeah, that’s sure like there are some competing JSON schema standards out there which I guess that’s always what happens when you have – let me make one thing that will unite them all and just one more standard.
[0:12:59.1] WJ: [inaudible].
[0:13:00.3] MN: 37 other standards.
[0:13:02.7] DA: Yeah, having the typing like built in to GraphQL is pretty huge. Not only for the reasons that you're mentioning about the benefits that gives you for security and for predictability but also in terms of developer happiness and productivity. I can look at this field and it is self-documented that this is going to be a string or this is going to be a date or a number of what have you.
Having that like built in as a first class citizen instead of an afterthought I think is really powerful.
[0:13:36.2] WJ: Yeah, it’s hard to argue with a documentation quality in strongly type domains.
[0:13:41.3] AM: Yeah, self-documentation basically, almost for free and the documentation and then we have that GraphiQL right, which is a nice integer where you can just play like a sound box, try it our queries, no more postman.
[0:13:56.4] DA: Yeah, that’s really wonderful for new devs on my team. People are always like amazed when you can just open a browser window and just explore and play around with - I think that’s something I like that is proven through science I think that if you can play with something then you can learn easier and you know, you can try a little experiment and see what happens.
[0:14:23.6] MN: That’s using GraphiQL you mentioned Azat?
[0:14:26.1] AM: Yes, GraphiQL, it’s usually calls with the GraphQL library when you install it with no JS. Just automatically sit in the browser. You can use it.
[0:14:36.6] MN: Yeah. There are some other ones too like GraphQL Playground I think is another one, that’s also a little bit more robust feature.
[0:14:44.9] AM: [inaudible] has a good editor as well.
[0:14:48.7] MN: I suppose of using like say if I was still a RESTful person, I would have to use Postman, right? That’s like the equivalent to Postman?
[0:14:57.2] AM: More or less.
[0:14:58.1] DA: Pretty much, yeah.
[0:14:59.3] MN: It’s just so much easier to hook in to GraphiQL on get data it seems?
[0:15:03.0] DA: Yeah, not going to like hold your hand and then show you the documentation and autocomplete when you’re typing.
[0:15:08.0] MN: Definitely doesn’t. Postman does not help at all, ever. Love you Postman, you’re great. Shout out to Postman team.
[0:15:15.5] DA: Yeah Postman is great. I use it with GraphQL sometimes.
[0:15:19.0] MN: Sometimes yeah.
[0:15:21.2] WJ: What are some of the new developments in the GraphQL ecosystem that you’re particularly excited about?
[0:15:26.7] AM: Well, Prisma is pretty interesting.
[0:15:29.6] DA: Prisma, yeah. I haven’t dug into that too much. What is Prisma and like, what do you find exciting about it?
[0:15:35.9] AM: It’s by the same team that developed [inaudible] back end as a service and get on link, you can get GraphQL. With Prisma, you basically have your back end or APIs and then you get GraphQL interface. Prisma sits in the middle with other APIs you have.
Because the biggest use case for GraphQL, it’s not purely API from scratch, a lot of companies, especially companies. They do have their legacy APIs already. The biggest use case and the biggest win for GraphQL is to sit in the middle and add this middle layer that will provide very nice data, aggregate data, make multiple calls. All the nice things that developers like users also can improve performance or applications.
[0:16:27.1] DA: Yeah, that is a pretty neat application of it to glue together things. Because I guess like, no matter what you do, you’re going to have that one APPI that you can’t really get rid of and putting GraphQL in front of it will help you standardize the interface of it, standardize the documentation of it and maybe even eventually help you deprecate it and get rid of it completely if you’re trying to get rid of like that legacy system.
[0:16:56.9] WJ: Yeah, I think GraphQL has some advantages when it comes to paginating, is that right?
[0:17:02.2] AM: Yes, GraphQL provides support and basically in your queries, you can describe what type of filtering pagination and how all of that can be implemented. If we try to do the same thing with restful APIs, it will take more ingenuity, you basically have to ask what is a sorting order like escape offest, all those integers they need to be passed in the URL or some other way.
GraphQL can take all that in the query, which is more natural but it’s better to read and for back end engineers, the API engineers, one, they implemented once, they don’t have to worry about it. Clients, they will have the control to request whatever they need in terms of pagination sorting and filtering and whatever other parameters it is a part of.
[0:17:57.7] DA: Yeah, I think that the Relay pattern for pagination is pretty powerful with the cursor based pagination and like having a standard way to do that, that’s kind of generally accepted in the GraphQL community is pretty great.
And the flexibility you get from having the ability to add arguments to any field for sorting and filtering and what not, that is pretty awesome.
[0:18:26.2] WJ: Yeah, it feels a lot like you’re just talking directly to your database. You know, just like the same way that you could do pagination of results and sorting pretty easily, if you were writing SQL. Although, that sort of raises the question, if you have an API that allows you to feel like you’re basically just talking to your database, how do you prevent other people from coming in and ruining all your data? What are the security implementations of an API so powerful?
[0:18:50.2] AM: That’s a great question, security is super important. The way [inaudible] services from GraphQL services is in this, implemented it by using API keys. Either a token and the secret or just API keys. So either token or a secret or just API key, I could be all authorization. It is an obligation based authorization in ACL, access control authorization. Then each individual they would – it could have its own permissions. So for example, “We write…” et cetera. This is not related to GraphQL as much as implementation of the GraphQL [inaudible]. So GraphQL is a protocol that tells you this is the query. This is data dives and this is the output.
And then developers, what we do on the backend that’s pretty much a up to us. It’s always the same metaphors that I like to give in the framework can provide some security measures but some developers would still make [inaudible] right? So same thing with GraphQL, it is possible to create a bad API. Ultimately, GraphQL would not prevent. What GraphQL helps with is that less data is transferred to the client.
So for example, I have a user collection and the user’s first name, last name, email address, social security number, phone number, etcetera. So not all the clients they need their social security, right? You should be able to restrict that access but the API for the outside looks exactly the same. It is also the benefit of GraphQL.
[0:20:32.5] DA: Right and that you were just have a field level authentication or authorization for that particular piece of data. A lot of flexibility. But you do have to be aware that you can make that hop from the post to the user to their social security number and you have to keep that in mind.
[0:20:51.0] WJ: I think you’re pretty expert not just in the field of GraphQL but also in educating people about GraphQL. Can you talk a little bit about some of the challenges around teaching people this kind of a paradigm?
[0:21:03.6] AM: The biggest obstacle and the biggest challenge is that for years and years and years, I think at least was 10 years, the better thing since the slice of bread was the RESTful APIs.
[0:21:16.4] MN: Oh yes.
[0:21:18.6] AM: We were just hammered, right? It’s like everywhere you go was like, “This is [inaudible], this is post, the hold on Rails.” They did a lot of that. You just exit accounting and you guys work with clients actually you are familiar with this model, [inaudible] rails they grew out of that model.
[0:21:37.9] DA: Oh yeah, got so many arguments about what is the most RESTful form of this API.
[0:21:44.5] MN: Yeah.
[0:21:45.0] DA: What does it truly mean?
[0:21:46.6] AM: Yeah, we’ve built those controllers in Java, in Ruby ,in Python. We build complex, very complex and reach single page application which are not single page anymore but we still call that single page and we call those RESTful APIs but a lot of times, some of those calls they don’t make sense. For example, I am signing up or I am logging in and so there is no post plus signing up, right? Since sign up was not a real database table.
It is not among it in the collection. It is a virtual end point that will create a record in the user’s collection than my password and username. So that’s a limitation of RESTful APIs but developers are very smart so they found out how to read with those limitation of RESTful APIs and they’re pretty comfortable and they don’t want to change. It’s just human nature, people don’t like to change and they become very religious and very against anything new.
They are tooling, going back to Postman, they have their frameworks. That works, they know how to test it. Yeah so that is the biggest hard part of how you make people not being afraid and the jubilation is good for that sort showing them this actually works, this is easier, this makes sense with React. It is natural, but not JS, well let’s try using it small and then find a way to use it in your project.
[0:23:19.2] DA: Yeah, definitely. I agree. It is a big leap to go from -
[0:23:25.1] AM: The most push back I get is from backend developers. The frontend developers and mobile developers they get it right away.
[0:23:33.0] MN: Oh interesting.
[0:23:34.5] DA: Yeah, I think it is a full stack developer like I have more of a perspective on that too, yeah but like if you tell someone that you have to learn a completely different tool chain in order to be productive and nothing makes sense that it used to make sense, there’s a plain challenge.
[0:23:52.5] AM: Another confusion, some people are very, very confused about like where the data comes from. I keep explaining them there is a resolver and then the resolver is the active function. You put whatever draw you could you want, you can call your GRPC, your thrift, you can call the database, you can read from a file system like that is where you put the code and it’s the schema but you have blank stares, people still don’t understand it.
[0:24:22.8] DA: Have you dug much into dataloaders?
[0:24:25.3] AM: No, what is it?
[0:24:27.0] DA: Dataloader is like a paradigm for batch loading of data in GraphQL. Yeah, it’s interesting but it is another layer of abstraction to wrap your head around if you want a performant GraphQL API.
[0:24:44.3] AM: Yeah.
[0:24:45.3] DA: That’s been a challenge for me because I think the documentation is pretty thin. There’s not many blog posts. So you’re like on your own when you start to have that scaling issue, trying to learn how to do things in a good way.
[0:24:59.5] AM: Yeah also the schema stitching.
[0:25:02.3] DA: Oh yeah.
[0:25:03.4] MN: Skim less teaching, was it?
[0:25:05.0] AM: It was schema stitching.
[0:25:06.4] MN: Oh what is it?
[0:25:07.2] AM: That’s like when you have a lot of micro term resist and a lot of schemas and then you would try to how to wire GraphQL or few of them, GraphQL APIs you need to stitch the schemas.
[0:25:18.8] MN: So like someone reaches out to certain pieces of information that has to go through different micro services, you have to stitch the data and then give it back to the user?
[0:25:30.3] AM: Yeah, more or less. So it is like combining multiple schemas.
[0:25:33.7] DA: Oh wow. Yeah, it is a pretty neat concept. I like the idea of it unless you’ve been dealing with a monolith but it seems like an interesting idea if you are trying to have like a micro service or if you are integrating with a third party API like GitHub.
You could glue some GitHub data into your schema somehow and do something crazy. I don’t know, you got to some prop dev to figure that out, do some project.
[0:26:01.6] MN: Do some stitching. I have a question, so in writing your book on GraphQL what was the most fun you have when writing this book - what was the concept that you felt was the most important for your readers to know?
[0:26:15.5] AM: That is a tough question because I had a lot of fun writing pretty much all the chapters and I would find time when I would fly to a conference I remember I was in Oslo, I had spoken in DC and Oslo conference and I was sitting in their coffee shop and writing three chapters and editing.
So those are wonderful memories but I think I had a blast especially in the beginning explaining the easy concept and some of the history with web development and frontend and backend and cracked a lot of jokes and people seemed to like that.
[0:26:52.0] MN: Nice, jokes - yeah jokes will get me reading.
[0:26:57.8] AM: One thing I wanted to mention also is that GraphQL improves the speed of development.
[0:27:04.2] MN: How so?
[0:27:05.0] AM: This is just my anecdotal evidence. I don’t have any high data to prove it. But think about it this way. So when you have a separate backend and frontend team or a regular team, you tend to have more meetings, a chance to understand what the API needs to look like. What the clients need in terms of fields and resources.
And then you have other meetings to hand off the work and then you have another meetings because there are bugs. And you need to fix all the new requirements. There’s new UI, you need to basically go back to the API team and tell them like, “Hey we need an addition to those fields or we need something different,” and the API team they tell you, “Well we were busy, we have an earlier schedule, we missed it so come back in a month.”
[0:27:53.3] MN: Yeah that happens way too often, right now.
[0:27:57.6] DA: The other times you’re going to listen to Episode number 82, Seven Wastes of Software Development, that’s all over the waste. It’s all about waiting and all of that stuff.
[0:28:07.9] MN: Right so go back to your point Azat, with GraphQL if I can just reach into whatever piece of data, I don’t need to iron out any JSON contracts within the backend team because I am able to just retrieve whatever data than necessary to display it to the users, is that correct?
[0:28:27.5] AM: Absolutely and that allows us the client developers, the mobile and frontend developers an easier way to make changes way faster. That’s what makes the difference in this competitive world where companies ship to production multiple times per day, right? You don’t want to waste time, you need to be as fast as possible, as AGILE as possible.
[0:28:51.2] DA: Yeah and also if you need to iterate quickly. And you make a small set of fields and maybe it suits your needs right now and then they might expand to a larger set up over time or you know maybe initially the requirements are that we only need the name of the book on the page but then eventually they need the ISBN. It’s like, “Okay I don’t need to go add that to the backend. We already have it.” We have this already. We decided to move that.
[0:29:23.4] AM: It’s a completely new product which no one knows right now but a month from now they can just build it using your great GraphQL API.
[0:29:31.9] MN: Oh wow.
[0:29:32.5] DA: Yeah, I would say I have anecdotal evidence that would confirm that although a little bit slower in the frontend when you are laying the ground work but as soon as you get those Legos in place then you can really build a lot faster.
[0:29:48.4] MN: Right because you can retrieve whatever data you want regardless of what the backend team is serving up as long as they are serving up the data necessary for you to complete the work then everything is fine and dandy with GraphQL as opposed to the REST where they have to go and make updates to the JSON contract and all sorts of gnarly things.
[0:30:09.9] DA: Yeah I mean it’s still software engineering so you’ve still got to do that. I like working full stack with GraphQL because you don’t have to ask that guy for the field to use if it’s missing, you just add it.
[0:30:23.3] WJ: So what are some instances of times when you really don’t own or use a GraphQL?
[0:30:28.4] AM: That’s a fair question because in technology often times there is no perfect solution, right? So it’s good to know and use the best tool for the job. So I wouldn’t recommend using GraphQL when all you are building and all of your clients’ needs are just a simple crowd based, create, read, update, delete based, resource based API.
For example, Flash users, flash [inaudible], flash resume ID. So there is no pagination, there is no sorting, there is no filter, it’s just a simple crowd base resource based API. That’s fine, GraphQL would be probably unnecessary abstraction and it could slow down the performance and it is just another layer, right?
Another reason why people shouldn’t use GraphQL or should be careful is when they need to load multiple resources on the frontend asynchronously, independently. So we are not talking about nested resources. But a resource that is independent of each other so by loading them in parallel and maybe you could use a CP2. Probably should use a CP2. Then you will get better results than combining everything into a single request. Then there are other reasons as well, someone who is not planning to make free contingents, someone who is not planning to roll out a new product or expose an API to public. They invested a lot of time and effort and money into their RESTful APIs.
So if it is working and there’s no changes in the future, if it is a mature product that’s my goal and removing the end and introduce new bugs -
[0:32:14.7] MN: Yeah, if it ain’t broke don’t fix it. Unless you have to. Unless you have to use GraphQL.
[0:32:23.1] AM: Unless it’s ES5 then we’ll have to.
[0:32:26.9] MN: Yeah. Azat, where do you see the future of GraphQL? We’re in 2018 right now, as you mentioned before it should take over APIs in the future but where do you see it within the next year, three years, five years and beyond?
[0:32:42.1] AM: Well I think it is already took over a lot of APIs in a lot of companies internally and publicly and this was very surprising to me and didn’t expect it all. I looked on GitHub as I mentioned and while there’s no REST API and Facebook and Shopify are some other big examples.
So the future is bright, the future is so bright we’ll all have to wear sunglasses.
[0:33:09.0] MN: GraphQL sunglasses, I’m ready.
[0:33:12.1] AM: It would be more backend as a service, tools with the AWS, Azure, Google Cloud, would be supporting more of GraphQL tools and services on their cloud platforms. I think there would be consolidation in the market of the open source tools and the backend as a service, things such as place migrate that whole. There used to be a lot of them now some of them are running out of money and they would pay consolidation. So we will have clear two or three winners. In terms of GraphQL backend as a service.
People will be getting into mainstream. It looks like we are getting into mainstream adoption. Remember that curve? There’s early adopters, migrates, mainstream, et cetera, et cetera. So there’s like five stages. Yeah, we’re getting into mainstream, et cetera. There’s like five stages. We’re getting into mainstream and it would be surprising in two or three years that people would develop GraphQL first and RESTful maybe second or maybe not at all.
[0:34:13.0] MN: I guess II got to start learning now. If I don’t learn now, maybe left in the dirt. I’m going to be burned. You got a course, Azat?
[0:34:25.5] AM: You have a code for it.
[0:34:27.6] DA: Yeah, this is a good transition.
[0:34:29.5] MN: Awesome. Azat was kind enough, tell us a little bit about the course before I give them the spiel.
[0:34:35.1] AM: It’s a course on manning. Manning Publications, the famous book publisher and how they got into videos and I love their video platform, it’s better than [inaudible]. They have all the transcription at the bottom and basically it follows the video and the audio. You can just click anywhere in the text and boom, it jumps straight to that point.
Let’s say you saw some snippet of code, you want an explanation so you can jump right to that, you cannot do that on YouTube, you cannot do that on [inaudible]. It’s amazing and I created a course with Manning and the course is short, that’s why I recommend it. I don’t spend five hours or 10 hours on the basics, it’s basic and it just started and then you can take it from there.
[0:35:23.2] MN: Where is the course located? Where can people go to see the course?
[0:35:27.4] AM: Manning, live videos, Manning, GraphQL, Apollo in Google, that should get the results and I’m sure you’ll put it in the notes.
[0:35:37.8] MN: Yeah, we’ll definitely put a link in the shownotes. What is that secret code? I got it right here. For our listeners, there is a 40% discount code.
[0:35:48.3] DA: 40%?
[0:35:49.4] MN: 40%.
[0:35:49.7] DA: Gosh.
[0:35:50.3] MN: Yeah. Azat was kind enough to bless us with the discount code, thank you so much first off for allowing us to share the discount code. It is, podrabbithole18. We’ll definitely try and get this on the show notes so that individuals can go and check it out and subscribe and check out the video and we’ll try to add as much information as possible.
Azat, how can people contact you?
[0:36:24.1] AM: Everyone, go in LinkedIn and connect with me and write what are you doing with GraphQL and how you like this on the podcast, I love getting feedback. Just LinkedIn, Azat Mardan.
[0:36:39.0] MN: Awesome. It was a pleasure having you on the show, Azat.
[0:36:42.8] AM: Thank you, it was fun.
[0:36:44.2] MN: Do you have any Twitter? We got a twitter action or?
[0:36:46.9] AM: Yeah, I have Twitter, Azat Mardan. I have a website, it’s just azat.co without the M. azat.co where I’ll have all the links to twitter, LinkedIn, Facebook, Instagram, YouTube, podcasts, books.
[0:37:03.9] MN: Videos. Manning, GraphQL, Javascript. Fill in the brand, there you go. Awesome.
[0:37:12.0] DA: [inaudible]
[0:37:13.7] MN: Awesome.
[0:37:14.1] DA: Check it out.
[0:37:14.5] MN: Azat, thanks so much, thanks for coming on down.
[0:37:17.8] AM: It was fun.
[0:37:18.3] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five star review and help developers just like you find their way into The Rabbit Hole and never miss an episode. Subscribe now however you listen to your favorite podcast.
On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
Links and Resources:
Sponsor
StrideOur seasoned cross-functional agilists work with you to develop technology, ship product and deliver value. We leverage our diverse expertise across industries and throughout the organizational growth cycle to your benefit. We bring best practices, emergent practices and creative solutions to your problems.
