It's worth looking into the N+1 problem with GraphQL. You need to look at how many depths you want to support when it comes to nested queries. itnext.io/what-is-the-n-1-problem-...
You also need to ask yourself do I need this negotiation? For me, GraphQL is there for a specific set of problems, to co-exist with REST endpoints. It makes sense to look into GraphQL when you need a layer on top of a lot of different types of data sources. When it comes to performance it really depends on what you query for, it lies in the query itself when you compare it to REST. The biggest thing GraphQL gives you is stopping over fetching, a lot smaller data payloads are coming back compared to REST (I mean you could be in control of the REST endpoint but sometimes you aren't)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It's worth looking into the N+1 problem with GraphQL. You need to look at how many depths you want to support when it comes to nested queries. itnext.io/what-is-the-n-1-problem-...
You also need to ask yourself do I need this negotiation? For me, GraphQL is there for a specific set of problems, to co-exist with REST endpoints. It makes sense to look into GraphQL when you need a layer on top of a lot of different types of data sources. When it comes to performance it really depends on what you query for, it lies in the query itself when you compare it to REST. The biggest thing GraphQL gives you is stopping over fetching, a lot smaller data payloads are coming back compared to REST (I mean you could be in control of the REST endpoint but sometimes you aren't)