In Meteor Methods this.connection is always undefined - meteor

I am trying to implement some methods for a DDP API, for use with a C# remote client.
Now, I want to be able to track the connection to implement some type of persistent session, to this end, id hope to be able to use the session id given by DDP on connection, example:
{
"msg": "connected",
"session": "CmnXKZ34aqSnEqscR"
}
After reading the documentation, I see that inside meteor methods, I can access the current connection using "this.connection", however, I always get an undefined "this.connection".
Was it removed? If so, how can i access it now?
PS: I dont want to login as a user and access this.userId, since the app I want to create should not login, but actually just get a document id and do work associated with that, including changes to other collections, but all, regarding ONLY this id, and I dont want to have to include this id every time I call a function, since, this could possibly lead security problems if anyone can just send any id. The app would ideally do a simple login, then associate token details with his "session".

Changing from:
() => { this.connection; }
to:
function() { this.connection; }
solves the problem from me. Based on a comment in the accepted answer.

The C# client on github has a few bugs with it as it doesn't follow the DDP spec exactly. When you send commands to it to connect and run a call, it usually sends the '.call' too soon.
The method does work if you do it this way with this.connection on the server side Meteor method.
You need to make sure you send the method calls after you know that you are actually connected. This is what works at least with Meteor 0.8.2

I was using a file named ".next.js" to force meteor to use the newest unsupported javascript spec using a package.
Somehow this messed it up. Changed back to default javascript and it now works.
Thank you :)

init.coffee
Meteor.startup ->
# client init
if Meteor.isClient
Meteor.call "init"
methods.coffee
Meteor.methods
init: ->
console.log #connection.httpHeaders.host
it's that easy...

Related

Meteor methods - stream/yield data from server

I'm writing a Meteor app which allows clients to execute terminal commands on the server at the click of a button.
I know how to do this with a single command:
//server
Meteor.methods({ exec : cmd => { ... } })
//client
Meteor.call('exec', cmd, (err, result) => {
console.log(result)
})
But now I'm trying to implement a more complex protocol and don't quite know what the best way is. I want the client to kick off a series of commands, have the server run them and tell me, step by step, whether they succeeded or failed.
Obviously I could implement this with the above code by writing client-side code that runs exec with the first command, checks the result from the server, runs exec with the next command and so on.
The crux is that in my case the series of commands is always the same, so it would make much more sense to only do one Meteor.call on the client -- the server would know what commands to run. However I would also like to have the results of the individual commands available on the client as they come in -- and this is what I can't do, because Meteor.call only returns once, of course.
What I'm looking for is a sort of stream or iterator through which I can send a number of messages to the client until everything is done. I've seen some outdated packages called meteor-streams and similar that might be able to do something like that, but I'm thinking there must be a smart way in Meteor itself to solve this. Ideas?
A common solution is a Notifications collection. Create the collection with a schema: for: ${userid}, msg: ${msg string}, type: ${err success etc}. Create a Notifications publication, which publishes docs with the users userid.
You can then subscribe to the Notifications collection in some main template page on the client. Use observeChanges to look for changes to the collection and either console.log them, use JavaScript to display them on the page or simply install a package like sAlerts to handle them.
Inside the observe changes callback, a seenNotification method should be called which removes the notification from the db, so it is not shown again.
I'll post code snippets a bit later.
Have a look at this: https://github.com/RocketChat/meteor-streamer
I think it will solve your problem easily.

authWithCustomToken not firing callback

When a user registers on my system, I create the user internally, and then allow the user to register with Firebase using the firebase client lib. This generates a session token for the user. Later, when a user starts the app again, the app automatically logs the user in like this:
ref.authWithCustomToken(sessionToken, function(error, authData) {...
debugger
I have verified that the sessionToken is available when the function is executed, but debugger is never reached, and no error is ever emitted.
Any help is appreciated!
I know it's a bit late, but I experienced a similar problem and it had me scratching my head for a while, so just in case it helps somebody else, here's what I found.
If I run authWithCustomToken with a token generated with one uid (uid1) and then run it again on the same ref with a different uid (uid2), the callback doesn't get fired the second time around.
In my case, I had declared the same ref in different modules that were used in the same node process and was trying to authenticate them with different uids. Although I had declared the ref twice, Firebase still saw it as the same ref because it was in the same process and referred to the same Firebase location. By declaring and authorising the ref in a parent module, I was then able to use onAuth in the child modules and the onAuth callbacks all fired as expected.
I had a similar problem with iOS, authWithCustomToken callback was never called right after install.
All consecutive launches worked fine.
My findings might be related so I thought I share them.
Problem was I called
func applicationWillResignActive(application: UIApplication) {
Firebase.goOffline()
}
func applicationWillEnterForeground(application: UIApplication) {
Firebase.goOnline()
}
in AppDelegate. Turns out if you call Firebase.goOnline() without logging in first it messes up the callback. Once I removed those two lines everything worked fine.

How can I get alerted when the Firebase service goes down?

I know I can manually go to status.firebase.com but I need to be alerted immediately when my firebase app goes down and when it comes back up.
I thought I could possibly use dingitsup.com to send myself a notification, but i don't know where to point it.
I would also like to have the option of automatically displaying a message to my users when Firebase is down to let them know the system is down and its not a problem on their end. Is there a Zapier integration i could use to achieve this?
Any help would be great! Thanks
Programmatically, you could use a service like Pingdom to send yourself a notification, and could ping an endpoint on your-firebase.firebaseio.com/some-public-endpoint.json.
Also, #FirebaseStatus is a good resource actively updated by the Firebase folks.
Could you write something to use the connection state?
https://www.firebase.com/docs/managing-presence.html (broken)
new link: https://firebase.google.com/docs/database/web/offline-capabilities
I use something similar in my apps to detect if the user has a connection, and display a notice if they don't.
I just figured a way
Firebase.enableLogging(function(logMessage) {
if(logMessage && logMessage.indexOf("Long-poll script failed to load") !== -1 && navigator.onLine){
console.error('Its dead Jim! Firebase seems to be down for this user');
}
});
I'm not sure how firebase works under the hoods but I've seen users connected in a previously open tab and if they open a new tab firebase won't connect when it's down.
This logging function is called a lot, and when firebase is down our console.error will be call every ~5s or something.
Make sure to debounce whatever you'll do in the console.error's place.

Monitor meteorjs active reactive connections

We have a problem with our meteor server. When we publish 300 or so items with Meteor.publish/Meteor.subscribe the server increases its memory and eventually becomes unresponsive.
We thought of:
1) monitor the number of reactive subscribtions / memory taken by an active subscription
2) make something like ,,one time publish" - ignore changes in server side collection
Any thoughts on how any of the above can be accomplished ?
Or any other tips to debug /improve meteor app performance ?
Thanks
zorlak's answer is good.
Some other things:
You can do a one-time publish by writing your own custom publisher via the this.set API, based on the code in _publishCursor. You'd do something like:
Meteor.publish("oneTimeQuery", function () {
MyCollection.find().forEach(function (doc) {
sub.added("collectionName", doc._id, doc);
});
sub.ready();
});
This does a query, sends its results down, and then never updates it again.
That said, we hope that Meteor's performance will be such that this is unnecessary!
I'd also like to add an easy way to get stats (like number of observed cursors) from an app to Meteor (exposed as an authenticated subscription) but haven't had the time yet.
As of Meteor 0.5.1, one thing you can do is to remove dependencies on the userId from the publish function. If a publish function does not depend on which user is subscribing, then Meteor will cache the db query so it doesn't get slower as more users subscribe.
See this Meteor blog post: http://meteor.com/blog/2012/11/20/meteor-051-database-scaling

When or how would I use this.flush() in a Meteor application

I am trying to understand when I might use this.flush() in a Meteor application.
The docs state the following
Call inside publish function. Sends all the pending set, unset, and
complete messages to the client.
If my publish function is something like this
Meteor.publish('myCollection', function(myid){
return MyCollection.find({_id: myid});
});
would I use this.flush()?
What kind of case would one use this.flush() in?
Thanks
S
Not needed in that use case, because Meteor.publish automatically handles the details of how to turn Mongo cursors into the appropriate set and unset commands for each subscribed client.
If you write a custom publish that manages its own set and unset, you can use flush to push all pending changes down to the client. You'll find an example of that technique here: How does the messages-count example in Meteor docs work?

Resources