For two weeks, I have been hard at work learning FastAPI and GraphQL. And I have some opinions on them.
Firstly, I like FastAPI. It seems like Python is finally catching up to NodeJS a bit with implementing async operations in this library. I think I have a soft spot for these lightweight libraries: FastAPI, Flask, ExpressJS. They aren't used in large sites. Corporations prefer big battle-tested frameworks more. But if I want to spin up a quick web server, these frameworks are my jam. I wrote my home server hub page using ExpressJS with a custom web templating engine (I didn't know that practice until later, go figure).
However, I don't like FastAPI's documentation. They focus too much on OpenAPI/Swagger and go in-depth on what each component does. I think that would be more helpful for newcomers to the web scene. But I've been for years, and I think OpenAPI should be the focus far later in the documentation. I rather just make something by using my previous knowledge about web development and applying them to FastAPI, resulting in this project. For this, I held ExpressJS documentation in higher regard. Maybe because it's quicker to get into it without OpenAPI part. But automatic doc is nice, don't get me wrong.
Another thing I picked up while learning FastAPI is that it's much easier understanding Dependency Injection. Much like NestJS except less verbose, they have a way to make DI enjoyable. Of course, I have to implement my own IoC container, unlike NestJS. So I recommend anyone wanting to learn DI, to start from FastAPI or NestJS. Starting from .NET/C# and you see your blood on a wall from banging your head against it a lot.
While learning FastAPI, I picked up GraphQL as well. At first, I didn't quite understand the reason for its existence. By learning about Facebook being the creator of GraphQL, and many videos later, I can see their POV. Nowadays, for one page, we need to fetch a lot of data, so a lot of API calls, which increase latency and loads on the backend server. Of all that APIs, some can get too much data (Over-fetching), some not enough (Under-fetching). There are also versioning, changing schemas. What if there's a way to call just once, and have it fetch everything you need, and nothing else? And also strongly typed schema. So, GraphQL was born.
In the CQRS design pattern (Controller → Service → Repository → Database), GraphQL would sit in the Controller. GraphQL schema consists of { query, mutation }. In each, there are resolvers, or functions that perform specific actions. Think of it like a route in a controller. For query, it's getting data. For mutation, it's changing them. At least that's the general concept. Resolvers could do pretty much anything like a normal function, as long as you return a type.
Here are two videos that I found helpful explaining GraphQL.