Open tianhaoz95 opened 4 years ago
If any choice seems confusing, please leave a comment.
So among API candidates, let's forget about gRPC and go with GraphQL. I researched it a bit, based on my research it doesn't seem like a good idea. It is apparently difficult to debug, and also not commonly used so it will be harder to find people who know how to use it.
For framework it boils down to React & Flutter. Based on my understanding so far, Flutter seems to have a good future. Also, it opens up more possibilities for future projects. Being able to build apps by using a single codebase for different platforms is power.
As for cloud platforms, I will leave that up to you.
So among API candidates, let's forget about gRPC and go with GraphQL. I researched it a bit, based on my research it doesn't seem like a good idea. It is apparently difficult to debug, and also not commonly used so it will be harder to find people who know how to use it.
GraphQL in general looks good to me. The one thing I dislike about it is that from the client's point of view, the result is typeless and there is one extra step needed to convert it to a type.
For example, if I query something like:
{user(id: "test_user") {
name
id
}}
Essentially the result back is the same as a REST which is just a JSON with:
{"user": { "id": "some_id"}}
Also, speed-wise GraphQL being 10x slower doesn't look very ideal.
GraphQL in general looks good to me. The one thing I dislike about it is that from the client's point of view, the result is > typeless and there is one extra step needed to convert it to a type.
Yeah, JSON conversion is very fast though, and because we avoid data redundancy by using GraphQL it is even faster. I don't know much about gRPC, but multiple articles said that it is hard to debug it. That's enough reason for me to avoid any tool unless I have no other options.
I think that makes sense. From the point of onboarding, protobuf and gRPC are known for being unfriendly.
Let's go with graphQL then.
However, I would avoid betting on graphQL will be the goto choice when writing the code, we still want an abstraction layer to make any switching easier.
Just opened #46 to track the process of getting the skeleton up and running.
Also, for record open #47 to track adding the final choices into the doc for future reference.
As for cloud platforms, I will leave that up to you.
Opened #51 to track the cloud vendor infra progress.
https://tianhaoz.com/acumany-re/#/design-docs/tech-stack-study
Description