I've just noticed how similar GraphQL and NestedTypes are...

[far-blue]

I was reading the details of graphQL this morning at it occurred to me how similar the concepts are to NestedTypes. graphQL basically wants to know about types and relationships - just like NestedTypes. It might be interesting to consider how NestedTypes could create objects based on GraphQL schema or vice-versa and how GraphQL support could be integrated into NestedTypes as a replacement for the Rest API style CRUD interface from backbone I've always considered to be somewhat poor.

[gaperton]

Starting from version 2.0 (which is in 'develop' branch now) NestedTypes is rather the thin wrapper around https://github.com/Volicon/Type-R
Which contains just the serialization core without any REST and Backbone parts.

Type-R could be used as the basis for any side project. The main class is the Record, not the Model. It's done precisely because an I/O API part is controversial.

[gaperton]

We don't have any plans on GraphQL integration as I see no advantages in it over the plain REST in case of our applications. Seriously. Not a single one.

It's rather an old story - the question is whenever you want to construct ad-hoc queries on the client or rather have the fixed API for the database wrapped to the "stored procedures". So, starting from some certain DB size, you would likely prefer stored procedures and do not allow the client to execute just any arbitrary query. Quite intentionally. Not to mention the situation that the system on server side might be the heterogeneous collection of distributed services which could be written with different languages, making the handling of arbitrary requests not that easy thing. And if we can't do that, it's entirely not clear which benefits GraphQL have so it would justify refactoring of our services.

[gaperton]

Because of that, I would rather prefer having client-side state management technologies to be client/server transport and protocol neutral (which Type-R and NestedTypes really are - there are just two core API calls like something.toJSON() and something.set( json, { parse : true })). So (for instance) it would be easy to use some real-time data synchronization over the websocket and REST at the same time, still having the same data layer technology. But if it puts rigid requirements on the client, server, and communication protocol between them at the same time, I would rather call it an architectural mistake.

[far-blue]

I can see you've considered this in some detail :) I can def. see disadvantages in only a single endpoint and then a schema for your entire model set and all relationships. As you say, ad-hoc querying becomes problematic. However, I see advantages in a dependency schema and the ability to request or update small chunks of data from a possibly large and deep relationship tree in a single request. When you need to update a single key/value pair on 1000 models 1000 single use POST calls is less than performant :) I was actually considering giving each of my REST endpoints a GraphQL schema and trying to create the best of both worlds - or only using parts of the standard :)

[gaperton]

That's the good point, and as I said it can be done pretty straightforward taking Type-R and implementing GraphQL I/O layer on top of it.

To define GraphQL schema using attributes annotations you can override static define method, call the parent's define, and then iterate through this._attributes hash which stores attributes metadata. Key is the name of the field, spec.type is the constructor function, and when spec.toJSON is falsy the field must not be serialized. You get json with model.toJSON(), and you update the model with model.set( json, { { parse : true }). Same for collection. That's pretty much it. There might be some issues with handling the relations, though, but they are possible to handle too.

[gaperton]

I can help with that if you will decide to do it. It will be fun.

[gaperton]

Regarding the problem of updates. In our case, we are using REST for bulk data requests and websocket for pinpoint real-time updates. For instance, if we have the large model which is the root of the model/collection tree (such as Store), an update message from the websocket might look like this:

{ 'collection1' : { 'add' : [ { id : 1, some : 'data' } ] } }

and then, we iterate through this object and update each collection with something like collection1.add( [ { id : 1, some : 'data' } ], { merge : true, parse : true } ). This logic is implemented in the extended Store class, and isn't really complex. About 10 lines of code or the same order. I believe, this technique is practically far superior to using REST.

If you don't need push updates, you just provide separate urlRoot for smaller nested models/collections, and fetch them independently for the purpose of update. It also works fine.

[gaperton]

@far-blue, so what did you decided? As I said, I can help you with the project based on Type-R which will use GraphQL as an I/O medium. Fork the NestedTypes develop branch, delete stuff you don't need (I think, it would be almost all the stuff in src), and go ahead. I will contribute and help to choose the right approach. You can count on it. Still, I cannot test it as I don't use it. Thus, I cannot lead an initiative (it would be wrong). But I can (and will) consult you on design choices and can write some code.

[far-blue]

We are really only at the stage of discussing and evaluating GraphQL as a team. As our rest API is only one of a number of products/projects a quite small team is working on these things take time but, along with Web Sockets, Microservices and a few other concepts and technologies it is on the table for consideration and I'll let you know if we decide to adopt it - because I'll be asking more questions, I'm sure, on Type-R and NestedTypes 2 ;)

[gaperton]

Sure. Just keep in mind that I will help if you decide to make it.