wmdmark

13 ms·

1.
by wmdmark 9y ago
Apollo is mentioned 4 times in the article. That's beside the point though, even using GraphQL with plain old HTTP requests would have removed a lot of the need for Redux in our case.
2.
by wmdmark 9y ago
This is true. Our team is a little unique maybe in that we can all modify the GraphQL Schemas when we need to (we're using Node.js + Join Monster so it's all JavaScript). I would say though that with our REST API, updating was a l
3.
by wmdmark 9y ago
Did you actually read the article? I explicitly mention that Apollo uses Redux as a cache under the hood (although that's not required).
4.
by wmdmark 9y ago
So this apple/oranges thing is true and addressed in the article. Have you used GraphQL/Apollo? It can do a lot of the things you're wanting: - You can combine multiple data sources into a central datastore using GraphQL (R
5.
by wmdmark 9y ago
The local store in Apollo (at least the current version) is actually Redux (and a good use case for it IMO). In our experience it hasn't been to hard to manage and it's nice that you can still use the Redux DevTools to inspect t
6.
by wmdmark 9y ago
Fair points. The thing that tipped in favor of GraphQL for the back-end was that it puts the client in charge of the data structure. I suppose you could hack something like that with REST but it would be difficult. Our application is by no
7.
by wmdmark 9y ago
That's true however at that point our API is not longer "RESTfull" and become very ad hoc. The cool thing we found with GraphQL is that the client can control the shape of the data it needs without any server side changes (as
8.
Tutorial and Demo of data binding with Backbone.js + Rivets.js(wmdmark.github.io)
5 points by wmdmark 13y ago|0 comments
9.
5 Reasons I Don't Ship(medium.com)
1 points by wmdmark 13y ago|0 comments
10.
by wmdmark 14y ago
Good stuff.