Meteor 3.0-beta.6 is out!

announce releases
12

With a delay, here are some tips. Mind you, we use a package-based architecture, in which the packages themselves have low or at least manageable coupling, which in turn helps to an extent with the problem of async bubbling up everywhere.

  1. Use separate git branches, and merge after each successful test.
  2. If using a package-based, or any kind of modular application architecture, load the minimum of modules, and modify as needed, to ensure a first successful boot. Then work your way up, adding the rest of packages/modules progressively.
  3. Start with a well defined, and relatively well-contained problem that requires switching to async/await. For instance, replacing the deprecated http package with fetch. Move through your entire codebase, and one by one, modify each function, then follow up wherever this function is called, and so on. This will help you keep the bubbling under control.
  4. Find another similarly well-contained problem, like perhaps instances of using Meteor.wrapAsync. Replace all these with async/await, or if you have callbacks, promisify them. Trace them across the entire codebase. Same goes if you ever used the Future option available with fibers. By the time you finish with these problems and their limited scope, a good chunk of your higher level APIs and Meteor methods and/or publications should have been upgraded to async/await, then your job becomes easier later.
  5. If you have isomorphic usages of Mongo APIs within synchronous functions that are not yet possible to change, like MongoDB queries inside SimplSchema functions, consider changing your approach. One such example can be seen in this post. This is a tough nut to crack and my advice is to use an approach like I describe here. This kind of refactoring should be performed on a stable version of your app & Meteor, then merged to your async branch(es).
  6. Heavy (isomorphic) usage of a particular package and its APIs, like alanning:roles and Roles.userIsInRole. In our case, we were already maintaining a forked version. So we ended up simply having a sync version of Roles.userIsInRole for the client. I know this may not be to everyone’s liking, but we do not really use isomorphism beyond schemas and collection declarations. So, oh boy, we would not start rewriting the entire frontend for the sake of some APIs that must be async for the sake of isomorphism. Then, on the server, we went and refactored all its usage to async, which meant we had to update all our internal authorisation APIs, which then caused another async bubbling, though still manageable.
  7. I am assuming you are working on an async-friendly Meteor version that is pre 3.0.0. So, work on all Mongo API related code and leave all changes that are only possible in 3.0.0 for the final step (like Accounts.<something>.) If you really are in a bind because of collection-hooks, like we were, you’d be happy to hear that there is a PR (see my previous reply) you can fork locally, at least while working on upgrading your app. Obviously, caveats apply; you may want to contribute to the fork, or wait for signs from Meteor Software as to what is going to happen with this package. In our case, given the minimal usage, yet essential, of this package, the fork does the job just fine while we are in testing phase.
  8. Once all your HTTP calls, Mongo API queries, Roles and other function have been refactored, and you are happy with the result, time to upgrade to Meteor 3.0.0. Change the usage of WebApp, Accounts APIs that need to be async.

This sounds way too simple, as it is indeed simplified. But our experience was that the workload was less dramatic in practice than what looked like in theory. Of course it depends on whether you inherited a codebase or it was yours to begin with. It depends on how well it is modularised, tested, and so on.

Also, it matters how many external packages you depend on. If I have to pinpoint to the single most important hiccup, this was it. I am not thinking of packages that really are essential, but we did use this opportunity to get rid of some that we only used very lightly.

[UPDATE] There we go, at least with respect to alanning:roles, the community approach is going to be the same as what we did: What's left until an official Meteor 3.0? - #27 by storyteller

4 Likes