Content
@
0 reply
0 recast
0 reaction
Samuel ツ
@samuellhuber.eth
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
7 replies
4 recasts
41 reactions
Nastya
@nastya
GraphQL also has many downsides that usually appear on a large scale. Often, the way to go on a large scale is rest api microservices. But on a very small scale, like when creating a full-stack app that you fully own, GraphQL also adds some unnecessary complexity.
0 reply
0 recast
1 reaction
Rafi
@rafi
We already talked about it on our call the other day so have nothing to add except for: Github have two APIs: one GQL the other REST. You can consider building a lil app on top of them and see how things looks and feel from the consumer perspective.
0 reply
0 recast
0 reaction
Arti Villa
@artivilla.eth
It's easy to start with but hard to master. Issues at scale are hard to debug. So if you're just building a single client vs multi clients, its not really needed. right tool for the right job. If you're using typescript, https://drizzle.com just works, works with any db, AI can write your boiler rest api and I'm sure there are tools to automate. And it kills on performance. I hate cli db management and they have the perfect solution for me. https://orm.drizzle.team/drizzle-studio/overview I went from never touching backend to building full stack with typesafety (zod) in a day. It's also a thin wrapper so it won't stop you from doing things low level. which a reason to not want a lot of abstractions. I literally change prod db code via an editor. Can't get better than that.
1 reply
0 recast
6 reactions
Fucory
@fucory
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
1 reply
0 recast
2 reactions
Alex Loukissas 🍉
@futureartist
I can talk for days for graphql. It's great and it's also not great. Nuances. Best fit for enterprise, for sure.
1 reply
0 recast
3 reactions
Mo
@meb
I’ve used it a lot as a consumer, and I’ve arrived at the conclusion that graphql is great when you want to open access to a bunch of data and enable joins, without worrying about permissions For mutations im still in favour of very deterministic and specialised endpoints
0 reply
0 recast
2 reactions
Ashoat
@ashoat.eth
GraphQL doesn’t have a great answer for syncing state… GraphQL Subscriptions don’t do much more than websockets, and Live Queries are basically just polling
0 reply
0 recast
1 reaction
