Moving DDP forward

Cool- adding a related question here:

Is DDP in need of a new owner now that MDG folks have moved on to APollo? Where is the protocol description on which graphql is based? I want to compare the two but lack the support. I also lack the support to defend DDP to others if it is not being maintained. My team personally would want to add some features or maybe even alter- but I wouldn’t know who to join forces with. Thanks @sashko and MDGers. I still have fun showing people what’s possible with DDP, and building great stuff, but I feel the redirect of attention to the query language and not the protocol leaves senior engineers who want to know the mechanics of if a little in the dark.


In the Meteor contributor guidelines there is a process for submitting new designs. DDP works great today and we use it for a variety of things. If you have ideas for improvements please submit a design and you might be surprised!

People spend a lot of time talking about how hard it is to contribute but many of those people haven’t really tried. Give it a shot.


Thanks. I’d like to inform my submission with the graphql protocol if you want to call that out. I never had trouble discovering DDP but graphql Leaves implementation detail questions like must an entire result be conveyed at once or can a client make use of partial results.

Hey, hope you don’t mind that I moved this to a new thread.

I think improvements to DDP should stand on their own merits, rather than being involved with GraphQL.

GraphQL has a pretty standard protocol right now which is just HTTP requests where you send a query and get a single response back. People have thought a bit about DDP-like protocols where you send objects incrementally, but there aren’t any features in GraphQL yet that will be able to take advantage of such a protocol.

Our current mindset is that the two technologies should grow in parallel until the GraphQL community agrees on some realtime functionality that can be added, in which case it will come much closer to Meteor, and we’re participating actively in that process by working on GraphQL subscriptions as a first step.


One great first step with regards to moving DDP forward would be to swing by the Meteor repo and help address the 59 open DDP related issues (that have been triaged - I’m sure there are many more that haven’t been classified yet). Any time that can be contributed towards lowering that issue count would be greatly appreciated!


Hugh. I’m an hourly consultant, and I’m not going to implement DDP issues that aren’t mine (yet) for free on the clock, I’m going to look for alternatives, or add my own monkey patches or fork for the features I need.

@deanius - you could just do what I do (I’m an hourly consultant as well); pretend you’re working but really spend most of your time on the forums and the repo. Then just before your deliverables are due, nail them out in record time thanks to Meteor! :slight_smile:

(P.S. --> I don’t really do this potential future clients … honestly, I don’t … :no_mouth:)


Perhaps some of the issues align with your needs? If not, then open issues and then they will?


Yeah, Hugh, I never have worked on OSS during client hours, never :slight_smile:

1 Like

@deanius, no one is encouraging you to skim your clients. However, if in order to complete your clients’ work a short path is to advance an OSS project a bit, then it’s normal, every one benefits. We have paid for OSS additions which got pushed to public repos. It’s 100% normal … they benefited from someone else’s work, nothing wrong with contributing. Give AND take … not just take.