If you have one sever with one end point, and never use other services, graphql doesn’t make sense. Don’t use it. If you work with a bunch of Micro services, a

If you have one sever with one end point, and never use other services, graphql doesn’t make sense. Don’t use it. If you work with a bunch of Micro services, and you’re only a backend developer, you likely don’t understand the problem graphql is solving. The alternatives are almost always way worse. > No clear path for Api versioning you'll end up with MyQueryV1.01 MyQueryV1.02 MyQueryV1.03 You’re not supposed to version it. That’s what the @deprecation is for. > It is actually a pain to use, depending on the backend you are using you'll have to manage Do some front end work, or use your companies API as a client. Something where you have to talk to several services and try to stitch together some sort of combined data with all the latency and unreliability of http over a cell phone network. Then pontificate about how the boundaries between the services are wrong, but never change anything - or better yet change a bunch of boundaries then change the UI to cross different boundaries - then complain about how the UI should always have to exactly match your services because the world should revolve around how you’ve decided to see the problem. Yikes, where did that come from. That wasn’t directed at you. Don’t use graphql. When you figure out what it’s for, it’ll be easier to learn.