Maybe controversial? It's not GraphQL vs REST. Both are part of the enterprise API stack, together with Open API, Async API and others. It's enterprise API stack vs people not caring at all and just vibing API sprawl from day one. Happy Friday 😅
Jens Neuse | Founder @ WunderGraph
@TheWorstFounder
Founder of @wundergraphcom - Building Cosmo to manage federated GraphQL APIs - wundergraph.com - Meet: wundergraph.com/meet/jens
- Companies who built a GraphQL layer have already solved this. They can already query all their systems in an efficient way. No over fetching, because that's natively solved by a query layer. Authentication and Authorization is solved. For many, caching is solved as well. JustOne interesting trend: I’m seeing *so many* VC-funded, internally built infrastructure and bootstrapped solutions around “building a context layer for engineering teams.” Aka trying to solve the problem of “if only eg Claude Code had the context from all your other systems”
- Who else is excited for GraphQL conf next week? The weather seems nice! Lot's to talk about. The WunderGraph team has been cooking like crazy over the last couple of months! #1 We're going to have a talk by David Stutt about Fission, our new algorithm that revolutionises how
- while true; do build_model_agnostic_solution gain_traction model_provider_invests_or_acquires solution_becomes_model_specific market_demands_neutrality_again done
- After some digging I figured out something about JSON parsers that claim multiple GB/s parsing speed by using SIMD. They don't really parse the JSON, they skip through 16 or more bytes per operation. The moment you try to build a JSON ast for each node, the speed drops
