Method calls are from client to server. What is there for the reverse direction (server -> client)?

[a4xrbj1]

I have two separate apps that communicate via ddp.connect, one is handling only the client side whereas the other one handles the connection to the db and the server. I successfully use method calls from client to server but now I need to send some data back the other way (from server to client), in this specific case some information that should be displayed in an infobox (just a modal with the text and and ok button).

Building the modal wasn’t a problem, using a helper to refer to the information also not. But what is the best practice to send information from the server to the client?

Shall I use a http call and build a small API (with one endpoint currently) just for that purpose with Restivus package?

Any other ideas?

Thanks in advance!

[robfallows]

publications and subscriptions.

[a4xrbj1]

Pub and sub sounds like another overkill for me (though I’m obviously doing
that already in both directions).

I just need to transfer a single string to the client which then gets
displayed in the info box. Any other suggestion?

[robfallows]

pub/sub is still your best option, but using a roll-your-own publication (not persisted in a DB collection).

Edit: check this one I prepared earlier:

How to get variable value from server to client?

So, I would do something like @cstrat suggests, like this (I don’t know the library you’re using - I assume temperature is updated automatically once initialised?): In a client/ folder TestData = new Mongo.Collection(null); // Put this on the client only // It will reactively update with a doc like {_id:‘abc123’, temp:23.5} Meteor.subscribe(‘test-docs’); // An arbitrary subscription name Then, on the server, you generate and publish data within a roll-your-own publication. Maybe something al…

[a4xrbj1]

Yes, now I get your idea. Not persisting is indeed much simpler than I thought you were suggesting. So it’s basically using the this.added (for initiation) and this.changed (in all later cases) to transfer the data via ddp. Interesting, I never looked into detail at these two as they are normally executed automatically (I assume) when I use Insert or Update/Upsert with a collection. Now I see a use case for them.

Will give it a try, thanks @robfallows

[a4xrbj1]

@robfallows one more question. How can I catch the update of the subscription in the client (sorry, I’m a backend dev, still not much knowledge about the client side). I need to trigger the modal box $('#nameOfModal').modal('show'); when the server is adding/updating this roll-your-own publication.

[robfallows]

You could do it entirely within Blaze’s reactivity:

<template name="something">
  blah blah
  {{#if modalNeeded}}
    <div class="modal">yada yada</div>
  {{/if}}
  blah blah
</template>

Template.something.onCreated(function() {
  this.subscribe('myModalThing');
});

Template.something.helpers({
  modalNeeded() {
    return ModalStuff.find();
  }
});

But you’d also have to ensure you send a removed from the publication to hide the modal when it’s closed.

Alternatively, you could observe the cursor: http://docs.meteor.com/#/full/observe if you want to use jQuery to trigger the modal as you have suggested.

[a4xrbj1]

Wow, this is getting much harder than I thought. As it’s a modal that I want to pop-up when the server has an important summary of some action to show to the user I think I can only use the jQuery `.modal(‘show’) in my case.

It’s also not so straightforward on the server side, as it’s quite different to the example with the temperature reading Arduino that you answered. Mine is an one-off trigger at a specific moment, then the modal should pop-up at the client with the text that I send over from the server. If I get this correct it would mean a normal publish of all records of this roll-your-own collection and the somewhere else in the code I would do the .added and .changed. Even making sure it’s initialised is just more overhead code.

I think it’s more elegant and easier for me to implement this as an endpoint with Restivus (as I used that package in the past), it gives me the security via a response code that the information was being received at the client.

Upon receiving the API call in the client I’d assign the transferred string to a global variable infotext which is then assigned in the helper:

Template.infobox.helpers({
    infoBoxText: function () {
        'use strict';
        return infoText;
    }
});

That infoBoxText is then used inside my template:

<template name="infobox">
    bla bla
    <div>
        {{{infoBoxText}}}
    </div>
</template>

Sounds a lot easier (at least to me). No need for the .onCreated part and no difficult publish part on the server, just fire one HTTP.post and that’s it. Maybe I overlook something as it’ already past 1am here, so I better try it with a fresh mind

[tomfreudenberg]

Hi Andreas ( @a4xrbj1 )

take a look at this thread :: Meteor and the Internet of Things (IoT) - whats best to use? Collection, Meteor-Streams, Streamy

You will find a number of hints and examples on meteorpad if you read my comments there.

Good luck
Tom

[trusktr]

I think something like

Meteor.methodsClient({methodName: function() {...}})
Meteor.callClient(userId, 'methodName', ...)

on the server-side would be nice. The same as Meteor.call on the client, except on the server the first arg is userId in order to find which clients to send the message to. What other ways could we identify specific clients beside userId?

[tomfreudenberg]

userId may not the way you are looking for, it is more subscriptionid - e.g. One User could be logged in multiple times on different devices and you just want to signal on some.

check out my posts about broadcast (or filter) messages.

If you want it “easier” by component try YuukanOOs streamy.

I would prefer in-built pub/sub because also authorization etc. is handled through that.

[a4xrbj1]

That was original thought but it unfortunately doesn’t exist (only client to server).

My use case is different than the IoT use cases with lots of data coming regularly or being checked in an interval or even broadcasting. That’s all overkill for my app.

I have one client only and I need to send a string to him. That’s it. It’s more like a confirmation when the server is finished doing the work that the client has asked him to do and sends a summary back to tell what was achieved in the task.

Again, I see the advantages of using pub/sub for most of the used cases and I have that as well when I need to regularly send (more) data from the server to the client.

That brings me back to what Joe also brought up. Is it technically possible to wrote such a server-to-client method package using DDP?

[robfallows]

I actually overthought my original response and I still think you can do what you want with a roll-your-own publication. Here’s the piece I missed … an unmanaged collection is not synced back up to the server, which means that the process can be simplified. On the server, always create a new entry (this.added). That document can contain whatever you want - including any server-derived data you may want to display in the modal. On the client, use a standard, reactive template much as I originally proposed (in which you can include that server-derived data if you wish). When you close the modal, just collection.remove({_id:xxx}); to complete the process.

That whole mechanism could be wrapped in some server-side callClient and client-side methodsClient sugar if preferred.