devFC

Am I wrong for thinking GraphQL is how builds APIs today?

GraphQL as core (anyone can select just the data they need)
Then some default queries offered via one call as REST endpoints (just a wrapper over the GraphQL)

and then for typesafety and production use on the client side combine GraphQL with effect to get end to end typesafety and return type validation in something like

What am I missing / where does this go wrong? trying to open my mind on GraphQL

Am I wrong for thinking GraphQL is how builds APIs today?

GraphQL as core (anyone can select just the data they need)
Then some default queries offered via one call as REST endpoints (just a wrapper over the GraphQL)

and then for typesafety and production use on the client side combine GraphQL with effect to get end to end typesafety and return type validation in something like

What am I missing / where does this go wrong? trying to open my mind on GraphQL

https://gist.github.com/tim-smart/e10e4cbaeff35242d8352adead30bef9

Farcaster Product Studio @ https://dTech.vision 💜 in love with tech 🤓decentralization, fitness and oldschool rap 😎

You aren’t wrong you just likely don’t need graphql in the same way you likely don’t need bazel for your build system or likely don’t need kubernetes for your web app

Makes sense. One likely scales into it? Though I am thinking more from an API provider PoV vs internal backend consumption

Same thing applies most apis don’t need graphql but the decision is easier for an api provider because
1. You care less about up front cost and care more about end developer dx 
2. It often is obvious if you want graphql because in the cases you do want it it will likely be easier to design a graphql api than an alternative