🚀 Meteor 3.5-beta: Change Streams & Performance improvements

[xet7]

@nachocodoner

I fixed login bug by adding router fallback:

Fix login and register to not require page reload by adding router fallback.

[italojs]

@nachocodoner

As far as I know, there are several changes in accounts packages and login behavior that could have affected this. But if something is broken, it is definitely critical, and we should find a way to reproduce it.

This is the purpose of the beta: to test and find bugs in real projects before an official release. I’m on vacation until the 19th, so I’ll review it soon.

btw thank you very much wekan for using that beta. We appreciate this kind of contribution a lot.

[xet7]

Previous change did not fix Login bug, so this one did fix it:

After register or login, redirect to All Boards page.

[harry97]

My two cents on this is that Wekan had lots of lingering bugs that weren’t really attended to and were brewing underneath. Once the migration was done, it got exposed so some of these aren’t really the beta problems.

Nonetheless, the enthusiasm and having a big project like Wekan test out these betas is an amazing benefit to Wekan itself and the broader Meteor community!

[xet7]

I had some problems with Snap, so I migrated to Docker. Here is how I run Meteor 3.5-beta, Node.js 24.x, MongoDB 7.x with changeStreams and uws at Hetzner bare metal server that has 64 GB RAM, 2x1TB NVME RAID, Ubuntu 26.04, Linux kernel 7,x, and over 14k users. (MongoDB 8.x did not work, it causes some attachment upload and disappearance bugs).

wekan/docs/Platforms/FOSS/Docker/Meteor3 at main · wekan/wekan

[xet7]

Next interesting bug. At my WeKan hosting, every browser page reload does load webpage of different customer. This is the free hosting login page, but sometimes there is different custom logo login page:

https://boards.wekan.team/sign-in

I tried to make to not cache at Caddy config, but it did not help:

wekan/wekan/blob/main/docs/Platforms/FOSS/Docker/Meteor3/caddy/Caddyfile#L244

[xet7]

Now I turned off CloudFlare caching with Development Mode. I’ll check does it help.

[xet7]

It looks like it did not help. Well, I’ll think of something else.

[xet7]

I fixed this multitenancy bug by changing from changeStreams uws to oplog sockjs and some other settings.

Use only oplog sockjs so that multitenancy works.

[italojs]

@xet7 can you please provide some guidance of how to reproduce it, please? so I can investigate what is happening

[xet7]

@italojs

Bug description:

wekan/wekan/blob/main/docs/Platforms/FOSS/Docker/Meteor3/multitenancy.md

Current working config. If it is changed to changeStreams uws, it breaks:

wekan/docs/Platforms/FOSS/Docker/Meteor3 at main · wekan/wekan

[italojs]

It was a little bit hard to reproduce and debug but now I have a propose fix.

The root cause come from the interaction of two bugs in the ddp-server/transports/ package of Meteor 3.5-beta.10 when multiple processes (or tenants) share the same network namespace. First, the uws internal port configuration silently fails because the code attempts to read settings from a client-side object (__meteor_runtime_config__.meteorSettings) that is never populated on the server, thus ignoring user configurations and always forcing the default port (5001). Second, since the uWebSockets.js library uses the SO_REUSEPORT option by default, multiple different Meteor instances can successfully bind to the exact same port (127.0.0.1:5001) without throwing any collision errors. As a result, the Linux kernel randomly load-balances and routes incoming WebSocket connections across the different processes, inadvertently mixing one tenant’s requests into another tenant’s database.

Here you can find a PR with the fix where I will land in the next beta, where you will be able to test it again.

[trusktr]

@italojs

const app = express();

// ...

WebApp.handlers.use(app);

Reading this code is a little bit confusing. Meteor already uses Express under the hood. But it seems like this code is creating a “new” express with the express() call.

Does this mean this code is telling Meteor’s existing express (which we extend with Meteor.handlers) to also use the new Express server, so we have two? Does it replace Meteor’s with a new one? Or what exactly?

Btw the docs are very lacking on these features, and because of it AI is making wrong assumptions or hallucinating.

I would greatly appreciate for all Meteor features to be released with complete docs, so we don’t have to dig into source code, and so AI won’t create random junk when we ask it to do something.

I think documentation is super pertinent in the AI era, otherwise we end up with super slop, ultra crazy unnecessary workarounds, or stuff that just doesn’t work.

It is also not clear what the difference is between the above example and the following which does authentication checks without a new express() being called:

Expose Meteor user context to Express endpoints

Hello community! I recently pushed a PR that introduces a dedicated package, accounts-express, for authenticating Express endpoints defined through Meteor’s WebApp package. It makes it possible to protect specific REST endpoints in a way similar to how DDP endpoints like methods and subscriptions already work, and it also ships an auth-aware fetch so the client (and the server) can call those endpoints with the user’s token attached. The final shape splits cleanly into two pieces: an auth mi…

import { WebApp } from 'meteor/webapp';
import { createAuthMiddleware } from 'meteor/accounts-express';

// Apply auth middleware to /api routes
WebApp.handlers.use('/api', createAuthMiddleware());

// Protected endpoint under /api
WebApp.handlers.use('/api/users', async (req, res) => {
  if (!(await Meteor.userAsync()).profile.isAllowedToDoSomething) {
    // ...block action, return 500 error to client...
    return
  }

  // ... proceed with authenticated user ...

})

[nachocodoner]

@trusktr

I would greatly appreciate for all Meteor features to be released with complete docs, so we don’t have to dig into source code, and so AI won’t create random junk when we ask it to do something.

Have you had a chance to check the original post from @italojs? It already included the link to the docs (press “Documentation” link): https://github.com/meteor/meteor/blob/release-3.5/v3-docs/docs/packages/accounts-express.md. This Markdown file will be officially available in Meteor docs once Meteor 3.5 final is released, and it includes what is needed to understand and use the package.

It is also accessible in the Meteor 3.5 beta preview docs: accounts-express | Docs.
More info in the dedicated forum post: Expose Meteor user context to Express endpoints, where we also cared to update the first post to describe the final approach and usage.

Remember this is still a beta. While we have provided the docs needed to use the feature, they are not available yet in the official Meteor 3 docs. So AI tools will not always have that context by default. For new beta features, it helps to provide the links and information shared in the Meteor 3.5 highlights and in the dedicated forum post for this addition.

It is also not clear what the difference is between the above example and the following which does authentication checks without a new express() being called

That’s right. The example above is a high-level one, meant to show the general idea of getting an Express instance to use the new endpoints. But Meteor can also reuse its own Express instance.

In the docs we prepared and linked, and in the forum post, there is also an example focused on Meteor’s built-in Express instance. That is referenced as the default documented approach.

Of course, docs need visibility from our side, and we tried to share all the materials we prepared. After a re-read focused on them, do you think they cover the main cases?

Where do you think we could improve?