Use JSONPatch instead of custom verbs in DDP

[mitar]

DDP could be just an extension over JSONPatch. Allowing deep changes and not just top-level changes.

[dcworldwide]

Interesting idea. Would this mean that a conflict resolution will now apply to a document sub-tree and not the entire document? If so that sounds very promising, as presently we often to denormalise a data model to support multi user editing use cases.

[stubailo]

Sounds like a cool idea for the next version of DDP. We'll have to do some thinking about the design anyway when we start taking into account other kinds of databases and applications, so we'll definitely take this into account then!

Thanks for the feature request! We welcome discussions about how to make Meteor better. If you haven't yet, check out our wiki page about feature requests on GitHub.

[mitar]

Is there some list of features I could make for DDP? My feature list is:

• JSON patch for verbs
• backpressure (DDP is lacking backpressure control #3740)
• allowing to add JSON schema to the document, or custom metadata, in general it could just be additional JSON which is associated with the document, but is not provided through MongoDB interface, but some other interface, you could store in it things like which publish is sending the data, or from which collection is coming, or some other annotations; the main important thing why it should be part of DDP is that it is in sync with data, I am currently using two collections and there are issues because sometimes data is available before annotations come over the wire

[ejfrancis]

JSONPatch seems like it's a perfect match for the way DDP is being used in Meteor apps currently. I feel like I'm constantly being forced to change my data model to something other than the true "correct" approach for MongoDB to accommodate the top-level fields being sent down the wire, like when an array is the proper data structure to use but I don't want N extra fields being sent down when I add a single value. Being able to model our data however a developer wants and send the minimal amount of data down the wire to apply changes would be a top priority for me for the next version of DDP..

[SanderMertens]

@ejfrancis That is exactly the issue I'm running into (#4752). Glad the discussion on this is still ongoing. Would love to see an update on when a new revision of DDP is going to be published.

@mitar With respect to a metadata scheme for documents, you might find www.corto.io an interesting experiment. It's a developer-oriented, strongly typed hierarchical object (document) store which has a DDP connector.

[dcworldwide]

Using nested arrays / sub-documents within a single document is the only way that I've managed to ensure atomicity and integrity within a complex multi-user edit scenario. It works great, but as this thread and #4752 suggests, DDP doesn't do this as efficiently as it should. Would really love to see this issue be given more attention, it has a broad benefit.

[hwillson]

To help provide a more clear separation between feature requests and bugs, and to help clean up the feature request backlog, Meteor feature requests are now being managed under the https://github.com/meteor/meteor-feature-requests repository.

This feature request will be closed here, but anyone interested in migrating this feature request to the new repository (to make sure it stays active), can click here to start the feature request migration process. This manual migration process is intended to help identify which of the older feature requests are still considered to be of value to the community. Thanks!