How to integrate with backend in different language?

Is it possible to integrate Meteor with a(n already existing) backend (in another language)?

More specifically I’m interested in how data can be sent back and forth between a Meteor client and a backend in another language / framework without losing reactivity.

Use cases for this could be:

  • use another database than MongoDB
  • use an already existing backend application (with the option to slowly migrate the backend to Meteor as well)
  • write a new application entirely in Meteor with the option to move the backend to a new stack in case there is a need for it (e.g. better scalability)

I know Meteor uses the DDP protocol for communication between components but it is unclear to me if / how the above could be achieved.

1 Like

Meteor is a fullstack javascript framework.
You can’t split server and client (otherwise you’ll break the definition of the Meteor haha), and I guess that MDG won’t do something like this in the future.

You can implement DDP.

http://www.meteorpedia.com/read/DDP_Clients

@grubens I know Meteor is advertised as being a fullstack framework, but on the other hand the documentation also says that the client isn’t aware it is talking to a server and vice versa.

To my understanding this means there is an abstraction layer (cfr DDP) between client and server, meaning it should be possible to separate client and server and as a result also to replace client or server with something else.

For clients this is apparently already done (cfr generation of mobile clients, ddp client implementations in different languages allowing one to create a client in his preferred language/framework, etc)

For the server side however I couldn’t find much information on how to do it.
There is this hackpad discussion from a year ago, but that’s almost anything I could find on the subject.

@ahref That’s a reference on DDP clients but what I am asking for is a server side implementation of the protocol in another language/framework (java, plain node.js, whatever).

1 Like

There’s not too much out there - and what there is is in node. However, these may provide creative fuel - I’m sure MDG would like to see a diverse set of DDP server solutions!

https://www.npmjs.com/package/ddp-server and Ddp-server-reactive

Meteor is doing some hard parts on the server that cannot be easily replicated to another language without a lot of work. Dispatch has connected a Meteor app with a Rails API backend. The approach is to replicate the database (e.g. relational one) to MongoDB. The MongoDB is connected with the Meteor app. The Meteor backend exposes the Rails API with Meteor methods from the Rails API to the Meteor client (like a proxy).

Thanks, that’s useful information!

Hmm, the fact that there isn’t much info on this topic probably confirms it indeed that it isn’t that trivial to implement.
Replicating the database is more like a temporary workaround than a real solution in my opinion.

There’s Django-DDP.

Django/PostgreSQL implementation of the Meteor DDP service, allowing Meteor to subscribe to changes on Django models.

1 Like

This is a pretty old topic, but I’m new to Meteor and the same question crossed my mind. I have nothing against the node backend. However I’m a big fan of Erlang/Elixir since it can perform so well.

1 Like

There doesn’t seem to be much a path for bringing a Meteor MVP to a more scalable production infrastructure.
DDP, pub-sub, etc all seem to provide a kind of lock-in.

It would be nice to be able to repurpose some parts of an MVP for a production app versus a complete rewrite and realizing that only the data and perhaps the templates can be salvaged.

FWIW, there are meteor-client-bundler projects on github that allow you to fill mini-mongo on your own in order to use an existing front-end, if you are prepared to get your hands dirty…

stuff like https://github.com/frozeman/meteor-build-client

end of the day, despite the custom protocol and pub-sub model it’s still webpack, javascript, etc… if there is enough interest it’s possible but not trivial: I would say start by finding another way to fill-up mini-mongo