peggyrayzis

Congrats on the launch! I recently tried InsForge for a personal project a few weeks ago and thought the getting started experience was really smooth.

Which one do you continue to reach for the most? I was surprised to see Gemini so low on your list even w/ the long context window.

Hi from the Apollo team! We're not abandoning open-source software. Excluding our Federation 2 libraries, nearly all of the 100+ public repositories in the Apollo GitHub organization are MIT-licensed. Our most popular projects, including Apollo Client (Web/iOS/Android), Apollo Server, apollo-rs, and Rover, remain MIT-licensed.

Federation 2, the component of our platform that is licensed under ELv2, is most interesting to large enterprises. Apollo has built a successful business that helps developers at large enterprises adopt a unified graph at scale. These enterprise subscriptions fund the development of important open-source projects like Apollo Client and Apollo Server that benefit the entire graph ecosystem.

Hi from the Apollo team! We hired a mobile engineer who is starting within a few weeks. Keep your eyes out for lots of exciting improvements to Apollo iOS soon!

The normalized cache is the one of the main value props of Apollo Client. It optimizes reads, automatically updates queries without a refetch for some mutations, supports optimistic updates, and can also return partial data for large queries. If you don't need a cache, then you can use fetch, graphql-request, or even Apollo Link to fire off a simple GraphQL request. You also don't have to use our cache implementation (apollo-cache-inmemory) with Apollo Client. There are other implementations that make different tradeoffs.

For what it's worth, we are rearchitecting parts of the cache to support invalidation and garbage collection for Apollo Client 3.0. The only reason why we don't have it yet is because it's a tough problem to solve - one mutation could invalidate an infinite amount of queries. We're committed to solving this soon though because we know the community really wants it.

Thanks for the thoughtful response, this is all helpful feedback that I will share with the team.

It's been on my backlog for a while to rewrite the Apollo Client intro section to give developers the high level overview you're looking for. Now that Apollo Federation is out, I have some time on my calendar to do exactly that. :) Would you be open to reviewing the new section once it's done? If you're interested, send me an email at peggy [at] apollographql.com.

If it's still confusing after that, then we can chalk it up to a problem with the library. I suspect that it's a docs problem since the intro hasn't been overhauled since I joined the company almost 2 years ago.

Really appreciate your feedback. Let me pass it along to the team. I agree that we could do a better job of documenting when queries are reinvoked depending on what options and variables are set.

For skip, the behavior with refetchQueries sounds intentional since the refetching happens within the Mutation component. I don't think we pass information about whether the skip prop is set on the Query component to the refetchQueries array (https://github.com/apollographql/react-apollo/blob/master/sr...).

Hi from Apollo! My team (Developer Experience) is responsible for making sure you can find what you need in the docs. What improvements would you like to see?

Hi from Apollo! We appreciate your honest feedback. Part of my team (Developer Experience) is responsible for our documentation. What features are inadequately documented? We'd like to fix that for you if we can.

Hi from the Apollo team! This is good feedback. I agree that the GraphQL community (including us) could do a better job at educating developers about best practices for building GraphQL APIs. There's a lot that goes into standing up a GraphQL server that isn't explained on the official docs, so hopefully we can work with the GraphQL Foundation to improve that in the future.

I don't think backend services with mature REST APIs are the problem; rather, it's fetching and aggregating their data on the frontend that's cumbersome. With the complexity of modern apps, developers have to write a considerable amount of data fetching code to build out new features. They have to fetch data from multiple REST APIs, filter down that data, aggregate it, cache it, and account for loading and error states. Writing all of this state management code by hand slows developers down and leads to bugs.

Apollo aims to solve this problem by unifying around one way to query all of your app's local and remote data. This reduces state management code considerably since Apollo takes care of fetching, tracking loading and error states, and caching your data. For simple primitive values that aren't shared among multiple components, I totally agree that Apollo is overkill and would recommend seeing how far you can get with React state instead. For local data that's shared among many components, like device API results or global boolean flags that you would put in a Redux store, Apollo shines because it allows you to specify all of your data requirements declaratively in one query.

While you do have to integrate a new data graph layer into your stack to take advantage of all the state management benefits, you don't have to migrate your REST APIs. Apollo Server has a data source plugin [1] that simplifies hooking a GraphQL server up to existing REST APIs, including a cache that eliminates the need for DataLoader in most cases.

I hope this helped to clear up any misconceptions. Happy to answer any other questions you might have!

[1] https://www.apollographql.com/docs/apollo-server/features/da...