the one major problem I see with graphql is its complexity. yah you can use libraries like apollo to abstract away those but tooling, rate limiting, role-based routing with graphql is still not quite convincing. in a microservice architecture, graphql might become a bottleneck in performance-wise. only apollo (js) supports federation, and it's not in graphql spec. so authors of graphql libs in other languages not much interested to implement it.
There's so many protocols with different wire format like protobuf, flatbuf, capnproto, avro, json, xml... so many language... so many infra tools like istio, nginx, etc...
graphql isn't flexible enough, and unfortunately, there's no other better solution yet. openapi can't solve all the problems with REST. but if someday anything new comes, switching from REST might be easier than graphql
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.
the one major problem I see with graphql is its complexity. yah you can use libraries like apollo to abstract away those but tooling, rate limiting, role-based routing with graphql is still not quite convincing. in a microservice architecture, graphql might become a bottleneck in performance-wise. only apollo (js) supports federation, and it's not in graphql spec. so authors of graphql libs in other languages not much interested to implement it.
There's so many protocols with different wire format like protobuf, flatbuf, capnproto, avro, json, xml... so many language... so many infra tools like istio, nginx, etc...
graphql isn't flexible enough, and unfortunately, there's no other better solution yet. openapi can't solve all the problems with REST. but if someday anything new comes, switching from REST might be easier than graphql