Make cache management a separate npm module?

[bnoguchi]

I'm thinking about using lokka with redux. In that case, I'd like redux to hold the cache in a typical app global state tree. In this case, lokka's management of the cache state is redundant with what someone would build with redux. It would be nice to move the caching that lokka does into a separate npm module. That way, one could swap in different cache management plugins, depending on how they want to manage the cache, where a plugin handles cache management via writing event listeners on lokka graphql query lifecycle events. Thoughts?

[smolinari]

👍 for more modularization.

Scott

[arunoda]

I think we do it like it even for now.
The core API does not cache anything.
And there's a cache API which uses the core API.

Cache API is still very basic, I'll think about it's better to use a different project or not.

[smolinari]

I also believe a Lokka/Redux combination would be really nice duo compared to Relay, especially because they aren't especially built for React. Yuckola!

What I do like with the Relay/React combination is the ability to add the GraphQL queries in React components. If you could team up say a view system like Vue with Lokka and Redux, and add that kind of mix of data, behavior and design in Vue components. Wow!

Scott

[D1plo1d]

I am actively working on a Lokka/Redux/React library and share @smolinari and @bnoguchi's concerns that the way Lokka is doing caching at present isn't really compatible with the Redux reducer pattern.

It would be better IMHO for Lokka to tighten it's scope and focus on it's most reusable aspects, moving caching to a separate package.

[smolinari]

Hey @D1plo1d - would you be interested at all in doing a Lokka/Redux/Vue library too by chance?

Scott

[D1plo1d]

@smolinari I don't have any time to put into a Vue library. It might be possible to reuse the redux/graphQL bindings if someone else wanted to build a Vue binding.

On that note, I've revised my plan regarding Lokka (with the experience of building a Lokka-based prototype now in hindsight). Now, I'm looking at building on a Lokka-alternative with lazy fragment evaluation and a non-regex-based parser now and also unit tests and also AST parsing... so... I'm also going to need to build that (I'm looking at repurposing some code from https://github.com/ooflorent/graphql-parser). Lokka transports are a great idea IMO though so I'm going to keep compatibility with those.

TL;DR: reinventing all the wheels, it's going to be a while. Vue integration would be cool but I'm spread too thin already.

[smolinari]

Ok. Thanks for the reply @D1plo1d Rob.

Scott

[stubailo]

This is a caching Redux GraphQL client: https://github.com/apollostack/apollo-client

It stores the data in Redux in a normalized form, and you can even integrate it with your existing Redux store! http://docs.apollostack.com/apollo-client/redux.html