I've spent the last couple of years building a graphql api around my employer's platform. When it comes to graphql mutations vs. sql writes, the things that ca

I've spent the last couple of years building a graphql api around my employer's platform. When it comes to graphql mutations vs. sql writes, the things that can go wrong are ugly and hard to avoid on both. But for read queries the graphql api is a lot safer. I can think of a few read queries I could make that could make the db server fall over, but those are bugs I'm working on fixing. But with sql queries it's much easier to crush the server, and I've done it way too often just by accident. I would much rather allow Dave in accounting have access to graphql over sql read statements. There's just a lot less damage that he can do. And the fact is that Dave in accounting has been using the graphql api via GraphiQL, getting great results, and taking a load off of the developers. It's much easier for him to learn than sql. The whole account management staff is gradually climbing on board. They can do things in minutes that would previously have been projects that crossed departments and took weeks. Some clients are using it directly too. We couldn't have seriously considered opening up sql queries like that, even to replica databases.