 Let's go over a bit of GraphQL. So Mike, I don't know. Yeah, I can also use this one. Oh, okay. Right. So I'm Alex and I'll be talking about GraphQL today. So I'm Alex. I work primarily as a front-end developer at Hook and I've been in Singapore for about four years. Generally, working with JavaScript most of the time, but I also like to play around with fewer things. So I've been playing around with a bit more of Rust in my free time as well. I think a little bit different. Also, TypeScript is one of the things that I'll be pushing a lot in this talk as well, I think because it works naturally very well with GraphQL. So in overview, we're going to just go a bit into what is GraphQL and why you could care about using it. We're going to be talking a bit more about the server and the client side using mostly Apollo GraphQL framework, which is pretty good. There will also be going over some brief examples, talking about the basics of GraphQL on both front and back-end. Some alternatives, there are alternatives, and most people probably don't know any of them. Then some closing remarks and questions at the end. So what is GraphQL? It is a modern query language that is useful. Oh, I did that. Die. That was not very good, was it? I can also just do that one if the Internet is not going to be working. But anyway, yeah, what is it? It is a modern query language that allows you to have much better declarative typing and data type. So it allows you to have better control over the data you're getting rather than the typical REST APIs that we've been using in the past. It was developed by Facebook a good few years ago, well, 2015 at this point. It uses schemas which work naturally quite well when using things like TypeScript as well to share them between the front and the back-end in different sections. It's generally one endpoint that you'll be using, which is also much nicer when you're dealing with lots and lots of microservices or whatever your architecture is. So it makes things a lot simpler to organize as well because that can be quite a hassle. And then there is a lot of type checking, which is also why it works quite well with TypeScript as well. They work pretty much hand in hand. And the main things you need to be focused on in GraphQL is going to be from the queries and the mutations. The queries are basically how you're going to be getting the data and what type of data you'll be getting, whereas the mutations are what you're going to be, either your post or put request to the database normally or ways of changing the actual data. So the problem which has became ever more apparent is architecture has changed a lot. So the client is no longer relying on just one back-end service. Now we're working with many, many different microservices, different databases, different frameworks everywhere. So it can be hard to get all the data in one location, especially to normalize all the data together. This can be a big problem and it can lead to a lot of inconsistencies. It can lead to a lot of headaches and a lot more pain on the client's side. So as a result, GraphQL has kind of came about to try and solve this problem by acting as an intermediary platform between the client and the back-end. So essentially it streamlines the whole process. So you start off with the front-end, GraphQL and all the back-end process that can be connected to it. It's been quite widely adopted over these past few years. So it's been taken up by many of these companies, including more like Airbnb as well. I've also been quite good at pushing GraphQL. Netflix is an interesting one because they actually developed their own version, their own solution that was solved. So my problem with GraphQL, which I will touch on later, but even they're using it these days as well. So yeah, like I said before, the whole purpose of GraphQL is to try to solve the problem of the modern way of microservices using different products, putting it all together and making it a little bit simpler for everybody because we have too many endpoints. The other thing as well is that the typical REST APIs that we've been using, they lack a lot of control over the data itself. You just ask them something, they'll send you a bunch of data, they don't really care about it. GraphQL is a lot more, can be a lot more opinionated, you can get the data you want and it allows you a little bit more flexibility which helps a lot when you're dealing with big data. It can eliminate a lot of the slow response times because you're getting the data you actually want rather than just lumping a load together. So what's one of the other big things that REST has been lacking? So yeah, GraphQL from the server side has actually grown quite well. It was so largely, there's still a lot of support for it in JavaScript so in Node.js, using things like Apollo. Apollo is very good for both server and client and it combines them together quite well. However, there is also support for other languages that just go and there are most of them actually supported at this stage which allows you a lot of flexibility in the way you want to write and work with it. Yeah, there's a very large JavaScript community behind GraphQL so it's usually quite easy to pick up and keep going on with. One of the nice benefits as well is that GraphQL comes with GraphQL playground built into it on both the native and the Apollo version of it. This allows you to actually start testing and playing around with your responses and it gives you quite a nice framework to work within to actually make sure you are trying to get the right data that you want. The documentation is also really nice and easy. It's built kind of into it because no one likes to document so it kind of makes it a very straightforward process. We can just add it as you go along as you're adding the tags into it and it actually produces quite nice documentation about too much hassle which hopefully encourages people to document better for even things like Swagger, people still don't update very often. It caches as well by default and it has a lot of caching rules you can update and change and this is really nice because it also will help speed up and eliminate any round trips as well. Yeah, heavily streamer-driven TypeScript. It works very well with TypeScript. It is one of the big things about it and yeah, the diagram kind of just explains more of the server and client interaction. So, from the client side it's actually compatible with any front-end framework. Obviously it works pretty well with React because it was built by Facebook as well. So React and GraphQL is like a natural fit but it's no problem to get it running in View or Angular as well. Again, the whole idea is that you can just have the one endpoint in the front end and it will just call it and you can just get all the data that you want. As well as because if you're working with JavaScript you can do your schema sharing quite easily. Especially with TypeScript you can just have your schemas on the back end and share them between front and back and it allows a lot more consistency with the data and hopefully prevents too many areas along the way. There is a lot more control over the data which is one of the big things and it can actually help reduce dependency on Redux if you're using React because oftentimes you're doing a lot of shaping of data or altering data via React so you can actually start to push that into GraphQL instead and GraphQL can shape the data before it even hits the front end which can be quite a big benefit and it can actually reduce quite a lot of the overhead on the client side. So one of the examples is when we're looking with, oh this isn't gonna work very well, is it? Because it's overly. One of the examples really is how quick and easy it is to really set up GraphQL using Express. This is just looking at using Express and Express GraphQL and essentially you can just set up by hooking GraphQL HTTP in and then you just write your schema and put it into here as well. This is really all you need for the part of the server then it's all about writing the schema itself which is in this one. So you have the GraphQL schema here, query name description description is what essentially leads to the documentation in the end and then the name we want to start with a query. Then we have the fields. This just comes on about the type. So we assign types where I think types are created even by also there are some built in types as well. Then there's a different arguments that we can accept such as the ID or the type which allows us to query specific things. Then our resolver, we also build down here but then actually paste it at the top as well. So it's easy to see. The resolver is basically where you can call your response. You can then alter the data anyway you want and then the return data the way that you want to get it in the end over here. So this, the resolver is kind of where a lot of the magic actually happens within GraphQL allows you to kind of alter, shape, change, do whatever you want so that the end result is clean or the type of data that you're wanting to get. And this is kind of repeated throughout all of them. They all follow a very similar format on the back end and this actually allows you to get up and running pretty fast with GraphQL. Then on the front end side looking at more react this one, yeah it's not gonna look so great because it's overlapping and that's not working. So on the front end side, you essentially have to hook it up. This is using Apollo GraphQL. And there's a few different ways you can work with it and there's a lot of different tooling and different plugins you can use on the front end to allow you to do either very complex or a little bit more streamlined querying of the data. This one is when I was using one of the smaller ones just to get the observable and subscribe to it. So this allows a lot more flexibility because there's a few different ways to work with it. You can either do like a full one that will actually map out through areas and all the different responses which is actually behind this, this doesn't work. But yeah, so this is just one of the ways of doing it. I found this quite a neat way of doing it. It allows you a lot of flexibility, observables and using subscribe actually work pretty well. No, it says not very good. So as a result, it gives you the benefit of allowing you to just get the data and then if you're using React, you can just push it into Redux and just keep it there as you go. I think- I'll keep talking as I go into the next slide as well. Yeah, so, technical difficulties. So then this is essentially how you log in, I guess, if it actually works. But this is an example of how you would set up the actual query itself. The queries are fairly straightforward. So this is for searching and then you're adding the variable up here to allow, this doesn't work. It's not working. So this allows you to actually do the querying itself. Yeah, the query, the exclamation mark at the end of string to show that it is a required argument and then it'll get passed in and then this is the return data that you'd be getting from it which you can put anything that you like from this one. I don't think it's gonna work. Yeah, I have a good thing about you. I don't think so. This is a very good example that you should. No, it just doesn't work. It's okay. Yeah. So yeah, this is essentially how you write the queries. Mutations are similar, mutations are a little bit different because you don't use queries mutation instead of the beginning. But with this, this is the return value. You can obviously put whatever you want in here, but what's nice about GraphQL is it doesn't have to be everything because you have to take your database or whatever you're getting this from. Could have many, many columns. You only have to pull back what you actually want to deal with which is really one of the powers and the nice things about GraphQL that people like. Okay, so some of the alternatives to GraphQL are also fairly interesting. So GraphQL is by far the biggest, biggest one out of all of them. And the other two are really not so used. So Filecore is interesting because it's developed by Netflix. So that kind of makes sense from the name Filecore. If anyone remembers Never Ending Story or is old, I guess. The community is very small. It's quite powerful, but it doesn't actually have the full power that you get from GraphQL. So it does do, it is a type of query language. It's just not a complete one. So there's lots of things that it misses out that GraphQL actually will do for you. Then there is Resql. And Resql just seems like nobody really uses it because I couldn't find many people or even like a logo or transparent background. So there was just nobody that seems to use it. But maybe it's good, it's so easy, there's no question. That is also true, that is also true. But it is easy to pick up. It's Python-like syntax. If you like Python, I don't know. There's a lot of JavaScript developers, so probably not many people like Python. Yeah, so there's just some alternatives. I find it interesting that Netflix did develop Filecore and they've started using GraphQL quite heavily, so. What do you mean by, when you're saying this comparison, like complex but powerful and powerful, just powerful. So what do you mean by that? And what do you mean by full query power? Where's the difference? Yeah, so I did have that on a different, it might actually be on a different slide. This one, yeah, so the main, one of the big things that this doesn't do is it doesn't support ranges, but it's not open-ended queries. Whereas GraphQL would allow you to do more broader-based queries. And Filecore is definitely a little bit limited from that perspective. But it does a lot of the syntaxing, it's quite similar to GraphQL. So if you can write with one, you can probably understand the other one as well. But yeah, it definitely misses some of the more complex parts that GraphQL allows you to do. The open-ended queries is the main one that I found that people seem to have a big comparison about. But a lot of it is fairly similar. Whereas, yeah, like ResQL, the, I don't have the example on this one, but like you write a lot less, again, like, it kind of like Python in many ways. You write a lot less code to get quite a lot to happen behind it. So it actually obfuscates quite a lot of what you're doing. And that I think makes it, is one of the reasons why it made it easy to pick up as well. It's also written in closure, which people like as well. So yeah, this one, ResQL, hasn't seemed to be picked up in the same way. I guess Facebook have put a lot of stuff behind GraphQL, it's been picked up a lot. And like I say, this one, it's a lot shorter. If you look at the syntax and the way that you're writing it, it will be a lot less to write compared to these two, which you're writing quite longer documents to actually get it to do similar things. Yeah, so GraphQL and kind of why you should care about it. So it is suited to much bigger projects. That definitely helped, especially if they're very split ecosystems and maybe have lots of microservices. You might have a few databases, they're all scattered. GraphQL helps you kind of be that one point that brings everything together. And it allows a lot more control over the data that you're doing. It works really well with TypeScript as well. If you're using obviously in Node.js. So TypeScript is really great because they can then write TypeScript on the front end, TypeScript on the back end. You can share the schemas between the two. You can make sure all the data is flowing accurately and making sure you think it's correct, which is why it works really well with TypeScript. It adds additional power as well. A lot of this comes down to it actually having much more flexibility than REST. REST would just force all the data down. GraphQL, you can be much more selective. And then also with the caching that it offers, it can help reduce round trips as well, which is also quite beneficial for speed. It is becoming more and more widely adopted. It was open sourced in 2015, but it's been picked up by a lot of big companies since. Obviously like Netflix, Airbnb, obviously Facebook. Quite a few different big companies are picking up and taking it much more seriously. So we've gone past the fad phase of GraphQL, which is one of the big problems with technology. Yeah, finally, a lot of people have always said that oh, it's gonna be like the REST killer, the REST for API killer. It doesn't really kill REST. It just changes the way that you use REST. And it will change the way people structure their backend a lot of the time. But it won't, I can't foresee it ever killing off REST because REST still has its place. But it does help you have a little bit less reliance on everything being REST, which is a bit nicer because REST is a little bit too flexible, I guess, like JavaScript as well. Okay, so that's down to the question side. Yeah, just to quit about the, you mentioned schemas, right? I've been looking for a way to update the schemas without restarting the server. Have you found a way to do that? Is that possible? Data about restarting the server, hmm. Because you can generate a schema, like a GraphQL schema from, say a JSON definition of your own invention, right? So let's say you want to like say, hey, I want this new schema to send it to the server and then that can regenerate. But so far, I haven't been able to actually do that. Is that something that is a sort of problem that you're aware of? I'm not really aware about that as a way of solving that. That's quite interesting actually. Are they, me? Yeah, it would open up a lot of new use cases. Yeah, it definitely would be one of those things that it could change quite a few ways of how you're using it as well. Yeah, I'm not quite sure about how you would implement that currently. But again, like if that was implemented, it would be fairly useful actually. Yeah, and just like not really a question, but like your last like, what are the advantages of it? I think one of the big ones is that it enforces like at a query level, much better than REST, like the difference between commands and queries or mutations and queries as GraphQL calls them. Because it's like right there in the first word of your query, whereas in REST, it's like, what is a post or a put? Yeah, yeah. You can use a get that mutates for you. It's much clearer in GraphQL. No, yeah, that is definitely actually one of the, I guess the easy points to kind of miss that, yeah, they're very, very strictly clear definition between the two. Whereas like you say in REST, you can kind of do whatever you want if you want to not follow what you should be doing. So yeah, that is another, I think very important thing as well. I know one of the questions I had previously, I've had some about GraphQL has been like versioning in GraphQL. People have asked before like, how do you version in GraphQL? And it's kind of interesting because the way GraphQL works, versioning is also quite different to your traditional REST for APIs. So it's more about, because you get to select the data you've been given from the server, from the GraphQL server. You don't version the same way. You'd normally just add additional fields into the potential schema, which allows you to then select the newer fields. Again, a lot of this will come down to naming. And again, naming is always a trouble for everybody. So it kind of tries to enforce you to name things better as well, where if for example, you're updating your image sources and then you get a new one, you'd probably want to name it as something a bit more relevant to move to that version. But the nice thing about it is it doesn't actually break the current implementations because you're not calling it unless you want it. So it allows you more flexibility in versioning as well because more gradual versioning than like a strict switching versions, which can be a lot of breaking changes. Do we have any questions? Yeah. So if we push these into the client, when something changes on the server side, can it push that down a query? So I know there are ways to work with more like real-time, a real-time kind of web socketing with GraphQL. I've not really looked into that so much currently, but I believe there are ways that you can actually, have more real-time connection using, I think it's web socketing would be the main one for GraphQL. So it is possible, but I've just not really explored that area yet. Yeah, so Facebook has released a specification for that, but not the implementation. Where it occurs in mutations, the implementation is also public. And there are some forks that are available. I think Hasura, H-A-S-U-R-A has its own fork of GraphQL that demonstrates the ability to use subscriptions. So instead of query mutating, there's a third one as available as the first word in the query called subscription. And that actually works. And it does use web sockets. Mm-hmm, yeah. So, yeah, it's as simple as write your query as if it's a query and change the first word. Oh my gosh. What are you gonna use? Yeah, go ahead. There's also the back as well. When it comes to security, are there any things that we shouldn't do? Oh, when it comes to security. So the thing is what's quite interesting about GraphQL is security can be done pretty much any way you want it to be. GraphQL is fairly un-opinionated about security. Some people prefer more cookie-based or you can use the art token as well. But anything you shouldn't do is anything particular that you are considering from that? Like when you say there's anything you shouldn't do is that? Bad practices. Bad practices. I think a lot of it would just be the normal bad practices you would generally have if you're working with rest and you have a kind of transferring data from the front to the back end. I mean, like I said, one of the nice things about GraphQL is that it does allow you to kind of implement your own type of authentication authorization and your own security over the top of it. So it can be just the art tokens or it could be using more second-base and cookies. It kind of comes up to which implementation you prefer. And then again, you're probably not gonna want to send unsecured data between the two necessarily as well. But yeah, it's the same way you would I guess treat any data transfer from the front to the back as well. What's the opinion on using schema registries currently by any different format? Because that would enforce the passable process. I think, again, that can be like a very good way of enforcing that everyone is using the same data circular as well. I think it can really depend on the way they implement it on the client on the server side as well. Because providing that is both gonna be like a JavaScript-based makes it easier if you're using different languages it can also make it more complex. But I think generally that is potentially a good solution that you can use to actually share between the two and then try and enforce better structuring from front and back as well. I think so. What is the underlying protocol that GraphQL use? The underlying protocol. Is it here? Is it here? Yeah. Yes. I mean, you did say GraphQL will be specified but that's what you're talking about. Yeah. Anything else? I have a, oh, that's one again. Never pay for anything. You have server like handles like the query against a large amount of data. Like how does it make sure that the query doesn't time off or it's basically tense forever? Or is that just an implementation? Part of it will go down to implementation of other things that work reasonably, I mean, yeah, because a lot of it will be implanted in the way that you're usually from GraphQL, you're gonna be calling database or another service and then it will probably be the way that these things are kind of communicating or whatever and working. I mean, if you're using GraphQL to talk directly to a database and things that I've worked with before GraphQL is like a type type on which works quite well to allow you to communicate with it and then you can set your own parameters about things as well. Also with GraphQL, doing more, it can be more heavily caching as well to try and speed up subsequent queries to similar sources to try and prevent more round-tripping, to try and speed up the data you're getting as well. How do you implement authentication on the server side? So again, GraphQL is reasonably unopinionated about how you work with authentication and it kind of integrates into pretty much whatever you want to do. So again, using my Jot tokens to work from to back is quite useful. If you're talking about talking to databases or services, then you'll be just storing keys in a similar way you would on the back end usually or using third-party authentication type of processes as well. So the thing is, well, I think one of the reasons why GraphQL has been widely adopted is because it's very unopinionated about how it works with other things as well. So it allows you to kind of build the GraphQL server itself and you can kind of throw in the stuff you want to allow it to do what you want it to do and it does integrate quite nicely with a lot of different processes and it is fairly straightforward about getting them working together. Because in most cases, is it recommended to authenticate at the dissolver level or it's better to have a separate meeting and all that. Hmm, that is another question about, yeah. So again, it will be, again, I think a lot of it just comes down to implementation about what you are trying to achieve from your GraphQL server as well. Obviously, more sensitive or secure data you're gonna wanna try and capture better and have more security processes in front of it as well. Resolver, yeah. I mean, you can do like a resolver and you can kind of like a hit, like an authentication process of in that. That's kind of one way of doing it. I think there's a few different ways you could potentially do, but I'm not sure about what you think of it as the most secure practice for that though, I don't think. Yeah, I think it depends on how granular you want your access control logic to be. So for example, if you want a user to read only rows in the database for this entity that pertains to them, then you go for that at that level. But if you want it just to secure the endpoint or any authentication, then you can just do it at that level. So like you said, whatever level you want. Okay, anything else? I have a question. Well, what is the advance or interesting implementation or pattern that you see before you use GraphQL for? You're like, oh, this is cool. Oh, like with GraphQL. I think one of the things that I've been quite interested in with GraphQL is once you kind of start using it and getting used to it, realizing how quickly you can actually get stuff done and how easily it does integrate with a lot of different things. I've started, I quite like using it with a kind of things like TypeScript and using like a TypeARM on the backend to actually get it to talk to the databases quite well. And then the way TypeARM integrates into GraphQL is very nice. And especially we start using the decorators as well because using TypeScript. So it actually allows you quite a lot of control over the schemas you're creating. It allows you to get them in quite a few different places which is very nice. And it can also help to try and keep consistency through your applications. So GraphQL is one of those things that I think it might seem like quite different to begin with, but once you start actually writing and doing the schemas and actually building the stuff yourself, you realize how quickly you can actually get it done, how the pattern is very easy to follow. And also it's quite nice, the actual GraphQL playground that they provide in built with it as well that allows you to quickly test out your ideas, making sure everything's working as you'd expect it. And then in the playground as well, it allows you to check through the documentation that you technically should be writing as you're doing it. And it all kind of flows really nicely and it works really well together. And I think it provides quite a useful service that I think is very quick and easy to get up and running yourself. And any other questions? Like no, don't keep it in your head if you really have one, don't be shy. This is not the moment to be shy. No? So thanks very much. Okay, thank you. Thank you. Thank you.