 Hi. My name is Sandil. I've been open source developer, self-learned programmer for the last two decades. I've built a couple of companies in service space. I'm more known in Ruby community than in Python, but I'm in Python because of new areas of interest, especially natural processing, data and other things. Basically, I'm here to rant about things. Everybody comes and says this is the next cool thing happening, happening, happening, and it makes our life miserable. Okay. So let's start with that. Okay. My time starts. Okay. Okay. So long back, there used to be a simple thing. There was a blogging service where we post a blog. People need to discover it. So they built a small service which will report to a aggregator that new blog has been created. And this was XMLRPC. I don't know. Many people may not have used it, but it's a very simple thing. Simple XML, because XML is standard at that point. And it worked. Okay. And since it was becoming popular, big companies came in, Microsoft, Sun, a lot of people came in, and they said, okay, let's add some more feature to it. Simple thing which works. They added more and more features, made it enough complex, and that is what SOAP is. Okay. Each company has spent millions of dollars building the specification, and only their tools can build a bunch of implementation for it. As an open source developer, each time you see SOAP, I dread it. Because I build companies on it, so if your developers can't do it, you have to do it. Language, encoding, technology, port, unknown parts. Okay. On the blocks, there was another simple API which was usable. It was called RSS. You can get all the feeds. You can have a new seeder. See, whoever wrote a new blog post, you can discover. You can have a small RSS reader application on your desktop, and you can do it. And then came Google. They said, okay, let's get all the feeds. We will get you for you. Let's do with the Google leader, everything. They ruined it for everybody. But in between, there are other standards which came in. Atom, different versions. And now nobody knows. Okay. Earlier, browsers will notify there's RSS feed on your browser head. It's gone, actually. Okay. Then Amazon actually proposed REST APIs. Okay. So, no, this is 2005-2006. So, you have to read the documents. So, since I'm a self-run guy, so you have to read the RFC. There's a RFC. There's an implementation or some talk. Read the spec. Try building it. Does it work? And then you implement in your project. Often, if you're a small company, you can get away with it. Large companies, there's a process. Or if you're clients, convincingly, it's required. Okay. So, REST solved a lot of problems. It created sort of own problem as well. Then they said, okay, no, REST is too many endpoints. I think there's a post which is coming earlier as well. And the problem was, how do you make it better? So, they said, okay, let's also put all the endpoints inside the REST API itself where you need to call. And that was called hypermedia. Okay. Even this was kind of okay. Then again, Google, right? It loves anything which runs on browser. So, they used to offer SOAP APIs. They used to offer REST APIs. They didn't offer anything anymore. Everything is now linked with OpenRT, OID, or this is a different version which came in. So, even if you're using a mobile app, if you don't authenticate with Google API, it will open a browser interface inside the native application where you have to authenticate into Google to get that part done. Okay. Then also, there were other versions. How do you make it standard? How to compress the request? XML was too big. JSON was simpler. They want to compress data even further. Then we had this protobuf, GRPC, and other kinds of shenanigans which came in along with it. Okay. Then we also had other kind of thing which came along with big companies. Okay. So, what application we built which had a lot of experience and they call it monolith. You have a Java application, Python. A lot of things are done together. It's a monolith. Let's not go in that way. Let's make it microservice. Build smaller services, build simple APIs, and that should solve everybody's every problem. And again, companies went and did a lot of this part. But if you remember, there is to be something called database developers, database administrators, right? There will also be CIS admins. Now, they're all DevOps. Because of, let's say, ORMs, the database developers have become somebody else now. I don't know what they are now. Maybe they are ETL developers or they are big data guys. I don't know. And those people who read couple of weeks of online courses, they become data scientists. I have a lot of problem with all of these guys. Okay. You have not built large applications. You don't know what challenges it faces. Okay. So, 2008, I was part of a team which had to implement something. So, at the time, Rest API was kind of okay at that point. And we had to scale it. So, APS scaling has a lot of challenges. Okay. Caching was a big problem. Okay. And now, I think we have two or three talks happening in GraphQL. Even the talk before here, before lunch was on GraphQL. I want to rant there. You are saying, oh, GraphQL solves every problem. Okay. You are saying lazy front-end developers or marketing-driven developers, what problem they are solving for them. Okay. It ruins our life. It ruins our weekends. Right. You want to have a release? How many requests are going to come? I change the phone. You want to have same font size. You want to make 20 requests. 30 requests. Where do I catch what? Earlier, we used to optimize database. Okay. Don't do N plus on queries. GraphQL never solves N plus on queries. Again, GraphQL is a Facebook product. See, every technology company is promoting their technology. Each, let's say, company has their own language. Google has Go, Dart, Twitter is promoting Scala, Microsoft has a whole bunch of languages, the whole .NET, F-sharp, everything. So, that's happening. Again, database also, it's happening at that level. So, a lot of these paradigms are being pushed. If you go for machine learning, Keras, TensorFlow, again, technology specific for that company. Okay. So, GraphQL is very specific to what, do social graph. It's not solving your problem. Okay. If you're a small company, small startup, whatever you understand very well, please implement that. Okay. Scaling challenges will come all the time. Right? There are people who can help you. See, Facebook did not release implementation of how to implement GraphQL DB. They gave us Peckpat. And what we have is a Node.js version called Apollo, which is running on a server and Apollo client. And why do they build it? Because they didn't want to build a native application iOS. They want to have a hyper... React.js was supposed to cross compile into Android plus iOS. Okay. So, they are solving some different problem because of some reasons. So, just don't fall into that trap immediately. If you want to implement a lot of implementations, learn, understand, whatever you understand, only implement that for now. And let big companies spend on GraphQL, other technologies for now. And let's see how that catches up. Thank you.