3 ms·
Because those conventions are rarely ever followed. That freedom to do wrong is not a perk for most organizations, and having an opinionated and consistent data
by diveanon 6y ago
Because those conventions are rarely ever followed. That freedom to do wrong is not a perk for most organizations, and having an opinionated and consistent data layer provides a lot of value to large teams.
That coupled with GQL automation and type generation has literally taken months off of the development cycle for the last two products I've built. That has a real $ value that has led to actual success for those products. Not to mention that these API's are extremely flexible for the end user in a way that comparable REST api's could only dream.
- jensneuse 6y agoI really like your answer. I think that's a very good argument if you want to convince someone to start adopting GraphQL. Do you have anything beyond that?
- diveanon 6y agoWhat would you like to know? We have a pretty robust unified graphql api that handles millions of requests per second. Its has recently replaced siloed REST api's and now provides a common interface and RBAC for all of our data, which is housed in 5 different DB engines. Previously most of the data was in MongoDB, so implementing GQL allowed up to regression test the api surface while migrating the underlying data. Remote schemas and persistent queries were pretty integral to that effort.