Relay/GraphQL

[hughryan]

I like your stack, I'm currently putting together something similar.

What are your thoughts on using Relay/GraphQL?

Here's what would change: Database Schema: GraphQL Database Hooks: GraphQL Client Side Cache: Relay Optimistic UI: Relay Routing: react-router + react-router-relay

[mattkrick]

I'm a fan of graphql, I'm actually playing around with it for the authentication as well as for the socket events on another branch.

• I currently think it can replace the controllers, although the resolve functions would look a little ugly. Plus, since signing JWTs requires a secret, I need to look into converting the schema to be client friendly if I send it to the client, too.
• I think it'd let me get rid of thinky as an ORM, I would just have to create tables and indexes in another function.
• it'll let me get rid of JOI on the server. The big question is if I can use it to get rid of JOI on the client, since it's a behemoth of a package and I'd love to get it out of the stack if possible.
• I'm interested in what their event driven subs are gonna look like, but I think I'll stick with my web sockets.

Regarding Relay, I like the idea, but as it currently stands, I'm not a fan. It was built before redux, so what can you expect. I need something that plugs into my redux store, offers an offline-first experience, and gives me some flexibility on when it syncs with the server, eg when I drag a note across lanes, I don't want to talk to the server until the note is dropped. There's a project called adrenaline that is a step in the right direction. We'll see how this space evolves over the coming months.

On Tue, Jan 12, 2016, 3:34 PM hughryan notifications@github.com wrote:

I like your stack, I'm currently putting together something similar.

What are your thoughts on using Relay/GraphQL?

Here's what would change: Database Schema: GraphQL https://github.com/facebook/graphql Database Hooks: GraphQL https://github.com/facebook/graphql Client Side Cache: Relay https://github.com/facebook/relay Optimistic UI: Relay https://github.com/facebook/relay Routing: react-router https://github.com/rackt/react-router + react-router-relay https://github.com/relay-tools/react-router-relay

— Reply to this email directly or view it on GitHub https://github.com/mattkrick/meatier/issues/43.

[mattkrick]

graphQL implemented! Outstanding issues:

• using graphQL with socketized changefeeds-- since facebook never uses websockets I doubt their subscription function will be able to handle this, but it's worth keeping an eye on
• still need a legit client-side cachce, opening a new issue exclusively for that

[abastardi]

What do you think of the graphQL event-based approach to subscriptions as opposed to the (RethinkDB) live query approach? Does the flexibility of RethinkDB changefeeds address many of their live query concerns (particularly once RethinkDB adds support for changefeeds on joins)?

[mattkrick]

maybe I'm wrong, but unless you've got a facebook-sized problem, you don't need event-based updates. Last I checked stackexchange could manage over 130,000 concurrent socket connections without a problem (granted their approach to sockets is to enhance the UX, it's not essential, they're not sending heartbeats or new documents). We'll see what it looks like when graphQL supports subscriptions, I've seen it's already present in parts of the SC. My fear is that everyone will jump on the facebook bandwagon & ditch the real-time web just because facebook doesn't use it.

[AhmadEl-Banna]

@mattkrick I think you should see this https://github.com/kennetpostigo/react-reach

[mattkrick]

@AhmadEl-Banna interesting, but not a lot of thought put into it. It's still tightly coupled to react, it doesn't normalize the data inside the store, it won't eliminate unnecessary server fetches, it doesn't allow for pagination, etc. I'll have something by May :smile:

[AhmadEl-Banna]

@kennetpostigo

[AhmadEl-Banna]

@mattkrick what about https://github.com/gyzerok/adrenaline

[mattkrick]

again, tight coupling & no normalization, although it does (or will) offer query aggregation. See https://github.com/mattkrick/cashay/issues/1

[kennetpostigo]

Hi, @mattkrick I began working on react-reach a few months back and haven't had a decent amount of time to keep working on it alot. react-reach is meant to only handle server request but I'm also working on implementing a few features for redux. It is in no way coupled to reduxor react. react-reach currently allows you to use any feature available with GraphQL (queries, fragments, mutations, compose queries). You can use it with vanilla js or any framework or library for that matter.

As for thought being put into it, I've done my best with the little time I've had. If you have any issues with the way my library tries to achieve it's goals feel free to contribute to make it better as it is an OpenSource project. If you need to normalize your data take a look at normalizr.

[mattkrick]

@kennetpostigo sorry for coming off as rude wrt your repo, little time = less elegant with words :confused:. Client caches are really hard & I totally agree with you that relay probably isn't the answer things unless the business case is very similar to facebooks.

[AhmadEl-Banna]

@mattkrick @kennetpostigo I think you guys have the same goals ,and you can use each other Ideas.