Eshoponcontainers: Pros and Cons of using GraphQL for this project.

[YuriyTigiev]

Hello,

What are the Pros and Cons of using GraphQL for this project?
In which cases prefer to use GraphQL instead of Microservices?
Why Microsoft doesn't have a native library for support GraphQL?

[mvelosop]

Hi @YuriyTigiev, I'm not sure that I understand what your doubt is.

Why do you compare microservices (an architectural style) with GraphQL (a query language)?

[YuriyTigiev]

Hi @YuriyTigiev, I'm not sure that I understand what your doubt is.

Why do you compare microservices (an architectural style) with GraphQL (a query language)?

Because instead of RESTful API (a few API) I can use GraphQL (One End Point). Am I wrong?
https://www.howtographql.com/basics/1-graphql-is-the-better-rest/#:~:text=With%20REST%2C%20you%20have%20to,includes%20the%20concrete%20data%20requirements.

[mvelosop]

Well...

Microservices is much more than a bunch of APIs, it's "small" services that can be developed, deployed and scaled independently of others, and that usually use asynchronous messaging (queues).

From your mention of REST I guess the comparison could be between an API Gateway/web aggregator and GraphQL.

I haven't really worked with GraphQL although I've been in a couple of workshops.

I, personally, find GraphQL requires too much setup effort for the kind of applications I've been involved with but, it looks like a good solution for the kind of problems FB has to tackle (that's why they implemented it after all).

So, as usual, there're are no silver bullets and you have to balance out if the additional complexity required adds value to your business. Whether any solution is good or not is always context-dependent.

I, personally again, prefer starting with a customized solution that fits the client application needs using a Backends for Frontends (BFF) approach, rather that going with a more general solution like GraphQL, because of the additional complexity.

The basic idea with BFF is that you return whatever the client app needs in a single call, and you can do that with REST.

AFAIK, one the stated GraphQL's strong points is it's ability to aggregate data from several sources, but that's actually one of the practices not recommended in a microservices architecture, because of reliability issues.

But as mentioned it all depends on the kind of problem you're trying to solve.

Hope this helps.

[YuriyTigiev]

I'm trying to find an optimal solution not only from a technical point of view. The development, testing, support, and hosting should no be expensive. I thought the GrahpQL could decrease investment capital.

[mvelosop]

Usually simpler is better, because you'll have to struggle less, and effort shows in the bottom line too 😉.

So I suggest you begin as simple a possible, but with an eye in security, and add technology and complexity when you start feeling the pain somehow.

Hope this helps.

[sughosneo]

Hello @YuriyTigiev , I am closing this issue as the original question has already been addressed. Please feel free to reopen it if you have any further questions.

CC : @mvelosop

Thank you.