Going at GraphQL

[smolinari]

Hey @inca,

Have you considered trying to also get Voie to work like Relay does with GraphQL and React? I'd really love to be able to define the data needs right within vue components and have a GraphQL backend. What do you think about that idea?

Scott

[inca]

Didn't look into GraphQL, I think I need to see their draft specs before I can say something specific :D
I guess any integration would work as long as it fits the FSM principle of Voie (it's pretty agnostic to data sources and types).

However, specifying data needs in Vue components is somewhat contrary to what Voie tries to achieve (I've just described my point of view in #5, so please take a look).

[smolinari]

Do have a read about Relay and GraphQL and how they work together (with React). I think you might just change your mind. 😉

https://facebook.github.io/relay/
http://graphql.org/

All these videos are pretty good at explaining too.
https://www.youtube.com/watch?v=9sc8Pyc51uU
https://facebook.github.io/relay/docs/videos.html#content

Scott

[inca]

Yep, had some good reading (thanks btw) :) Still pretty convinced that Relay has nothing to do with states and routing (the domain of Voie). Or did I miss something? :D

I'd like to see an example of Vue + GraphQL integration though, to figure how Voie would fit in this architecture.

[smolinari]

Thanks for taking the time to learn GraphQL and Relay's concepts.

Yeah, you are right. Relay, and indirectly GraphQL, don't deal with routing at all. They even mention renaming the Routes modules too, because of that. For routing in the React world, they have react-router.

Relay deals purely with state, which, from a separation of concerns perspective, might not be too bad of an idea either. (Not knocking your great work with Voie at all with that comment either. 😄)

As I mentioned earlier, being able to define the data needed in the components directly is a pretty neat and very convenient idea. I believe one of the mantras of Relay is also, before any component is rendered, it will have the necessary data/ state it needs. I think that goes along the lines of one of Voie's main goals too, doesn't it? It certainly goes with Vue's. I've read often where Evan tells people to make sure their data is defined up front and to avoid using $set, if possible.

GraphQL itself is just another (and I think quite smart) specification for communication with the backend server. My personal favorite advantage of GraphQL is the ability to have, basically, a versionless API and not needing different URLs/ endpoints for different data needs. In other words, it is a great way to decouple front and backends and it goes totally with the goal of my project too, Skooppa.

I'll be honest, I am no expert on all this or with programming in JS in general (I am learning). I am just a guy looking for something better than React, because I don't believe working in JS all the time (JSX 🚫) is really a good answer to creating well designed websites. I like the fact that Vue still has markup as markup and can still be reactive. Vue can be handled more like a templating system, which is a bare necessity for Skooppa too.

At any rate. I hope you might consider the possible challenge of a GraphQL/ Relay-like/ Vue solution as another project, maybe even involving your concept of state as the key to routing too, which I think is also smart. It certainly would be different. I think such a project would get a lot of attention, because GraphQL is also gaining in popularity fast. 😄

Scott

[inca]

Thanks for detailed follow-up! I agree, that's a good idea for another project. I'll ponder on it whenever I've got some spare time.

Closing ;)