It's the simple things that you can use far more broadly over the longer term in more scenarios. Run async function, cache results to a key value store. I think these days reactive vars are a little overrated. And for local state management it's pretty weak. I'm over it tbh.Īpollo's config is a rabbit hole that at the end of the day doesn't matter very much.
And for some reason I'm supposed to care about their cloud hosted registry? They're acting like now you can't build an Apollo server without paying for graph diffs. Yoga, and Mesh specifically.Īpollo Federation turned into super graph (or did it?) I'm not sure what the router is, and wtf is GraphOS? None of it is a framework so I don't know how any of this new stuff translates into actually building things. Since this query language for APIs was open sourced in 2015 by a small company named Facebook (which has used it for its mobile apps since 2012), a growing community has been supporting and developing it. You can use Apollo Server as: The GraphQL server for a subgraph in a federated supergraph A stand-alone GraphQL server An add-on to your application's existing Node.js middleware (such as Express, AWS Lambda, or Fastify) Apollo. And these days I'd still probably go for tools from The Guild. GraphQL is an API syntax that defines how to fetch data from one or many databases. It's the best way to build a production-ready, self-documenting GraphQL API that can use data from any source. I think most of the benefits of Apollo are in Apollo server. I don't mind Apollo Clients size because it's a net positive. React Query + Vercels graphql-request library.
0 kommentar(er)
