However I am perplexed by the fact so many languages listed there are, unless I am mistaken, in the practice of 2019 server-side languages (Python, Ruby, PHP, C#, Haskell), so what is the point of having DDP clients in these languages rather than DDP servers? But there seem to be very few non-JS DDP servers available (I found a django-postgres one, interesting for connecting to legacy apps probably).
What I am missing here?
The context that spurs my question is the following. At my university we are trying to build a modeling tool that:
reuses model-driven technology which is almost exclusively available in Java (Eclipse Modeling Framework plugins ecosystem) and finite domain constraint solvers that are almost exclusively available in Prolog, Java or C; almost no robust reusable JavaScript modules are available in these domains AFAWK;
features a web-based and real-time collaborative optimistic UI to maximize collaborative productivity and minimize friction, a requirement that pointed us towards Meteor.
We thought of trying a microservice architecture with some services in Meteor and others in Java. However, without a Java DDP server, I guess a Java server can communicate with a Meteor server only through either gRPC, REST or MongoDB drivers. But wouldn’t these three approaches make us loose the built-in reactivity of the DDP-based reactive pub/sub pattern that makes Meteor such an attractive technology for web-based collaborative apps?
A “Client” doesn’t have to mean a browser (or user’s machine), any computer, including servers, can be a client. Using the Java DDP Client, a Java server can connect and communicate with Meteor over DDP
Ahah, thank you very much for your reply! So please let me check whether I understood your answer correctly.
So could I for example:
Put up a Java web socket server at some url1 running a Java DDP client
Start a Meteor app with a Meteor client running in the browser, a Meteor server running at url2 and a Mongo DB running at url3
Have the Meteor web client connecting to the Java server using DDP.Connect(url1), use Meteor methods from the Meteor web client to remotely call Java methods running on the Java server
Then have the Java server use DDP.Connect(url2) to call Meteor server methods to (a) persist the results of the Java server method computation on the MongoDB running at url3 and b) trigger reactive update of the minimongo cache in the Meteor client running in the browser with the result computed by the Java method.
AFAIK, you cannot do #3 (“Have the Meteor web client connecting to the Java server using DDP.Connect(url1), use Meteor methods from the Meteor web client to remotely call Java methods running on the Java server”).
All the (released) Java DDP libraries I’ve seen are clients - they can connect to a Meteor Server to run Meteor Methods hosted on the Meteor server and subscribe to publications, but cannot take on the role of a Meteor server (host methods and publications).
So then you agree with me that these Java DDP client libs are only useful for Android mobile clients and are not meant to run on a Java web socket server as part of a reactive DDP based microservice architecture with some server-side services in Java and others in Meteor communicating through DDP (instead of gRPC, http or indirectly through operations on a shared Mongo DB server).
But what to do with a PHP, C#, Ruby or Haskell DDP client that only support subscriptions to reactive Mongo DB collections but no publications of them?
We’ve used a Java client (the keenya one you’ve found) to communicate with a Meteor server via method calls and pub/sub. It worked well, so I tend to disagree that mobile apps are the only use case. However, I don’t know of any peer-to-peer systems involving a Java service.
I’m not quite sure what you’re asking. If they use a DDP client then they are not expected to be able to publish - in the same way you can’t publish from a browser client. By definition, a client is a consumer of a service, not a provider.
Having said that, publishing data which conforms to the DDP spec is not difficult, if that’s what you want to do.
I’m not quite sure what you’re asking. If they use a DDP client then they are not expected to be able to publish - in the same way you can’t publish from a browser client. By definition, a client is a consumer of a service, not a provider.
I am just assuming that pure consumers playing only the client role and not the server role in a microservice architecture are essentially UI/FrontEnd components.
But today, UI components of client-server applications run mostly in the browser (JS only) or on mobile platforms (Java, Swift)
So what I am wondering is what are the UI components developped in PHP, C#, Ruby or Haskell that make DDP clients for these languages useful?
I don’t know. In our case, there was no UI component. The Java piece collected performance data from servers. We used DDP to enable “real-time” inspection and reconfiguration of the metric collection.
@coagmano@stanp But do you agree that a DDP client library for a foreign language must provide connections and subscriptions while a DDP server library for a foreign language must provide connections and publications, so they are quite different pieces of software, independently on what kind of computer and where on the network they are deloyed?
Just to make sure that I am not missing a point that you were trying to make…
Yes, they are separate pieces of software though they can both run on the same server and network. For instance, Meteor is obviously a DDP server, but can also act as a client by connecting to other DDP servers.
Why would you want to have an application that can make HTTP requests, but doesn’t serve webpages?
By this logic, all web browsers are useless.
Just like there are plenty of applications that consume remote APIs without having a UI or exposing their own API, you can create all sorts of applications consuming a DDP API