I can see the praise of Graphql especially when coming from frontend developers. I do enjoy working with them at the client side level. But at the backend leve

I can see the praise of Graphql especially when coming from frontend developers. I do enjoy working with them at the client side level. But at the backend level, I find Graphql bit too verbose. There is a lot of code being repeated (or referenced) and it makes your code bloated with having to manage several different places. For example if you have a customers table, you have to declare the fields you have in the table for the schema, then you declare them all again on the queries/mutations/resolvers. Which are again repeated at the client side. So if you ever alter something in your table, you have to touch around 4-5 files for each change. You then multiply that by the number of tables you have and you get the idea. It is essentially worse if your database schema have quite a bit of nested JSON data. Sure there are pros and cons to this but atleast with me, so far, the cons seem to outweigh the pros. I miss being able to whip up an API endpoint on the fly. Graphql backend coding reminds me of the days of SOAP with the WSDL and all, I recall it made me hate coding. I was thrilled to see REST get popularized and get away from SOAP completely. Now it seems we are back in a quasi-SOAP world again with Graphql. I'm sure it's a bit more improved now but once being burned I just don't feel comfortable going back to anything that resembles it. I generally like simple and quick solutions that addresses problems. But Graphql seems like it's in the other spectrum of it. On the bright side, Graphql is somewhat fun. :)