Calling methods from a method (server-side)

help
1

Hi,

I’ve read the documentation about the migration towards a fiber-free life that it will now be impossible to call a method from another method.

We did use it quite a lot in the code for methods that are not called that frequently. But still, we’ll have to change quite a bit of code.

What would be an easy way to modify that code ?
Turn methods into functions that are then called by a “wrapper” method for each? That would allow it to be called from a client or from a method ?

Any other idea ?

Regards,

Burni

2

Where did you read this? I can’t find it anywhere.

3

Hi @minhna,

It’s been quite difficult to find it back.

Maybe the team has found a solution ?

It would be very interesting to understand when that will stop working if it’s the case.

image
image884×1021 93.8 KB

4

I don’t think @janmp was right. But I’m not sure.
Meteor 2.9 was released with this commit: Meteor version to 2.9.0 ☄️ by Grubba27 · Pull Request #12356 · meteor/meteor · GitHub
You can try create a Meteor 2.9 app, then set the evinroment variable DISABLE_FIBERS to true and try to call methods from method.

1 Like
5

Please someone do this, it’d be indeed be a big blow to our current architecture if this would be true.

I don’t actually understand why it should be the case, code-wise. Calling Methods from the server was always supported and why shouldn’t it work as before, with one async method awaiting the next (or not), as required.

I haven’t really started working on the migration though. We’ll start piecemeal in January I think.

6

I tried to start a fresh Meteor 2.9 with DISABLE_FIBERS flag but
the app crash:

.meteor/packages/meteor-tool/.2.9.0.119qbjj.pwz6++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle/server-lib/node_modules/fibers/future.js:280
						throw(ex);
						^

TypeError: self._nextObjectPromise(...).await is not a function
    at SynchronousCursor._nextObject (packages/mongo/mongo_driver.js:1154:38)
    at SynchronousCursor.forEach (packages/mongo/mongo_driver.js:1168:22)
    at SynchronousCursor.map (packages/mongo/mongo_driver.js:1178:10)
    at SynchronousCursor.fetch (packages/mongo/mongo_driver.js:1202:17)
    at Cursor.<computed> [as fetch] (packages/mongo/mongo_driver.js:937:32)
    at MongoConnection.findOne (packages/mongo/mongo_driver.js:812:56)
    at OplogHandle._startTailing (packages/mongo/oplog_tailing.js:231:57)
    at new OplogHandle (packages/mongo/oplog_tailing.js:85:8)
    at new MongoConnection (packages/mongo/mongo_driver.js:210:25)
    at new MongoInternals.RemoteCollectionDriver (packages/mongo/remote_collection_driver.js:4:16)
    at Object.<anonymous> (packages/mongo/remote_collection_driver.js:51:18)
    at Object.defaultRemoteCollectionDriver (packages/underscore.js:784:19)
    at new Collection (packages/mongo/collection.js:110:40)
    at module (imports/api/links.js:3:32)
    at fileEvaluate (packages/modules-runtime.js:336:7)
    at Module.require (packages/modules-runtime.js:238:14)
Exited with code: 1
Your application is crashing. Waiting for file change.

It looks like 2.9.0 is not ready to run without fibers

7

Can someone involved in the strategy behind a fiber-free meteor comment on this ?

@janmp have you heard any news about this since your post I copied here ?

Regards,

Burni

8

@burni13 There’s a simple and straightforward solution for this issue:

  1. Move logic from Meteor methods into regular functions
  2. Call these functions instead of calling the methods

This way you’ll introduce enough flexibility to suit your needs.

We (Astraload team) can assist you should you have any difficulties implementing this solution and also do some advanced stuff like introducing unit-testing or assessing your project performance-wise.

2 Likes