 Hi everyone, a very good morning, good evening and good afternoon based on your time locations. I'm Anishwini Das and I work as a software engineer at Red Hat and I will be walking you through some use cases of REST, GRPC and GraphQL. So the reason why I chose this topic is ever since the evolution of frameworks, there has been a lot of content on the internet when REST came to existence and when GraphQL came into existence, there were posts respectively like REST in PSope, REST is the new soap when REST became overly popular and there were blog posts like REST APIs, REST in PSAPIs, LongDrip, GraphQL and so on. I believe that every API is its own pros and cons and there is no right API style for everything so that is why I chose this topic and as developers I feel we have a responsibility to choose whatever suits our purpose best and then make a well informed decision based on that. So there is no right API style for everything as mentioned earlier. So before developing an API you have to consider the following constraints that is business, technical and socio-technical and then lay the properties of the system like whether you need scalability and so on. Coming to business constraints, there may be stuff like if your system can consume flat files then go ahead with GRPC and there may be technical constraints that involve distributed system complexity problems and there may be social technical constraints as well that involves stuff like whether you have the particular manpower or the expert is to develop that particular system or not. So in order to clarify this a bit I have a quote from Phil Sturgeon that is if an API is mostly actions maybe it should be RPC and if an API is mostly create, read, update and delete and manipulate its related data then it must be REST. So this is one of the quotes that he wrote in one of his articles on Smashing Magazine. He's a content creator feel free to check out his content. So coming to the advantages, disadvantages and use cases of REST that is REST has standard method names, arguments and status quotes just because it's been there for a long time that's why it's easy to maintain because you can find a lot of resources on the internet to develop that particular API style and it utilizes HTTP features. Coming to disadvantages there are big payloads and it's kind of taken care of in case of JSON APIs by means of field grouping and compound documents and it may involve multiple round trips and it's considered best for APIs that expose create, read, update, delete like operations. Coming to GRPC or remote procedure calls that came into existence somewhere around 2015 that is it's easy to maintain, easy to understand and not maintain, maintain is for REST and there may be light weight payloads as well and the performance is really high. Coming to disadvantages, the discovery is difficult and there is limited standardization because it's very recent and it may lead to function explosion and it's considered best for APIs exposing several actions. Coming to GraphQL, it saves multiple round trips and it has smaller payload size but coming to disadvantages it has added complexity, difficult performance optimization and it's too complicated for simple APIs so it's considered best when you need querying flexibility. So just summarizing all of this that is when you have application web forms that involve simple create, read, update and delete go ahead with REST and if you have composite web forms or microservices that involve schema stitching using multiple APIs and the APIs are data source agnostic go ahead with GraphQL and if you have to develop a native mobile back and for frontend which involves single client and the API static and well documented mostly single clients with real-time interaction go ahead with GRPC. So if you want to know more then go ahead and check out this talk by Rob Crowley on GraphQL, GRPC or REST in one of the NBC conferences I think there are two talks you can search it up on YouTube and if you are more inclined towards the text based information then go ahead and read these two articles. So yes that's all for me feel free to reach out to me in case you have more doubts and if you want to strike a conversation about this and what API and let me know in the comment section in the chat section what API style have you been using most recently so I'd love to know that yes thank you thanks a lot for lending your years and hope you have a great day thank you