My journey towards meteor 3.0

3.0 migration
1

Hello all,

I really don’t know if this is of any interest for someone, but I feel like maybe it could be of some use to have another thread to share some experiences and thoughts about moving projects towards meteor 3.0

About myself+my project: I have a private repo on meteor 2.12 + react + react native client, that is an app for the organization of schools, such as timetable and substitute schedules, resource management etc.

I have some server internal methods (~450) and quite a lot pubs and methods and just started building a restful api to get some existing third party apps connected.

All of this is done in my free time as a side project, since in my main job I’m a teacher, but I really love developing the project, since I hope it might help a lot of people in school with their job&learning. Currently I have around 3200 users using the app actively. I deployed the app at scalingo.io. When I started this project around two years ago I had no clue on nodeJS, react or anything, but since I white labeled Rocket.Chat + RN client for our school during the pandemic I came across meteor and love it since I finished the react todo tutorial :slight_smile:

This is how I move to 3.0:

First I used this guide here and the jscodeshift scripts to get a first conversion of my internal server methods. That really worked quite well, but some schemes won’t get covered (such as array.forEach(...) or array.some( async (item) => {} ) patterns like that).

In order to make sure that everything works as expected I‘m adding mocha Tests for all of these methods. That’s taking a lot of time but currently I’m at about 90% test coverage.

I also rely on several packages, like Roles and Migrations, also meteor-push and ostrio:files

For Roles and Migrations I have forks where I added async functions (like Roles.userIsInRoleAsync(...)) to move await from fibers. But there’s a lot of testing required here, especially for async Roles methods. (One can easily run into serious problems when checking Roles like if (Roles.userIsInRoleAsync(user, "admin")) { ... } :wink: )

I also used Collection Hooks to get some tenancy functionality into my app, but I couldn’t get and async version of this running, so I implemented tenancy functions without hooks.

I guess that ostrio:files will also needed to be updated to async functions.

Also, I could find any async version of these meteor Accounts url functions, but maybe this has changed in the meantime.

Finally I still have some basic questions on how the client will be affected. As fibers only live on the server, will I still be able to use Meteor.call from the client side via (err,res) => {}-style callbacks? (Would be quite a time-saver…).

Alright, will now get my last couple of tests ready. I’d be really interested in sharing experiences with all other devs moving their apps to meteor 3.0.

Thanks for the meteor team for all the work they put into meteor! Keep going guys!

11 Likes
2

Definitely an interesting read! Keep em coming! Will have to move to 3.0 myself soon, so good to read about other people’s experience.

1 Like
3

Waiting for the guide. We have a sizeable code base with 4 apps interconnected with shared code especially for the collections.

Our first order of business is to figure out how to migrate in parallel while developing new features/products. We have a new product to be developed that will coincide with this migration.

Or figure out which parts of this code migration that will require a code freeze so we can schedule a few days or a week just doing this (hopefully not more)

After the migration, we also need to move to new versions of npm packages that we were stuck with due to node constraints or issues with fibers like SSR with React 18

1 Like
4

I’m glad it helped. You’re right, some patterns doesn’t work, maybe you could create a pull request to make it work with those patterns.

1 Like
5

At the moment I only do really important hotfixes on my main branch and try to merge changes into my async branch (which is a 100% merge conflict all the time…). Feature requests are stalled. Since my async branch changes touches hundreds of files I’m really glad that by now auto merging async in my main branch seems to work.

When I got my server functions ready and tested, I’ll merge them into my main branch, so that I can potentially add features or fix bugs for production more easily.

6

Thanks for your script, I find it really amazing how it helped across my server functions. I’m really a noob on jscodeshift, so I ended up editing all functions manually, which was necessary anyways since I needed to add docs and tests to almost every method…

7

It also can help you on front-end react components.

8

Imagine working with a team, and this is chaos

9

So this is a must, right? No more Meteor.call(…,(err,res) => { ... })?

10

I also came across the following question: I get a lot of warnings from the Accounts package, since obviously methods such as Accounts.findUserByUsername still use fibers, and Accounts.findUserByUsernameAsync doesn’t seem to exists (yet?).

Is this on the roadmap?

11

There’s no problem when you have callback function in Meteor.call. But if you call the Meteor.call without callback, then you need to use Meteor.callAsync

1 Like
12

Hello @bratelefant, we have reviewed the packages you mentioned and have encountered some challenges, particularly with packages that utilize the kernel architecture, such as redis-oplog. Migrating these packages to the 3.0 version may be a complex and resource-intensive task, and we believe it should be approached in a methodical and organized manner to avoid duplication of effort.

Unfortunately, we are currently unable to begin this activity due to limitations in the alpha version, which does not allow for the compilation of third-party packages. As a result, we have been focusing our efforts on migrating to the asynchronous version of the server-side mongo, which has been a significant undertaking and has occupied us for several months.

We have not yet addressed the possible migration of the client, and there is some concern about the timeline for releasing our applications. At this time, we are unable to provide a specific release date.

1 Like
13

Which ones do you mean, and where do you see complex tasks? E.g. the Roles and Migrations package could be a rather easy one to transform. Also meteor-push shouldn’t be to complicated too.

14

redis-oplog rewrites kernel logic, which is not exactly easy to modify and test. Collection hooks also has some peculiarities to consider which must be examined carefully. I am concerned that many of us are modifying packages, which I consider to be standard, on their behalf and losing sight of sharing them.

1 Like
15

I think that’s true, since preparing a PR means potentially quite some extra work for those who are already at (over) 100% load… :wink:

16

Ok, for now i finished the transition of all of my methods and pubs and have tests for my methods and rest api. The remaining warnings on fibers are coming from accounts-base, meteor-files and monti. Looking really forward for those packages to get updated.

5 Likes
17

That is a great case study, thanks for sharing your experience.

1 Like
18

Congrats!

You might want to report it here: https://github.com/meteor/meteor/pull/12359

1 Like
19

Thanks for sharing. I already feel my gray hair growing when I read all of this.

2 Likes
20

Yeah, it’s not so much fun really…
I also noticed that memory consumption is quite a bit higher when everything’s changed to promises.

Got my async update up and running in my staging environment. Monti reports RAM usage of ~300mb in contrast to ~225mb when no sessions are active…

I‘m really curious what will happen here when I get some load on the server…

1 Like