Isomorphic universal models/collections about apollo HOT 4 CLOSED

Semantic nitpick: "isomorphic JavaScript" refers to using similar patterns in multiple environments, like client, server, iOS, Android; think React Native's "Learn Once, Write Anywhere" philosophy.
To refer to actually using the same code in multiple environments, "Universal JavaScript" is the right term.

I have nothing actually useful to add to this conversation, sorry 😄

from apollo.

I get your point. But this is the idea of GraphQL.

• Define a set of schemas on the server.
• The let the client to access them however they want it.

So, this decouple the server and client is a proper interface. Which let's both parties to great things.

That's how GraphQL works today. Now with Apollo, we are trying to make it reactive and add some cool features Meteor had, like Reactiveness and better optimistic updates.

I think it's so early to tell more about these, but we'll get most of cool things we love in Meteor data stacks with the power of GraphQL.

from apollo.

Having simple isomorphic reusable models on client and server with functionality like create, save, update, validate, very smartly available on both

You can definitely do this if you want to, but I think the current trend is to move away from the concept of "models" and towards plain data - so instead of:

widget = Widgets.get(id);
widget.set("x", y);
widget.save();

It's more like:

Widgets.setX(id, y);

This eliminates the extra state in the system from having a temporary model around. Especially in a world where there are lots of different clients looking at the same data using models and save can result in people overwriting each other's changes pretty frequently.

from apollo.

Widgets.setX(id, y);

@stubailo sound for most cases even better than my approach ;) Just not having to manually send mutations towards the graph api sound awesome!

However I see two strategies with forms, maybe making both strategies necessary:

1. On field change, validate and if valid directly trigger the setter (direct form binding possible?)
2. On field change, validate, render some previews (direct form binding) e.g. an ad-editor like Google Adwords or Facebook Ads. As soon as finally done, update dirty values on "save"-Button. (probably the much rarer scenario)

Will there be reusable "models"? On heavily data-driven SPAs I think models may still are preferable? I think defining the database-source may only happen server-sided but making validations on both, client and server, would be awesome. Maybe there is a way to let both coexist while having graphql as a data strategy in the background?

from apollo.