Forem: Meteor

Faster Server Startup in Meteor 3.4 with Deferrables

Gabriel Grubba — Thu, 12 Feb 2026 22:01:43 +0000

As you might have seen in the 3.4 release blog post, Meteor has received a HUGE update with a lot of focus on the developer experience. One of the new additions was the new deferrable functions, which we will dive into today in this blog post.

Why were those functions added?

While seeing teams update to 3.4, we saw a recurring problem: build times have gotten faster with rspack, but the developers were not feeling it because they had a bottleneck at the startup

With that in mind, we did our investigation, and we saw that those apps that were not feeling this increase in productivity were the ones that had async or costly operations being done at the startup. You can think of requesting data from external APIs, waiting for sidekick services to get started, etc.

For production, this makes sense — you don’t want your app to start without those dependencies ready. You might not need all that. With that in mind, we made this addition to our api.

New API

The added functions were: deferrable, deferDev, deferProd. I'll start with the first.

⚠️
If a function is not deferred for the current environment, it runs immediately and behaves exactly like a normal function call (including return values).

Meteor.deferrable

In the docs, we can see it in action:

import { Meteor } from "meteor/meteor";

Meteor.startup(async () => {
  await Meteor.deferrable(connectToExternalDB, {
    on: ["development"],
  });
});

This means that, on development, this connectToExternalDB function will run deferred (scheduled to run after the initial startup completes, instead of blocking it).

You can define test, development, and production – for testing only environments, this can be very nice!

Conceptually, deferrable functions let Meteor finish booting the app first, and then run non-critical async work afterward. The app becomes usable sooner, even if some background initialization is still happening.

Meteor.deferDev

deferDev is an abstraction on top of deferrable with the options for development and testing environments.

This is probably the one that will be used the most. You should use this one for flagging those functions that can run later in development mode; Consistently using it will make your overall startup and rebuild faster.

In our hypothetical PR example, using deferDev was saving our startup time in around two seconds!

And to use it is very simple:

  const connectToExternalExpensiveService = async () => {
    const sleep = (ms) => new Promise(resolve => setTimeout(resolve, ms));
    console.log("Connecting to external expensive service...");
    await sleep(Math.random() * 2000 + 1000); // simulate expensive connection
    console.log("Connected to external expensive service!");
  }

  await Meteor.deferDev(connectToExternalExpensiveService);

Meteor.deferProd

deferProd is an abstraction on top of deferrable with the options for production.

This is used for more one-off cases. We saw usage in this one for connecting to dev-only services and to overall services that will be used later in production, but were necessary to be there at startup when working locally.

A good example is warming a cache or connecting to an analytics pipeline that won’t be used during the first requests, but must still exist in production.

Using deferrable with values

The last notable thing about this new API is that deferred functions, if they are not deferred they, work exactly as if they were not marked as deferred.

You can see this logging example:

 console.log("Before defer Dev");
  Meteor.deferDev(async () => {
    console.log("Connecting to some external service...");
    console.log("This will run later on local mode!");
  })
  console.log("After defer Dev");

  console.log("Before defer Prod");
  Meteor.deferProd(async () => {
    console.log("Connecting to some service...");
    console.log("This will run later on prod mode!");
  })
  console.log("After defer Prod");

  // in a regular meteor run
  // Before defer Dev
  // After defer Dev
  // Before defer Prod
  // Connecting to some service...
  // This will run later on prod mode!
  // After defer Prod
  // Connecting to some external service...
  // This will run later on local mode!

Very cool, eh?

But also this API can return values so for example you can have this example in your code:

  const value = Meteor.deferDev(() => "later_in_dev") || Meteor.deferProd(() => "later_in_prod");
  console.log("value is set to:", value);

If a function is not deferred for the current environment, it runs immediately and behaves exactly like a normal function call (including return values).

⚠️
You can see all the examples that I shared today in this PR

Migration & Conclusion

To start getting gains with this new API, begin by wrapping your slowest startup work — external connections, async setup, or non-critical initialization — with deferDev and measure the impact. Most teams will see improvements immediately.

Galaxy team saw these improvements first hand – their local environment, with these optimizations, got ~3x faster!

You can think of these functions as saying: this work is important — just not right now.

Treat deferDev as part of your startup hygiene: anything that doesn’t block correctness should be a candidate.

If you haven’t revisited your startup code since upgrading to 3.4, now is the perfect time — you may be sitting on seconds of free productivity without realizing it.

If you’re migrating to 3.4 and have questions, run into edge cases, or want to share how much startup time you shaved off using these APIs, join the conversation on the Meteor forums. We’d love to hear what worked for your app — and what didn’t.

We’re excited about what’s to come and can’t wait for you to join the Meteor renaissance!

For feedback, questions, or support, visit our forums or join our Discord channel.

Meteor 3.4 is out: Rspack integration, 4x faster builds, 8x smaller bundles, and extended bundler features

Nacho Codoñer — Fri, 30 Jan 2026 15:35:58 +0000

Meteor 3.4 marks the final day of the Galaxy Expansion and celebrates a new era for the framework that started it all, bringing modern tools into the core Meteor experience.

Meteor 3.4 introduces the Rspack bundler in the core to improve the dev experience by cutting build times, reducing bundler size, and supporting standard configuration patterns and features from the wider JS ecosystem.

This is a big step forward to address many long-requested improvements Meteor users have talked about, and we moved toward them across the newer Meteor 3 era.

In Meteor 3.2, we started by adding tools to monitor our goals for the build experience, with meteor profile introduced to measure build times and bundle size.

In Meteor 3.3, we delivered the first round of optimizations for faster builds on the Meteor bundler, getting more from the solid and mature mechanism used for Meteor apps since the beginning. We added a new transpiler with SWC, a new watcher, and other improvements.

In Meteor 3.4, to wrap up this effort on improving the bundler experience, we focused on delegating to a modern tool like Rspack, which let us meet all initial goals and allow Meteor apps to apply efficient HMR, tree shaking, full ESM support, modern plugins, and more.

Our core team has already migrated to Rspack for the Galaxy Cloud app, showing the optimizations applied to a real-world app like the one hosting your Meteor apps. This post details the changes and shows the Galaxy app’s improvement metrics as an example of what to expect with your Meteor 3.4 upgrade when adopting the Meteor Rspack integration.

This release also includes community contributions for Meteor React packages by improving stability and performance of suspense hooks, integrating collection-extensions package into core, considering Cordova as a modern build, and more.

Getting Started

To start using Meteor 3.4.

Create a New App

# Create a new Meteor app using Meteor 3.4
meteor create my-app --release 3.4

All improvements introduced in Meteor 3.3 and 3.4, including the Rspack integration, are enabled by default for new apps and applied to all skeleton examples. Check meteor create --help to see the available skeletons.

Update Your App

# Update your existing Meteor app to version 3.4
meteor update --release 3.4

Add modern to your package.json to enable the Meteor Bundler optimizations:

"meteor": {
  "modern": true
}

Check out the requirements for Meteor Bundler optimizations on existing apps.

☄️Meteor Bundler optimizations docs

Add rspack package to enable the Rspack Bundler integration:

meteor add rspack

Check out the requirements for Rspack Bundler integration on existing apps.

⚡Rspack Bundler integration docs

Highlights

Faster Builds

Meteor 3.4 goes further than Meteor 3.3 and the initial SWC adoption. With Rspack now compiling your app code, you get the speed of this modern tool built in Rust. The Meteor bundler still compiles Atmosphere packages and links the final app code, but that part was already optimized in Meteor 3.3, so you get the best of both.

With meteor profile, build times drop ~70% and are over ~3.5x faster. Rebuild times for both client and server are now much shorter, making development far quicker.

These metrics were measured for the Galaxy app Rspack migration, coming from Meteor 3.3 applied optimizations. Your app will see similar improvements.

Smaller Bundles

Meteor 3.4 introduces one of the most awaited features to keep app bundles small: tree shaking. With the Meteor-Rspack integration, bundle size is significantly reduced through this built-in optimization, along with other Rspack strategies such as chunk splitting, dynamic imports, minification and more.

After migrating and deploying the Galaxy app, the main client bundle size dropped by about 88% compared to previous 3.3.2 release. Client bundles are now thinner, meaning less code delivered and faster initial load times for your apps.

The gains vary by app, its dependencies, and the optimizations used. Just by applying tree shaking you will get improvements; sometimes smaller, sometimes much larger, depending on how tree-shakeable your dependencies are.

Additionally, by using code splitting and dynamic imports you split the main chunk, reduce the main size, and load other pieces on demand. Give it a try and play with these options in your project.

Atmosphere Bundle Reduction

What is more, Meteor 3.4 adds an optimization for Atmosphere packages by introducing:

The ability to mark packages as devOnly, so they’re fully removed from production builds.
A new Npm.devDepends option in your package.js to define dev dependencies, ensuring only the needed node modules for development are included during dev time and excluded from production (meteor build).

After deploying the Galaxy app, the total bundle size stored on the host machine dropped by about ~42%. This improvement applies to all apps, since Meteor core packages now use the new Atmosphere optimization configuration. More gains will come as you update your own Atmosphere packages or community ones to properly skip dev-only packages and dependencies in production builds, leaving your final containers on hosts noticeably smaller.

Modern Setups

Meteor 3.4 introduces Rspack so you can configure modern setups from the community.

Supported setups include React, React Compiler, Vue, Solid, Svelte and Angular, all using their latest versions. Legacy setups like Coffeescript and Blaze remain supported, keeping older projects compatible.

With this update, ESM packages are fully supported. Meteor apps can now use modules that rely on ESM behavior. A clear example is the support for React Router v7, a long-standing request from the community.

Rspack also opens many new options. All Rspack or Webpack features can be configured in Meteor apps, including Workbox for Service Workers and PWA, asset imports and optimizations, and controlling the bundler lifecycle for custom behaviors and improvements.

What Else Is New in Meteor 3.4?

Thanks to the commitment of many of our community contributors, we have been able to expand this release with new features and optimizations.

react-meteor-data updated to 4.0.1, bringing improvements to suspense hooks and general optimizations. @welkinwong, @malua, @evolross, and @StorytellerCZ delivered these updates along with other maintenance.
Integrated collection-extensions into core, part of our goal to bring widely used packages across Meteor projects into core for better support and maintenance. Thanks to @harryadel for making this possible.
Cordova builds are now considered modern instead of legacy when "modern": true is set in your project’s package.json. @tmeyer24 prepared this change, laying the groundwork for future native updates with CapacitorJS or similar modern tools.
--raw-logs is now the default in the Meteor CLI for development. @paulishca suggested this, with full consensus from the community, and @Grubba27 provided the update quickly.

More improvements and fixes were introduced in Meteor 3.4, see the changelog.

For more insights into the release, watch the release video:

📹 Meteor 3.4 and the road ahead - Galaxy Expansion Day 5.

For more about the modern build stack, including Rspack, we joined Meteor Impact and gave a talk that explains its adoption, migration, and expected benefits.

📹 Modern Build Stack in Meteor 3: Empower Your Meteor Apps with Faster, Feature-Rich Bundling

Big Thanks to our contributors

Reaching the 3.4 milestone would not have been possible without such an active and enthusiastic community. We want to highlight how important these contributions have been for this release.

Thanks to our core contributors: @nachocodoner, @italojs, @Grubba27, @welkinwong, @harryadel, @vparpoil, @StorytellerCZ, @turoar23, @DipakHalkude, @sanki92, @evolross, @malua, @tmeyer24, @jeetburman and @copleykj

Thanks to all community members for the testing and feedback on Meteor 3.4.

What’s Next for Meteor and Beyond?

For the upcoming releases, we have the following priorities.

Stability and patches. Collect feedback and fix issues. Planned Meteor 3.4.x patches.
Change streams. Unified MongoDB change notifications. Planned on Meteor 3.5 release./
Node 24. Align with newer Node LTS releases.
Native. Move toward a modern native solution beyond Cordova.

For more details on upcoming work and priorities, see the Meteor roadmap.

Join the Meteor Renaissance!

Meteor 3.4 wraps up the significant bundler changes we had envisioned. From these changes we will keep tweaking the bundler to expand and improve the experience if needed. Still, we’ll continue updating Meteor to revitalize the framework we all love in other areas as well.

We’re excited about what’s to come and can’t wait for you to join the Meteor renaissance!

For feedback, questions, or support, visit our forums or join our Discord channel.

If you find any issues, please report them to the Meteor issues tracker.

Stay tuned, and as always, happy coding! ☄️

GitHub Actions + Galaxy: Zero-Downtime Deploy CI/CD

Philippe Oliveira — Fri, 22 Aug 2025 14:55:43 +0000

I recently set up a zero-downtime deploy pipeline for my Meteor app using GitHub Actions and Galaxy and honestly, it was way simpler than I expected.

In this post, I’ll walk you through how I did it step by step. You’ll have a fully working push-to-deploy setup in minutes using secrets for safety, pinned Meteor versions for consistency, and Galaxy’s infrastructure for smooth deploys.

Galaxy is Meteor’s official cloud hosting platform designed for simple, reliable deployments with integrated monitoring.

Today, beyond Meteor, Galaxy also supports Node.js, Python, and databases like MongoDB.

Learn more here

🚀 What we’re building

A GitHub Actions workflow that deploys your Meteor app to Galaxy automatically on every main push
Secure configuration using GitHub Secrets (no plain text credentials in the repo)
Reliable, reproducible builds with a pinned Meteor release for consistency

⚡ Why CI/CD with Actions helps

If you’ve ever deployed Meteor locally, you know how resource-hungry the build process can be high CPU load, memory spikes, and your laptop fans going full throttle.

Running this through GitHub Actions takes that pain away:

Builds run entirely on GitHub’s hosted runners (Ubuntu VMs).
Your machine stays free for real work no waiting around for Meteor to compile.
Every run happens in a clean, isolated environment, so you avoid “works on my machine” problems.

The result: faster, more consistent deploys, no local slowdowns, and zero babysitting during the build.

🔗 Useful links

Galaxy CLI deploy docs
Galaxy regions
GitHub Action: aquinoit/simpletasks-ghactions

✅ Prerequisites

You’ll need:

A live Galaxy app (e.g. myapp.meteorapp.com)
MongoDB configured via your app settings
A GitHub repo with Actions enabled

1️⃣ Create a Meteor session (local, one-time)

Meteor’s CLI deploy requires a valid session. We’ll create one locally and convert it to base64 to use securely in GitHub.

METEOR_SESSION_FILE=./meteor_session.json meteor login
base64 -w0 meteor_session.json > meteor_session.b64

Save the base64 string output — we’ll add this as a GitHub Secret.

2️⃣ Add your GitHub Secrets

Go to your repo → Settings → Secrets and variables → Actions → New repository secret

Add the following two secrets:

Secret Name	Description
`METEOR_SESSION_B64`	Paste the contents of `meteor_session.b64`
`METEOR_SETTINGS`	Your app’s settings JSON (as a single line)

Tip: use jq -c to compress your settings file into one line:

jq -c . settings.json

3️⃣ Add the deploy workflow

In your project, create a file at .github/workflows/deploy.yml with:

name: Build & Deploy to Galaxy

on:
  push:
    branches: ["main"]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: meteorengineer/setup-meteor@v2
        with:
          meteor-release: '2.14'  # Use your exact Meteor version

      - run: meteor npm install

      - name: Write settings.json
        run: |
          printf '%s' '${{ secrets.METEOR_SETTINGS }}' > settings.json

      - name: Show Settings
        run: cat settings.json

      - name: Deploy to Galaxy
        uses: aquinoit/galaxy-ghactions@0.0.2
        with:
          meteor_session_base64: ${{ secrets.METEOR_SESSION_B64 }}
          app_hostname: myapp.meteorapp.com
          region: galaxy.meteor.com
          settings_file: ./settings.json
          deploy_flags: '--free'
          npm_install: 'true'
          npm_install_args: ''

4️⃣ Push and deploy

Now commit and push to main. The workflow will run automatically and deploy your app to Galaxy.

git add .
git commit -m "ci: automatic deploy to Galaxy"
git push origin main

Then on GitHub:

Go to the Actions tab
Click on Build & Deploy to Galaxy
Watch the logs in real time!

🔐 Secrets & best practices

Never commit settings.json. The workflow writes it at runtime.
Use a Meteor account with the minimum necessary access for deployment.
Consider separate workflows for production and staging environments.

🧯 Common issues & fixes

Meteor “superuser” warning
You can ignore this. The action already includes --allow-superuser internally.

Deploying to the wrong region?
Use the correct region hostname:

US: galaxy.meteor.com
EU: eu-west-1.galaxy.meteor.com
APAC: ap-southeast-2.galaxy.meteor.com

“Can’t find action” error?
Make sure:

You have uses: aquinoit/galaxy-ghactions@0.0.2
You’ve included the checkout step at the top

🧪 Production tips

Pin your Meteor version in the workflow to avoid surprises
Add a second workflow for develop → staging app
You can also enable manual deployments with workflow_dispatch in your workflow. This allows you to trigger a deploy from the GitHub Actions UI, without pushing a commit.

✅ Final thoughts

That’s it! You now have a clean, secure CI/CD pipeline that deploys your Meteor app to Galaxy automatically — with zero downtime. Just push to main and watch it go live in seconds.

🔗 More resources

🔮 Coming soon: GitLab CI and Bitbucket Pipelines

This guide focused on GitHub Actions, but I’ll soon publish versions tailored for GitLab CI and Bitbucket Pipelines.

So if your team uses those platforms, stay tuned the same zero-downtime deployment approach applies, just with different syntax.

Let me know if this was helpful or if you hit any issues while setting it up happy to help!

Faster Builds in Meteor 3.3: Modern Build Stack with SWC and Bundler Optimizations

Nacho Codoñer — Tue, 17 Jun 2025 14:41:26 +0000

Meteor 3.3 slashes build times by around 60% on average, with some projects building over 3× faster builds.

This is the first major update to the Meteor bundler in years, introducing several optimizations. The main change is switching from Babel to SWC for transpiling and minifying to speed up builds. We reviewed and optimized the bundler’s components to improve the development experience.

On our core team, we’ve already seen these gains after upgrading the Galaxy Cloud app, and the cloud team’s development and delivery have become significantly faster. This post details the changes and shows the Galaxy app’s improvement metrics as an example of what to expect with your Meteor 3.3 upgrade.

This release also includes community contributions for Meteor React packages, improving stability and performance of common hooks and adding support for React 19.

Getting Started: A Quick Hands-On

To start using Meteor 3.3.

Update Your App

# Update your existing Meteor app to version 3.3
meteor update --release 3.3

Create a New App

# Create a new Meteor app using Meteor 3.3
meteor create my-app --release 3.3

Add this to your package.json to enable the new modern build stack:

"meteor": {
  "modern": true
}

This setting is on by default for new apps.

Highlights

Modern Build Stack

Meteor 3.3 brings a new build stack: SWC for transpiling and minifying, @parcel/watcher for file watching, and smarter skips for legacy bundles.

Turn on "modern": true in your package.json and see rebuilds and builds fly!

On average, build and rebuild times are cut by about 60%, roughly a 3× speed-up.

These results come from the Galaxy Cloud app. In the next sections, we break down improvements for development and production experiences. Your app’s numbers may differ, but you can expect similar gains.

Curious about the gains? Run meteor profile to compare Meteor 3.2 vs 3.3 on your project and share your results!

Development Breakdown

When running meteor run, timings from meteor profile in Meteor 3.2 vs 3.3.

On average, these runs show about a 60% reduction in build times, corresponding to roughly a 2.7× speed-up, and exceeding 3× in many cases.

Production Breakdown

When running meteor build, timings from meteor profile --build with and without "modern": true.

On average, these runs show about a 60% reduction, corresponding to roughly a 2.5× speed-up.

Build Stack Upgrade

Transpiler

The transpiler converts modern JS syntax in all app code to a cross-browser compatible version.

Meteor profiling showed most build time goes to Babel transpilation (meteor run/meteor build). To fix this, we added SWC (in Rust), which speeds up rebuilds in both development and production.

There are no breaking changes for most apps. If your app uses nested imports (not dynamic ones), it may fall back to Babel. The same applies if you use Babel plugins that SWC does not support yet. You can find SWC equivalents or disable SWC for those files.

We also added a doc page with tips for migrating and debugging the new setup.

🔗 Modern Transpiler: SWC docs

Minifier

The minifier reduces and obfuscates your app’s production bundle for security and efficiency.

Meteor profiling showed Terser spends a lot of time on production builds (meteor build). To fix this, we added the SWC minifier, which speeds up builds.

@italojs adapted the minifier from the zodern/minify-js-sourcemaps package, cherry-picked it, and integrated it into Meteor core, delivering the performance gains we wanted.

🔗 Modern Bundler: Minifier docs

Web archs

Web archs are the builds Meteor generates for modern browsers, legacy browsers, and Cordova.

Skipping web.browser.legacy and web.cordova speeds up builds. In development mode, Meteor skips these archs when they aren’t needed.

Thanks to @9Morello for driving this forward!

🔗 Modern Bundler: Web Arch docs

Watcher

The watcher listens for changes in your app’s code files and triggers quick recompilations.

Meteor now uses @parcel/watcher. This improves development mode speed and compatibility by using native, recursive file watching on all OS. It also fixes a long-standing Linux delay where file changes took 5 seconds to register.

🔗 Modern Dev Server: Watcher docs

Tools: CPU profiling

Observability is crucial for data-driven releases. In our effort to enable this, we’ve improved our profiling tools and made them available to everyone.

We added environment variables to generate and inspect CPU profiles. In his guide, @italojs shows how to run these profiles and pinpoints Babel as a bottleneck now replaced by SWC in 3.3.

We enhanced the meteor profile command introduced in Meteor 3.2. It now includes a --build flag to profile the production build and highlight minifier gains. Rebuild reports now emphasize total rebuild times so you can track client and server build improvements.

React 19 Support

We updated the meteor/react-packages repo to restore tests/CI and ensure compatibility with Meteor 3. Contributors also improved the performance of useFind and useSubscribe, and added React 19 support.

Try the new beta of react-meteor-data:

meteor add react-meteor-data@4.0.0

Thanks to @welkinwong, @Poyoman39, and @PedroMarianoAlmeida for their contributions and tests!

Be aware of a breaking change: useFind describes no deps by default #431

What Else Is New in Meteor 3.3?

For full details on what’s included in Meteor 3.3, see the changelog.

For more insights into the release, watch the release video.

We want to highlight how important community members contributions have been in delivering these changes.

Thanks to our core contributors: @nachocodoner, @italojs, @Grubba27, @zodern, @9Morello, @welkinwong, @Poyoman39, @PedroMarianoAlmeida, @harryadel, @ericm546, @StorytellerCZ.

Thanks to community members for testing and feedback on Meteor 3.3: @zodern, @minhna, @paulishca, @pmogollon, @ferjep, @wreiske, @schlaegerz.

What’s Next for Meteor and Beyond?

For the upcoming releases, we have the following priorities.

Stability and patches. Collect feedback, fix missing support or issues in modern build stack, and ship pending contributions. Planned Meteor 3.3.x patches.
Modern bundler. Integrate a bundler that meets current standards for performance, tooling, plugin support, and community growth. Planned for Meteor 3.4. A demonstration is available, please share your feedback on the Meteor-RSPack integration.
Change streams. Provide a unified API for MongoDB change notifications to improve efficiency and consistency. Research is underway, please share your feedback: MongoDB Change Streams support in Meteor.

To learn more about upcoming work, see the Meteor roadmap.

Join the Meteor Renaissance!

Meteor 3.3 delivers significantly faster build times for your Meteor app development experience. These changes are just the beginning; we’ll continue updating Meteor to revitalize the framework we all love.

We’re excited about what’s to come and can’t wait for you to join the Meteor renaissance!

For feedback, questions, or support, visit our forums or join our Discord channel.

If you find any issues, please report them to the Meteor issues tracker.

Stay tuned, and as always, happy coding! ☄️

Big Changes at Meteor Software: Our Next Chapter

Frederico Maia — Fri, 16 May 2025 17:02:54 +0000

As the CEO of Meteor Software for the past 3 years, I wanted to share some major exciting things about where we're heading. When I first joined the company, I had a clear vision to modernize Meteor and transform Galaxy into something bigger.

Today, I'm excited to tell you that these changes are finally happening.

A New Era, A New Identity

First things first! We're introducing fresh new brands for both Meteor and Galaxy. This isn't just a cosmetic facelift. It shows that we are changing our direction in a significant way.

We've been using the original Meteor logo for more than 13 years, and it has become quite recognizable within the JavaScript community. The decision to change it wasn't made hastily, but we felt it was essential to reflect our ongoing evolution.

Our new Meteor brand represents our commitment to modern JavaScript. It features a cleaner, more contemporary design that represents our future direction rather than just our heritage. The redesigned Meteor website is now ready and includes a really cool interactive demo that showcases what Meteor can do. We're excited for you to check it out and experience Meteor's capabilities firsthand.

Meanwhile, Galaxy's new independent brand shows it's growing beyond its Meteor-only roots into a robust, multi-stack cloud platform.

Meteor 3: Embracing the Node.js Ecosystem

After countless long nights and coffee-fueled coding sessions, we released Meteor 3.0 in July 2024 (now we're at version 3.2). This release wasn't just another version bump. It shows where we want to go in the future. We changed from using Fibers to using async/await, which is what most developers use now. We also support the newest version of Node.js. These changes help Meteor work better with other Node.js tools.

This is important because instead of maintaining our own solutions for everything, we're now able to use the best tools the JavaScript ecosystem has to offer. Why reinvent the wheel when there are already amazing solutions out there? Since I started working at Meteor Software, I wanted Meteor to work well with other Node.js tools instead of being separate and alone.

What's Coming in 2025

Looking ahead, our 2025 roadmap shows exactly where we're heading. We're embracing integration with powerful, proven tools instead of making everything ourselves.

Bundle Optimization: Our Current Priority

We're working to make Meteor apps smaller and faster:

Working with modern bundlers: We're making it easy to use RSPack, ESBuild, and Rollup so your apps will load faster and use less memory
Faster builds: With our new tools (added in version 3.2), we're making builds take less time
Better development experience: Making changes to your code will show up more quickly while you're developing

Other Important Improvements

We are also going to work on:

Modernized RPC Methods and Publications: Adding self-documenting code, better validation, and more intuitive interfaces while maintaining backward compatibility
MongoDB Change Streams: Using the official way to get real-time updates from MongoDB
Better TypeScript support: Making it easier to use TypeScript with Meteor and its packages
CapacitorJS for mobile apps: A better, newer way to build mobile apps than our old Cordova system
Faster releases: Making our own process quicker so you get updates sooner

All these changes will solve real problems that developers face every day.

We will write clear, helpful guides about all these new features so everyone can use them easily, whether you're new to Meteor or have used it for years.

Galaxy Expands Its Universe

I'm particularly excited to share what is perhaps our most significant announcement. Galaxy is undergoing a comprehensive transformation. Upon joining the company, I recognized Galaxy's potential to evolve beyond its role as a Meteor-only hosting platform. Today, I'm pleased to announce that we're realizing this ambitious vision.

Galaxy 2.0 integrates our previous dashboard and backend systems into a cohesive, intuitive platform that significantly enhances the user experience. The truly revolutionary aspect, however, is Galaxy's expanded support capabilities. The platform now supports Node.js and Python applications, including frameworks such as Express, Nest, Adonis, Flask, and Django. And we're developing support for Ruby on Rails, which will be available in the coming months.

Our promise is simple but powerful. We'll provide the most user-friendly cloud platform and the most responsive support team available. We believe cloud hosting shouldn't be complicated, and when you need help, you deserve proper answers from people who understand your challenges.

Complete Platform with Database Solutions

In 2024, we enhanced Galaxy by adding MongoDB hosting directly on the platform. This significantly simplified deployments for teams needing reliable, managed MongoDB solutions. We're continuing this evolution in 2025 by expanding our database offerings to include PostgreSQL, Redis, and FerretDB.

These additions transform Galaxy into a comprehensive platform for hosting applications and databases together, streamlining deployment and management considerably.

This isn't just an upgrade. It's a complete transformation. Galaxy now operates as an independent platform with its own dedicated website and distinct brand identity separate from Meteor. The new Galaxy brand reflects our commitment to serving a wider developer community while maintaining the reliability our users expect. We're making a substantial investment in this expansion for 2025.

Our Team Structure

I want to be transparent about our organization. These advancements are being delivered by dedicated, autonomous teams working diligently behind the scenes.

We operate with two specialized technical teams, each led by its own tech lead while sharing the same CTO. The teams maintain separate roadmaps and priorities, focusing exclusively on their respective products. The Galaxy team advances our cloud platform, while the Meteor team enhances and maintains our open-source framework. Our DevOps specialists, though formally part of the Galaxy team, provide support to both divisions when infrastructure requirements arise.

This organizational approach ensures consistent attention to both products, with Meteor and Galaxy each receiving the focused development they require.

Why These Changes Matter

I won't present you with buzzwords or empty promises. As developers ourselves, we understand what's truly important: reliable tools that enhance productivity and effectiveness. These changes address genuine requirements:

Meteor requires improvements on DX, scaling, and compatibility with modern JavaScript
Galaxy needed to support additional technologies because that's what teams actually use in the real world
Both products needed to communicate their evolution with new, modern brand identities

The refreshed branding for Meteor and Galaxy isn't merely cosmetic. These are deliberate declarations of our direction. They demonstrate our dedication to innovation and our readiness to meet current development demands. The real improvements are in the technology and its capabilities. We're committed to developing robust, practical solutions for real-world development challenges.

Try It Today

If you're a Meteor developer, I encourage you to upgrade to Meteor 3 today. You'll immediately feel the benefits of native async/await and modern Node.js features. Meteor 3.3, which is currently in beta, already brings faster builds. Check out Meteor 3 docs.

For those working with Node.js, Python, and their popular frameworks, consider exploring Galaxy. Visit our new Galaxy website to discover how we've simplified cloud deployment.

I'm really proud of what our teams have built, but we're just getting started. There's so much more coming down the pipeline, and we'll keep you updated as we roll out new features.

Let's build amazing things together.

Enhancing Performance in MeteorJS bundler: Complete Guide to CPU Profiling

italojs — Fri, 28 Mar 2025 19:20:50 +0000

Performance is a fundamental concern for any modern web application, and Meteor apps are no exception. Currently, one of our main focuses is optimizing the Meteor bundler, which can be a significant bottleneck in larger projects. Although Meteor already offers built-in tools for performance analysis, using native CPU profiling can provide much deeper insights into performance bottlenecks. In this article, we'll explore how to effectively use CPU profiling in Meteor, including the difference between Meteor's current profiling system and native profiling based on Node.js Inspector, with special emphasis on how this can help improve the bundling process.

What is CPU Profiling?

CPU profiling is a performance analysis technique that tracks exactly which functions are being executed by the CPU, for how long, and how frequently. This type of analysis allows you to identify precisely where your code is spending the most processing time.

Unlike simple time measurement techniques (like basic timers), CPU profiling creates a comprehensive view of code execution, including:

Function call tree - shows which functions call other functions
Execution time for each function
Frequency of calls for each function
Memory allocation (in some cases)
Call stack visualization

Current Meteor Profiling vs Native CPU Profiling

Meteor's Built-in Profiling System

Meteor has a built-in profiling system that can be activated by setting the METEOR_PROFILE environment variable. This system uses a timer-based measurement approach:

METEOR_PROFILE=1 meteor <command>

This profiler is designed specifically for the Meteor ecosystem and works through manual code instrumentation. The result is a report that shows the time spent on different Meteor operations, such as:

| (#1) Profiling: ProjectContext prepareProjectForBuild
| ProjectContext prepareProjectForBuild..........9,207 ms (1)
|    _initializeCatalog.............................24 ms (1)
|       files.readFile                               7 ms (2)
|       runJavaScript package.js                     2 ms (1)
|       files.rm_recursive                           4 ms (4)
|       other _initializeCatalog                    11 ms
|    _resolveConstraints.........................6,702 ms (1)
|       bundler.readJsImage.........................42 ms (1)
...
| (#1) Total: 9,544 ms (ProjectContext prepareProjectForBuild)

Native CPU Profiling with Node.js Inspector

Recent versions of Meteor have included support for native CPU profiling using Node.js's inspector module. This approach generates .cpuprofile files that provide much more detailed data and can be analyzed with advanced tools such as Chrome DevTools or cpupro.

To enable native CPU profiling:

METEOR_INSPECT=bundler.bundle,compiler.compile meteor <command>

Advantages of Native CPU Profiling:

Complete execution view: Captures all functions being executed, not just those manually instrumented
Interactive analysis: Allows you to visually explore and filter performance data using graphical tools
Hidden bottleneck discovery: Identifies problems in third-party libraries or Node.js code
Superior precision: Uses CPU sampling directly, providing more accurate data about actual CPU usage
Multiple metrics: Beyond time, can provide data on memory allocation and other aspects

How to Use Native CPU Profiling in Meteor

Basic Configuration

To generate a basic CPU profile, use the METEOR_INSPECT environment variable specifying which functions you want to profile:

# Profile a single function
METEOR_INSPECT=bundler.bundle meteor build ./output-build

# Profile multiple functions
METEOR_INSPECT=bundler.bundle,compiler.compile meteor build ./output-build

Available Functions for Profiling

Meteor supports profiling for several critical functions:

bundler.bundle - Application packaging process
compiler.compile - General compilation
Babel.compile - Babel-specific compilation
_readProjectMetadata - Reading project metadata
initializeCatalog - Package catalog initialization
_downloadMissingPackages - Downloading missing packages
_saveChangeMetadata - Saving change metadata
_realpath - File path resolution
package-client - Package client operations

Advanced Configuration Options

You can customize the profiling behavior with additional environment variables:

# Identifier for profile files
METEOR_INSPECT_CONTEXT=context_name

# Directory where .cpuprofile files will be saved (default: ./profiling)
METEOR_INSPECT_OUTPUT=/path/to/directory

# Sampling interval in ms - lower values = more details but uses more memory
METEOR_INSPECT_INTERVAL=500

# Maximum profile size in MB (default: 2000)
METEOR_INSPECT_MAX_SIZE=1000

For Large Applications

Larger applications may require more memory for profiling. To avoid out-of-memory (OOM) errors:

NODE_OPTIONS="--max-old-space-size=4096" METEOR_INSPECT=bundler.bundle meteor <command>

Analyzing CPU Profiling Results

With Chrome DevTools

Open Chrome DevTools
Go to the "Performance" or "Profiler" tab
Click "Load Profile" and select the generated .cpuprofile file

With cpupro (Open-Source Visualizer)

For more advanced analysis, you can use cpupro:

Visit https://discoveryjs.github.io/cpupro/ in your browser
Drag and drop your .cpuprofile file onto the interface
Use the interactive visualization to explore your profile data

cpupro offers several advantages over Chrome DevTools:

Better handling of large profiles
More flexible filtering options
Advanced search capabilities
Multiple visualization modes
Ability to compare different profiles

Practical Use Cases

Identifying Bottlenecks in Template Compilation

If your Meteor application is taking a long time to restart after template changes, you can use:

METEOR_INSPECT=compiler.compile meteor run

Analyze the resulting profile to identify which templates are causing the most overhead.

Diagnosing Slow Build Problems

For apps with slow builds:

METEOR_INSPECT=bundler.bundle meteor build ./output

Look in the profile for functions that are consuming excessive time, such as CSS processing, code transpilation, or minification.

Optimizing Package Loading

If you suspect packages are affecting performance:

METEOR_INSPECT=_downloadMissingPackages,package-client meteor update

When to Use Each Type of Profiling

Use Meteor's Built-in Profiling (`METEOR_PROFILE`) when:

You need a quick and general overview of Meteor tool performance
You're analyzing specific issues in Meteor operations
You prefer simple text-based reports
You have limited system resources (less memory usage)

Use Native CPU Profiling (`METEOR_INSPECT`) when:

You need more detailed analysis than the standard profiler provides
You're investigating complex performance issues
You want to identify specific bottlenecks in heavy functions like bundler or compiler
You need interactive visualization and in-depth analysis
You're looking to understand issues in third-party libraries or Node.js runtime

Real life demo

When using CPU profiling in real Meteor applications, we can identify specific bottlenecks that significantly impact performance. Let's analyze two practical examples:

Case 1: Babel as the main CPU consumer

When examining a Meteor CPU profile, we can clearly observe that Babel is the module consuming most of the processing time, both in self time (time spent within the function itself) and total time (time including calls to other functions):

This is a known issue in the Meteor community and fortunately it's already being addressed by PRs #13675 and #13674, which aim to replace Babel with SWC, a much faster transpiler written in Rust.

PR #13675, in particular, implements a smart approach: it uses SWC for initial transpilation, but preserves reify to maintain Meteor-specific features, such as reify modules, nested imports, and top-level await support. This allows gaining speed without losing important functionalities of the Meteor ecosystem.

Case 2: Analyzing by Self Time - The bottleneck in compiler-plugin

When sorting the same profile by "self time", we find the "script" module appearing as the one consuming the most processing time.

Digging deeper, we see that the compiler-plugin.js file is responsible for much of this consumption. And digging even deeper, the _linkJS function stands out as the most expensive of all.

Examining the flame graph of this function, we can see that there is especially intensive processing in the generation of hashes for the cache system:

const cacheKeyPrefix = sha1(JSON.stringify({
  linkerOptions,
  files: await Promise.all(
    jsResources.map(async (inputFile) => {
      fileHashes.push(await inputFile.hash);
      return {
        meteorInstallOptions: inputFile.meteorInstallOptions,
        absModuleId: inputFile.absModuleId,
        sourceMap: !!(await inputFile.sourceMap),
        mainModule: inputFile.mainModule,
        imported: inputFile.imported,
        alias: inputFile.alias,
        lazy: inputFile.lazy,
        bare: inputFile.bare,
      };
    })
  )
}));
const cacheKeySuffix = sha1(JSON.stringify({
  LINKER_CACHE_SALT,
  fileHashes
}));

This snippet shows that for each JavaScript file processed, the function executes:

Multiple await operations to access properties like hash and sourceMap
Conversions to JSON (via JSON.stringify)
Multiple SHA-1 hash calculations
Promise operations that occur for each file individually

The impact of this code is significant because it is executed for each JavaScript file in each module/package, becoming a serious bottleneck in larger applications with many files. Each call of this function processes all files again to generate cache keys, even when most files haven't changed.

This is an area where focused optimization could bring significant benefits.

Conclusion

While Meteor's built-in profiling system offers a more practical solution for performance analysis, native CPU profiling based on Node.js Inspector provides deeper and more detailed insights into your application's build performance. By combining both approaches, Meteor developers can identify and solve performance problems with unprecedented precision.

Try these techniques in your next performance debugging session and see how CPU profiling can transform your approach to optimizing Meteor applications.

Unlocking Meteor 3.2: New Profiling Tool to Track Bundler Performance and Size

Nacho Codoñer — Thu, 20 Mar 2025 16:37:38 +0000

Meteor continues to evolve. After focusing on improving runtime performance, the latest update, Meteor 3.2, pivots toward bundler performance and optimizing the developer experience.

With Meteor 3.2, we introduced profiling. We revisited the old implementation to restore functionality and added meteor profile for automatic analysis of the app build process. This tool helps you track critical data like build phase timings and bundle sizes, which are key for optimizing performance and reducing build times.

This marks the beginning of exciting improvements to Meteor’s bundler, as we integrate modern solutions while maintaining Meteor’s performance and developer-friendly experience. Whether you’re working on a private project or contributing to the Meteor core, the new meteor profile tool is here to help you monitor and optimize the app’s build process.

Getting Started: A Quick Hands-On

Ready to dive in? To start using the new profiling tool, ensure your app is on Meteor 3.2 (or create a new one).

Update Your App

# Update your existing Meteor app to version 3.2
meteor update --release 3.2

Create a New App

# Create a new Meteor app using Meteor 3.2
meteor create meteorite-app --release 3.2

Profiling Your App’s Development Process

The key to Meteor 3.2's new profiling feature is the meteor profile command. Here’s how you can run it:

meteor profile [<meteor-run-options>...]

This command tracks the time taken across various phases of running your Meteor app, capturing insights that will help you fine-tune performance.

Here’s a Breakdown of the Profiling Phases:

Cold Start: This is the first run of your app, when no data is cached in the .meteor/local folder. (Use meteor reset to simulate this phase.)
Cache Start: The second run, where the app leverages cached data, improving startup speed.
Rebuild Client: When you change client-side code, this phase measures the time required to rebuild the client-side app.
Rebuild Server: Similar to the client rebuild, but this tracks the time to rebuild the server-side code.

With these key phases, you can easily track how your app’s performance changes as you make updates.

Here’s an example output from the small-sized Meteor React example, to see what it looks like in action:

A detailed log is generated during profiling, which you’ll find in the logs folder. This log contains full meteor run and METEOR_PROFILE output for each phase. Feel free to adjust the METEOR_PROFILE environment variable to suit your needs. For more options, run meteor profile --help.

Profiling Your App’s Size

The meteor profile command can also help you track bundle sizes. Run:

meteor profile --size-only [<meteor-run-options>...]

This command provides a breakdown of the package sizes across different bundlers, such as Meteor Modern, Legacy, and Cordova, helping you identify optimization opportunities. You’ll see the results in a neat table format, making it easy to spot potential issues.

If you want to include bundle size analysis as part of a full profiling session, simply add the --size option.

Tip: Exclude Architectures for a Faster Dev Experience

Here’s a quick tip to improve your development speed. If you’re not targeting legacy browsers or Cordova, you can exclude those architectures to speed up builds.

For example, compare the default behavior with excluding certain architectures:

# 1) `meteor run`
meteor profile

# 2) `meteor run` excluding certain archs
meteor profile --exclude-archs web.browser.legacy,web.cordova

The output comparison for the small-sized Meteor React example is shown below.

The impact will be much greater on large, full-featured apps. By excluding legacy and Cordova builds, you can see reduction in build times, especially when restarting Meteor apps ("Build App" stage in profile). These architectures are useful for testing older browsers or building for Cordova, but they’re often unnecessary during regular development, especially if you’re targeting modern browsers or platforms.

What’s Next for Meteor and Beyond?

Meteor 3.2 sets the stage for future improvements. The new meteor profile command helps ensure performance gains or size reductions without regressions. Automated profiling replaces subjective assessments with data-driven releases, now available to all Meteor developers.

Upcoming improvements to the Meteor bundler include:

SWC Support: We’re working on integrating SWC for enhanced compilation and analysis capabilities.
CPU Profiling and Memory Snapshots: This will allow for deeper performance tuning across all phases of app building.
Modern Bundler Integration: Expect improved bundler features and faster speeds with the adoption of modern bundlers.
Default Modern Architecture: Soon, Meteor will build only for modern architecture by default, skipping legacy and Cordova builds unless you specify otherwise.

These improvements will help keep Meteor aligned with current standards on the bundler side while improving performance and developer experience.

What Else Is New in Meteor 3.2?

Meteor 3.2 brings more than just new profiling tools. Want to explore further?

Join the Conversation

Watch the Discussion

Join the Meteor Renaissance!

Meteor 3.2 brings a new era of profiling tools, allowing developers to monitor app performance and bundle size like never before. With these updates, you’ll have the insights needed to optimize your app’s performance with data-driven decisions.

We’re excited about what’s to come and can’t wait for you to join the Meteor renaissance!

For feedback, questions, or support, visit our forums or join our Discord channel.

Stay tuned, and as always, happy coding! ☄️

The Meteor 3.0 Migration: A Space Exploration Mission

Harry Adel — Tue, 18 Mar 2025 16:05:29 +0000

Just wanted to share this story of how we completed our Meteor 3.0 migration at my company medbeauty and how more than a year's worth of effort is coming to an end with a PR of 439 file changes about to be merged 🤞

Mission Briefing: The Launch Preparation

A little background on the application: it was started in 2014. In my humble opinion, it's one of the last OG Meteor fortresses as it still utilizes Blaze & Cordova. Full-stack reactivity all the way thanks to collection-helpers. It's about as OG as you can get.

Liftoff: Initial Trajectory Calculations

The team at medbeauty had already dipped their toes in the 3.0 waters as their migration efforts began in 2023 while I joined them late January 2024. They had migrated lots of bits to async. Even DanielDornhardt had created a magnificent babel-plugin (which isn't getting the credit it deserves, by the way) to help keep your Blaze code looking nice while migrating it to async.

Since I had already been involved in the Meteor community, I had been getting notifications in my email with the PRs that were popping up here and there, but didn't see anything materialize. The core team was hammering away at the core packages, but no love was being shown to Atmosphere packages. After all, a framework is only as good as its surrounding ecosystem—no wonder people were ditching Blaze for React!

I was already skeptical of such an endeavor and didn't even know if it was feasible. So I started with what I know best: Collection2!

The Launch Sequence: Igniting Collection2

I believe Collection2 is one of those very few packages that act as a cornerstone for the entire Meteor framework. If these packages could be made async-friendly, then the rest would surely follow.

A little side trivia: I never anticipated nor vowed to undertake maintaining Collection2. Back when MCP was just getting started, I created an issue suggesting including the package in the roster due to its importance and the fact that Eric/Aldeed had already moved beyond Meteor. Once the package was moved, I was surprised that StorytellerCZ granted me maintainer access. In hindsight, it was a great decision ;)

Back to Collection2, work had already started thanks to Klablink—big shoutout to him as he helped with many packages. I started a PR building on his work and went from there. Bit by bit, I began to understand the changes made and even tried to improve it and cut down on the code changes. This was also the first time in my life where I had released a beta version of Meteor packages (I didn't know if it was even possible, but hey, we keep on learning).

I kept modifying code & releasing betas, then modifying the package in our application to see if anything would break. Also, Andrei/alisnic came to the rescue. With 2400 unit tests and 821 e2e test cases, surely I didn't break anything, right?

After a couple of hiccups and many commits, we made it! 4.0.0 was released, affirming the possibility of not only migrating Meteor packages—but in my own eyes—Meteor and Meteor projects as a whole.

Entering Orbit: Community Navigation Challenges

This experience had not only proven the possibility but also revealed the amount of work that awaited us. It highlighted a problem with the coordination of the community because I had seen people not only replicating work but also migrating silently or forking packages entirely! Which could bring an end to this unborn endeavor entirely!

That's why after brief discussions with Daniel, we came up with the idea to document the packages that needed to be migrated and their current status. This eventually led to the birth of this forum article.

The forum post helped to showcase who was working on what and gave a sense of how things were moving. While I had hoped for more widespread community participation to distribute the workload, the reality was that the effort largely fell to a dedicated group of familiar faces along with a few new contributors. When I shared my thoughts with alimgafar about wanting more community involvement, he offered a perspective that resonated with me: "that's how open source™ works" – a small group of passionate contributors often carries the weight of major transitions.

Needless to say, medbeauty & Daniel were both gracious with their time and monetary support. At one point, Daniel even instructed me to take a pause and create PRs for the packages that we had migrated so others could benefit.

Gravitational Anomalies: Deployment Mysteries

As we migrated more and more packages and made significant improvements to our codebase, we became increasingly confident in our ability to increase the version number.

One of the most intriguing things that stood out to me during this phase was that we ran into troubles when we tried building and deploying our Meteor application. The problem had already been reported by zodern, and surprisingly, we were the third to comment on it!

By that time, I had read countless articles here on the forums about how people had migrated to the lush green 3.0 lands, yet I was left puzzled. If so many teams had successfully made the journey, I wondered why more weren't encountering this deployment issue. I began to question whether there was a difference between production-grade applications with paying customers versus smaller projects with less complex requirements. The contrast between reported experiences and our own challenges made me curious about what we might be missing.

Course Corrections: Navigation Adjustments

Migrating packages was no easy task. At times, we had to make course corrections and prioritize getting things working instead of getting things right.

I had to make adjustments and make the best of the current situation, which is why I opted to still use node-sass in fourseven:scss instead of switching to leonardoventurini:scss. I had recommended forking and modifying a core package just to make things work.

But this experience didn't come easily. I had burned weeks on end trying to perfect the packages we're using. I had to freeze a version of collection-hooks that's compatible with our code. I commented out pieces of code that utilized autoValue, which still is in the works. And I think that's the moral of the story I want to drive home: it takes time, there's no perfect flight path, and you have to make some navigational adjustments.

Thankfully, many commits later, our application is stable and deployed to production, but there's still remaining work for us as we're still facing problems with Cordova. We're currently considering our options of soliciting outside help, so maybe there will be a part 2?

Mission Data: Exploration Statistics

Did you like my storytelling talents? Call me StorytellerEG — because clearly the pyramids make for better storytelling backdrops than Prague Castle!

Now time for some fun mission statistics for those interested:

A picture is worth 1000 words:

250 commits (tens of them were trying to re-run the CI actually)
439 changed files (200 forked packages?)
2 Conversations (I'm a man of few words)

By the way, we had started and closed multiple PRs in the hopes of merging 3.0, so this is probably the 3rd clone with plenty of merged/squashed commits with multiple mini-PRs already merged in, so the amount of code we changed is larger than what's mentioned in this image.

Mission Control's Transmission: Guidance for Future Explorers

Since I grew a single grey hair during this migration, this warrants me transmitting wisdom to all you young space cadets out there on how to migrate your applications. So ditch your flight manuals and come listen to how seasoned astronauts do it:

Test Your Life Support Systems: Time and time again, I've been proven that if you were to boil down all of the best practices of software development, it just comes down to having tests. If you don't have a robust test suite with plenty of coverage, then you might want to start investing in it immediately. Otherwise, suck to be you, sorry 🤷‍♂️

Don't Jump to Warp Speed Immediately: Don't kick off your application by pumping it to 3.0 like I did. I thought, "Hey, I'd just increase the version number and go from there fixing errors bit by bit and getting it working." WRONG!

Again, I learned this the hard way. I tried and failed, or better yet, didn't even get to try because as I attempted to run meteor update --release 3.x, it crashed with the following error:

MINISAT-out: Cannot enlarge memory arrays. Either (1) compile with -s TOTAL_MEMORY=X with X higher than the current value 67108864, (2) compile with ALLOW_MEMORY_GROWTH which adjusts the size at runtime but prevents some optimizations, or (3) set Module.TOTAL_MEMORY before the program runs.
MINISAT-err: Cannot enlarge memory arrays. Either (1) compile with -s TOTAL_MEMORY=X with X higher than the current value 67108864, (2) compile with ALLOW_MEMORY_GROWTH which adjusts the size at runtime but prevents some optimizations, or (3) set Module.TOTAL_MEMORY before the program runs.
abort() at Error                              
    at jsStackTrace (packages/logic-solver.js:21:18626)
    at stackTrace (packages/logic-solver.js:21:18809)
    at abort (packages/logic-solver.js:51:28956)
    at enlargeMemory (packages/logic-solver.js:21:19142)
    at Function.dynamicAlloc [as alloc] (packages/logic-solver.js:21:7927)
    at _sbrk (packages/logic-solver.js:21:58803)
    at Sd (packages/logic-solver.js:25:98389)
    at Ud (packages/logic-solver.js:25:109800)

This is what pushed me into dissecting this into small pieces and starting this whole 3.0 libraries migration thread.

Install Your Warning System: Enable the WARN_WHEN_USING_OLD_API env variable. It's a little env variable that got added during 2.12 but didn't get much attention. Enabling it should be your first pre-flight check.
Gradual Engine Upgrades: Once you've enabled it, slowly start migrating all of your old DB calls to async.
Replace Components Methodically: As you're doing the previous step, you might need to start swapping out the old Meteor packages with the new ones. Act accordingly and, most importantly, patiently. You don't want to introduce too many changes at once; that's how you crash your spacecraft. Don't ask how I know.
Multiple Small Launches Beat One Big One: Introduce changes in small, separate PRs as much as you can. We migrated all our packages and DB calls before launching into the final frontier—err, 3.0, I mean.
Share Your Flight Log: Share your experience and stay in touch. It helped me immensely that I was cross-referencing many ideas with the community and reporting any issues back to mission control. In a way, this article is part of this migration journey so we can collectively learn and elevate each other.

Mission Accomplished: Return to Earth

After more than a year of work, our Meteor 3.0 migration is complete and running in production. This achievement wouldn't have been possible without the support of the open source community.

Special thanks to Klablink, bhunjadi, alisnic, bratelefant, vparpoil, leonardoventurini, dr-dimitru, and paulishca who contributed critical components to this ecosystem-wide effort. I apologize if I forgot any names.

If you'd like help migrating to 3.0 or generally would like to connect and chat about your own space mission, I've set up a cal account.

Migrating to Meteor 3: a solo developer story

Dominic Thwaites — Thu, 13 Mar 2025 18:25:48 +0000

Introduction

My Meteor 3 conversion story starts October 2023 and ends Spring 2025.

Apart from achieving future-proofness with Meteor 3, the upgrade has also caused/motivated me to:

Upgrade all 3rd party libraries to latest versions
Establish unit tests for all methods and subscriptions that perform basic sanity and security checks on all of them
Make other changes that generally improve reliability, performance, standardisations and code clarity

So while it's been a lot of work, it's been worth it!

About me

I'm a semi-retired IT professional who used to work in the banking industry building real-time trading systems. Things are different now, but back in the day, reactivity was rare in applications and our systems in banking were all home grown reactive applications (we're talking 20+ years ago). I've always been intrigued about how to build systems that reflected their data state seamlessly & continuously. Anyway, I left banking a while ago and consulted for the most part. I'm an active squash player at my local club and wasn't impressed with the systems available to manage the processes involved for members and the club, so I started to build ManageMyMatch in 2017 having identified Meteor as an interesting framework to work with. And so my Meteor journey began...

The app

The app is a club management system for racquet sports (Squash, Tennis etc). Size-wise we have:

730 Template files
1,500 JS files
115,000 JS source code lines

Having completed the conversion we have 3,236 Meteor async calls:

1,500 findOneAsync()
320 fetchAsync()
64 insertAsync()
836 updateAsync()
75 removeAsync()
47 forEachAsync()
294 mapAsync()
96 countAsync()
4 observeAsync()

Client/server interface

519 Meteor methods
206 publications

My app uses Blaze as well as dozens of 3rd party packages some of which required custom upgrade to get them to work again.

Summary & general approach

It took about 8 months of solid work to complete. Half of that is testing. We're still not done with testing actually - but we are in user acceptance stage now. There were two phases to the plan (about 4 man-months each):

Pre-meteor 3 upgrade

Convert all relevant functions to async
Build unit tests for every meteor method & publication

Post-meteor 3 upgrade

Remove, re-install & upgrade all 3rd party packages to latest versions
Get the client app back up and running
Perform integration testing
Perform user acceptance testing
Rollout & re-issue iOS & Android apps

Pre-meteor 3 upgrade

Async conversion

I did initially use a codemon to start the process but it rapidly became clear that the impact of asyncing had to be dealt with by hand in every file. So it was a long trawl. Every change meant iterating up the function call tree to async functions were necessary. In doing so there were two main categories of issues:

Isomorphic code

I have lots of isomorphic code (runs on client and server) and ending up with async template helpers is far from ideal. I needed to minimise the amount of async that ended up in the client. I generally had these scenarios:

Collection helpers: (I use dburles:collection-helpers) I ended up creating two versions where necessary. Collection.helperXyzAsync() declared in a server folder so the server would use that and Collection.helperXyz() declared in a client folder so the client would use that.
I stubbed out many meteor methods preventing them from running optimistically on the client and then imported the files that contained async methods at the top of the method function. This process allowed me to audit and refactor what really needed to be isomorphic and has reduced my client footprint
In the same vein, I audited and segregated dozens of general helper functions for server or client use.
In some instances, where I had a pseudo package of isomorphic functionality, I restructured things to encapsulate the async requirement into one initialiser (essentially an async init() method on a class that encapsulated the functionality). Performance was improved as a happy side product.

JS iterators

In many, many cases, I needed to put async inside standard JS iterators like forEach(), map(), find(), filter(). You can't do that as the function itself doesn't magically become async if the iterator function is async. In every case, I had to refactor:

I have pretty much deprecated the use of forEach() in favour of for (value of array) {...}.
For map(), you could wrap it with Promise.all(), so let result=a.map(item => fn(item)) becomes let result=Promise.all(a.map(async item => fn(item))). For larger arrays though, I tended to iterate using for...of and pushed each result into a predefined result array
For find() I replaced it with for...of and setting an external variable with the found result and breaking out
For filter() I went for...of route as per map() though I have done this sometimes: let result=a.filter(item =>!!fn(item)) became let result=_.compact(Promise.all(a.map(async item => await fn(item) ? item : null)))

Unit testing

When I started this project I was full of good intentions and wrote some tests. Didn't last long. And, to be honest, I've not regretted it as I am pretty diligent with making sure that what I write works. Bugs exist, of course, but it's not perceived as any kind of issue by my users. But I could have used them for this migration. So I really felt like I needed to thoroughly test my methods and publications having made material changes to pretty much every single one. Besides, my async conversion efforts above had, for various reasons, left my app unrunnable. In order to get decent coverage the data setup requirement was challenging. I've ended up with different approaches for my publication unit tests and my method unit tests.

As a result I have thousands of sanity & security tests that cover about 90% of all server code and most isomorphic code. And I could now prove the sanity of my conversion work before I could get the app back up and running.

At first the process of building up the tests was slow as I iterated and improved the auto-generation processes and testing framework. By the end it's all very self generating and it's now very simple (mostly just one line of code) to set a test in place for new subscriptions or methods - so even I might keep up with that.

Publication testing

Using dburles:factory and by calling relevant meteor methods in my app, I built up a variety of different data models that I could instantiate prior to a batch of tests. The database consists of around 50 collections some of which have deeply nested document structures. These needed to be richly instantiated for the publication tests to be meaningful. I used coverage tools to check that I was running most of the code - I achieved about 90% on average. My publications are grouped in about 25 files so I have a test file matching each. I have a common procedure to run several tests per publication that includes:

Anonymous access
Unauthorised access
Authorised access
Bad parameters
No parameters
Good parameters

This standardisation has ensured I have a consistent security policy for each and every one. For each publication I encode the expected results in terms of what collections are expected to be returned, how many documents in each and how many properties on those documents are expected. They do not check any more semantics than that or other data content. The key aim is to "sanity" check them and get code coverage.

Method testing

The database seeding I had for publications was not enough for methods. So I developed a new strategy. All my collections are fully "documented" using aldeed:simple-schema. I have also augmented SimpleSchema to allow me to annotate foreign keys. So I know what collection every foreign key points to. The parameters to my methods are also documented with SimpleSchema in the same way (foreign keys are identified). With this, I can inspect the schema and auto-generate all documents inferred from the parameters as well as any documents I know the method would expect. Surprisingly this automatically achieves sufficient seeding to attain my 90% coverage target. As with publications, I have coded the generation of the tests to include similar scenarios as listed for publication above.

Sample documents are auto generated for every test. For example if my method has the parameter {matchId: 'osHdQsYsrvKYzqcBn'} the test knows this points to my Matches collection and, using the schema, generates a sample Match document. In turn the Match document has several id's that reference documents in other collections. Again, SimpleSchema tells me what collections they are and so I can generate sample documents for those too. And so on. Thus a complete network of documents is self-prepared for the method function to work on. I have special configuration properties that allow me to easily override and specify specific values for certain document properties (otherwise, values are generated that conform to the SimpleSchema type and definitions) in order to emulate certain scenarios to boost coverage. I can also instruct the test to auto generate other documents as needed. The downside is that this data seeding happens for every individual test and there are thousands of them so the whole test run takes about 15 minutes!

I use mdg:validated-method and whilst the validate() function simply checks the syntax of the parameters passed I have an internal, custom validator that is called in every method that also checks on security access and even the validity of foreign keys passed. As a convenience, incidentally, this internal validator returns the documents associated with any foreign keys passed - and most of my methods involve the submission of at least one id field.

Post Meteor upgrade

With my app completely disabled, but with all the conversion and refactoring supposedly done it was time to upgrade to Meteor 3. Which of course didn't work as my dependencies were totally shot. So I made careful notes of my packages and removed every one of them (at least all the non standard Meteor ones). Eventually Meteor allowed me to upgrade.

Next I started the process of reinstalling all my packages. Many of them didn't work and some of them had breaking changes which necessitated more changes to my code. Others I had to investigate alternatives for. So it took a while to put back together. The biggest of these was aldeed:simple-schema where I went from version 1 to 2. I have hundreds of schema definitions and they all had to be refactored. I've also ended up having to fork more packages to make dependency adjustments and/or code changes to get them to work with Meteor 3.

Package upgrade inventory

Here are all the packages (except for ones I wrote myself for the project). I had forked a few before for functional reasons, but I've had to fork quite a few more now...

What I had before	What I have now	Action or Issues
meteor-base@1.5.1	meteor-base@1.5.2	Updated
mobile-experience@1.1.0	mobile-experience@1.1.2	Updated
mongo@1.16.7	mongo@2.1.0	Updated
blaze-html-templates@1.2.1	blaze-html-templates@3.0.0	Updated
reactive-var@1.0.12	reactive-var@1.0.13	Updated
jquery@1.11.10	jquery@3.0.2!	Updated
tracker@1.3.2	tracker@1.3.4	Updated
standard-minifier-css@1.9.2	standard-minifier-css@1.9.3	Updated
standard-minifier-js@2.8.1	standard-minifier-js@3.0.0	Updated
es5-shim@4.8.0	es5-shim@4.8.1	Updated
ecmascript@0.16.7	ecmascript@0.16.10	Updated
momentjs:moment@2.29.3	momentjs:moment@2.30.1	Updated
underscore@1.0.13	underscore@1.6.4	Updated
mdg:validated-method@1.3.0	mdg:validated-method@1.3.0	Same
dburles:collection-helpers@2.0.0	dburles:collection-helpers@2.0.0	Same
mdg:validation-error@0.5.1	mdg:validation-error@0.5.1	Same
check@1.3.2	check@1.4.4	Updated
ddp-rate-limiter@1.2.0	ddp-rate-limiter@1.2.2	Updated
email@2.2.5	email@3.1.2	Updated
reactive-dict@1.3.1	reactive-dict@1.3.2	Updated
dburles:factory@1.5.0	dburles:factory@1.5.0	Same
anti:fake@0.4.1	anti:fake@0.4.1	Same
velocity:meteor-stubs@1.1.1	velocity:meteor-stubs@1.1.1	Same
random@1.2.1	random@1.2.2	Updated
shell-server@0.5.0	shell-server@0.6.1	Updated
sacha:spin@2.3.1	sacha:spin@2.3.1	Same
session@1.2.1	session@1.2.2	Updated
tinytest@1.2.2	tinytest@1.3.1	Updated
oauth2@1.3.2	oauth2@1.3.3	Updated
jparker:crypto-md5@0.1.1	jparker:crypto-md5@0.1.1	Same
base64@1.0.12	base64@1.0.13	Updated
dynamic-import@0.7.3	dynamic-import@0.7.4	Updated
server-render@0.4.1	server-render@0.4.2	Updated
service-configuration@1.3.1	service-configuration@1.3.5	Updated
blaze-hot@1.1.1	blaze-hot@2.0.0	Updated
hot-module-replacement@0.5.3	hot-module-replacement@0.5.4	Updated
autoupdate@1.8.0	autoupdate@2.0.0	Updated
meteortesting:mocha@2.1.0	meteortesting:mocha@3.2.0	Updated
accounts-base@2.2.8	accounts-base@3.0.4	Updated
accounts-facebook@1.3.3	accounts-facebook@1.3.4	Updated
accounts-google@1.4.0	accounts-google@1.4.1	Updated
accounts-password@2.3.4	accounts-password@3.0.3	Updated
accounts-ui@1.4.2	accounts-ui@1.4.3	Updated
tap:i18n@1.8.2	tap:i18n@2.0.1	Forked - dependencies changed
percolate:momentum@0.7.2	percolate:momentum@0.7.3	Forked - dependencies changed
aldeed:collection2@2.10.0	aldeed:collection2@4.0.3	Updated
quave:accounts-apple@3.0.0	quave:accounts-apple@4.0.0	Updated
aldeed:autoform@5.8.1	aldeed:autoform@8.0.0-rc.4	Required application changes
aldeed:simple-schema@1.5.4	aldeed:simple-schema@2.0.0	Required extensive application changes
	softwarerero:accounts-t9n@2.6.0	New
	useraccounts:core@1.17.2	New
	lmieulet:meteor-coverage@5.0.0	New
johanbrook:publication-collector@1.1.0	johanbrook:publication-collector@1.1.0	Forked - functional fix & dependencies changed
gwendall:autoform-i18n@0.1.9_2	gwendall:autoform-i18n@0.1.9_2	Forked - dependencies changed
bozhao:link-accounts@2.8.0	bozhao:link-accounts@3.0.1	Updated
tmeasday:publish-counts@0.8.0	compat:publish-counts@1.0.0	Replaced
splendido:accounts-emails-field@1.2.0	splendido:accounts-emails-field@1.2.0	Forked - needed asyncing
cultofcoders:persistent-session@0.4.5	itgenio:persistent-session@0.4.12	Replaced, forked - dependencies changed
rocketchat:oauth2-server@2.1.0	rocketchat:oauth2-server@2.1.0	Forked - needed asyncing and dependencies changed
useraccounts:bootstrap@1.14.2	useraccounts:bootstrap@1.15.3	Updated
reywood:bootstrap3-sass@3.3.5_1	reywood:bootstrap3-sass@3.3.7_1	Forked - dependencies change
	communitypackages:autoform-bootstrap3@2.0.0	New
markdown1.0.12	markdown@2.0.0	Updated
aldeed:autoform-bs-datepicker@1.2.0	aldeed:autoform-bs-datepicker@2.0.0	Forked - dependencies changed
rajit:bootstrap3-datepicker@1.7.1_1	rajit:bootstrap3-datepicker@1.7.1_1	Same
tsega:bootstrap3-datetimepicker@4.17.47	tsega:bootstrap3-datetimepicker@4.17.47	Same
kadira:flow-router	ostrio:flow-router-extra@3.11.0-rc300.1	Forked - needed coffescript dependencies change and a functional fix
useraccounts:flow-routing@2.12.1	useraccounts:flow-routing-extra@1.1.0	Replaced
kadira:blaze-layout@2.3.0	kadira:blaze-layout@2.3.0	Forked - dependency change
fourseven:scss@4.15.0	fourseven:scss@4.17.0-rc.0	Needed: brew install python@3.11
aldeed:template-extension@4.1.0	aldeed:template-extension@4.1.0	Forked - dependency changed
arillo:flow-router-helpers		Removed
xolvio:cleaner		Removed
hwilson:stub-collections		Removed
simple:reactive-method		Removed
autoform-markdown		Removed
http		Removed - use fetch now
jkeuster:http		Removed - use fetch now
facebook-config-ui		Removed
facebook-oauth		Removed
quave:apple-oauth		Removed
google-config-ui		Removed
meteorhacks:picker		Removed - now using webapp
practicalmeteor:chai		Removed
practicalmeteor:sinon		Removed
meteorhacks:zones		Removed
dispatch:mocha		Removed
fetch		Removed - now using npm package

Getting the app to work again

Once I got the build working I fired up the browser to see what happened. It didn't work, of course. So I had a period of a few weeks where I was wholesale fixing and refactoring throughout the app to the point where I eventually had the app basically able to operate but still with many bugs and issues. There was much work in upgrading the client for the following reasons, though the process did involve a lot of server-side fixing now that I was using the app for real (remember the automated tests are security and sanity checks - they don't achieve real-world semantic or scenario testing):

aldeed:simple-schema upgrade

I use schemas to check the data passed into my templates. I have a lot of templates - 732 of them and most of them take some kind of data. So all my template simple-schemas had to be upgraded. At the same time I took the opportunity to better standardise on this practice.

async functions

Despite minimising the bubbling up of async functions having to be dealt with by the client, there's still lots of them. Sometimes they are innocuous as the new Blaze does a good job of resolving them. But other times action has to be taken. Here's two examples:

If I have {{> nestedTemplate data=getAsyncHelperValue}} in my blaze template, poor old nestedTemplate receives a promise. No good. So I'd generally change this to:

{{#let asyncHelperValue=getAsyncHelperValue}}
    {{#if @resolved "asyncHelperValue"}}
        {{> nestedTemplate data=asyncHelperValue}}
    {{/if}}
{{/let}}

Another issue was the loss of reactivity within an async function - so my UI did not update as expected. You lose reactivity after the first await inside an async reactive function. Often I could resolve the issue just be ensuring the reactivity that was really important was as a result of the first await in the function. But sometimes I needed reactivity based on more than one reactive source change. I then had to resort to using Tracker.withComputation that restores reactivity after losing it from the first await. Truth be told, I thought this was going to be a major problem for my app. But it turns out there were relatively few instances where I had to use Tracker.withComputation.

method calls

My method calls in the client would generally follow this pattern, using mdg:validated-method:
myMethod.call(params,(error,result) => error ? showError(error) : process(result))

Often I do not need to process any result so that becomes simply
myMethod.call(params,showError)

showError() is my ubiquitous "Oops, sorry, something went wrong" message to the user.

I wanted to keep this pattern because I have 801 method calls. But I needed to use the callAsync() method on mdg:validated-method because all my methods were now async and that would mean changing the pattern and having to async my functions. So I implemented a new method on this class called 'callSync()' that went as follows:

ValidatedMethod.prototype.callSync=async function(parameter,callback) {
    if (_.isFunction(parameter)) {
        callback=parameter;
        parameter=undefined;
    }
    try {
        let result=await this.callAsync(parameter);
        if (_.isFunction(callback)) callback(null,result);
    } catch (error) {
        if (_.isFunction(callback)) callback(error);
    }
};

Then it was just a matter of replacing all method.call() invocations into method.callSync() invocations.

Integration testing

Having reached the point where wholesale changes seemed to be a thing of the past, I now needed to touch every part of the functional app. It's a big system. Hundreds of different screens and functionalities and combinations. I installed and built a few tests with Cypress, but I soon realised that it would take me a decade to set up enough tests in cypress (with good seeded data) to make them meaningful. So I ditched that and went manual. Instead I used Dynalist to quickly and easily (it's very good) build a deep nested structure (using several separate files) that reflected full navigation paths throughout the app. This allowed me to at least record what needed to be tested and introduced the discipline to reach every part of the app. It was no good testing the 10% of the app that was used 90% of the time since every single bit was subject to change and risked not working. So I had to test the 90% of the app that was used only 10% of the time. Though the former did receive greater attention.

The app has many points of integration to the outside world and these too needed to be included in the test plan. This included:

Private API - I expose my methods and publications through a REST interface which is used externally. Mainly AWS Lambda functions as well as an AWS API implementation that exposes a limited public API to the system
Social logins and management - Facebook, Google & Apple
Integrations with Stripe, Doorflow (a security system), EposNow (a PoS system) and Mailchimp
OAuth2 flows - with external systems as well as the apps own OAuth2 service.
Communications to networked devices (SNMP)
Webhooks

It was always satisfying to find a bug that was already there from before and fixing that - I found quite a few! Who knows, the new version might have less bugs than the old by the time it goes live!

User acceptance testing

This consists of two phases; Alpha and Beta. The fact that the database has not changed and that testing so far gives us confidence that the new app won't corrupt the database is a huge benefit allowing us to test the new app in a live environment. In doing so we can compare and contrast screens and behaviour between the production site and the test site at all times. There have been minimal visible changes so the screens should match precisely making it easy to spot unexpected differences in behaviour. The test version has hotjar installed making it easy for users to provide feedback and for us to track behaviour

Alpha testing

I deploy the app (to Galaxy) with an alpha subdomain so that my internal team can use the new app against the production database. This phase lasts 1 month where we can root out many of the remaining issues whilst using the system for real.

Beta testing

I deploy the app with a beta subdomain and widen out its use by inviting friendly customers and users to use the new system. This phase may last 1 or 2 months, depending on how it goes, for further opportunities to find bugs while the system is used by people of different roles.

Rollout and re-issue of iOS & Android apps

This is the final stage of the project. The production domain is upgraded to the new app at the same time as we deploy compatible new versions of the iOS and Android apps. It's normally a bit of a battle to get the apps building, sadly.

Conclusion

At first the task seemed daunting. But even then I'm not sure I realised just how much work was involved. But as with any project, it was a matter of breaking it down and building lists of what had to be done in an orderly fashion. And then tracking progress on each task and seeing that progress slowly reach 100% complete. Take the unit tests for the meteor methods for example. There are 519 of them. Every one needed a test. Some days I'd get dozens done. Other days only a few. But sooner or later I knew that 100% would arrive! We are now in a much better place, technologically, than before and this upgrade has forced us to use where possible all the latest packages and components as well as having established reasonably comprehensive test harnesses and procedures.

While it's been a lot of work for me, I know it's been many times more for others without whose work this could not have been achieved. So thanks as ever to the Meteor team and the community for making it possible!

I now look forward to many more years of happy Meteoring.

How We Scaled Meteor to Handle 30,000 Concurrent Users at Propiedata

Paulo Mogollon — Mon, 24 Feb 2025 18:24:43 +0000

Scaling Meteor is both an art and a science.

At Propiedata, a property management platform with features like virtual assemblies, dashboards, and real-time voting, chat, reactions and participation queues, we successfully scaled our app to handle peaks of 30,000 concurrent users. Here's how we did it and the lessons learned along the way.

1. Favor Methods Over Publications

Meteor's publications can be expensive in terms of server and database resources. While powerful, they aren't always necessary for all types of data. Switching to methods:

Reduces load on your servers.
Improves response times.
Performance is more stable and dependable.
Optimizes performance for complex queries.
Methods can be easily cached.

What did we fetch with methods?

Everything! We just subscribed to data that required real-time information like poll results, chats, assembly state and participation queues.

2. Optimize MongoDB Schemas and Queries

Efficient database queries are the backbone of scaling any app.
Here's what worked for us:

Indexes: Use compound indexes tailored to how your data is queried.
Selective Fields: Only retrieve the fields you need.
Avoid Regex: Regex queries can be a performance killer.
Secondary Reads: Offload read operations to secondary replicas when possible.
Monitor Performance: Regularly check for long-running queries and eliminate n+1 issues.
Too Many Indexes: Having too many indexes can hurt your write performance.
ESR Rule: When creating an index the Equality fields go first, then Sort and at last Range, we will go deeper later.
MF3 rule: Most filtering field first, which means that in any query filter, a field that filters more should goes first.

3. Move Heavy Jobs Out of the Main App

Offloading resource-intensive tasks from the main (user facing) application reduces server load and improves the responsiveness of methods and subscriptions. Using external job queues or microservices ensures more stable and dependable performance, especially during peak times.

So what we moved off from the main app?

Bulk imports
Analytics aggregations
Real time data aggregations
PDF/HTML rendering
Batch data cleansing
Batch email sending
Puppeteer page crawling
Large data reads and documents creation

4. Implement Redis Oplog

Switching to Redis Oplog was a game-changer. It significantly reduced server load by:

Listening to specific changes through channels.
Publishing only the necessary changes. This approach minimized the overhead caused by Meteor's default oplog tailing.
Debounce requerying when processing bulk payloads.

5. Cache Frequently Used Data

Caching common queries or computationally expensive results dramatically reduces database calls and response times. This is particularly useful for read-heavy applications with repetitive queries.

We used Grapher so that made it easy to cache data in redis or memory.

Don't make the same error we did at first caching also the firewall or security section of the method calls (we did this before using Grapher).

6. Follow General MongoDB Principles

To get the most out of MongoDB:

Always use compound indexes.
Ensure every query has an index and every index is used by a query.
Filter and limit queries as much as possible.
Follow the Equality, Sort, Range (ESR) rule when creating indexes.
Prioritize the field that filters the most for the first index position.
Use TTL indexes to expire your old data.

What is the ESR rule?

The ESR Rule is a guideline for designing efficient indexes to optimize query performance. It stands for:

Equality: Fields used for exact matches (e.g., { x: 1 }) should come first in the index. These are the most selective filters and significantly narrow down the dataset early in the query process.
Sort: Fields used for sorting the results (e.g., { createdAt: -1 }) should be next in the index. This helps MongoDB avoid sorting the data in memory, which can be resource-intensive.
Range: Fields used for range queries (e.g., { $gte: 1 }) should come last in the index, as they scan broader parts of the dataset.

What is the MF3 rule?

Well, I just named it that way at the moment of writing, but this rule prioritizes fields that filter the dataset the most at the beginning of the index. Think of it as a pipeline: the more each field filters the dataset in each step, the fewer resources the query uses in the less performant parts, like range filters. By placing the most selective fields first, you optimize the query process and reduce the workload for MongoDB, especially in more resource-intensive operations like range queries.

7. Secure Your MongoDB Cluster

A critical step in scaling securely is ensuring your database is not exposed to the internet. Initially, we relied on a strong, hard-to-guess username and password for security. However, we discovered that much of our resource usage was caused by automated scripts attempting to connect to our database.

Even unsuccessful login attempts consume server resources due to hashing and cryptographic operations. When multiplied by thousands of attempts from bots or malicious scripts, this can significantly impact performance.

Solution:

Set up VPC peering: This allows your database to communicate securely with your application servers without exposing it to the public internet.
Use IP Access Lists: If you're hosting your database on platforms like MongoDB Atlas, restrict access to known IPs only.

By implementing these measures, you prevent unnecessary resource usage from brute-force attempts and enhance the overall security and performance of your application.

8. Other Key Improvements

Rate Limiting: Prevent abuse of your methods by implementing rate limits.
Collection Hooks: Be cautious with queries triggered by collection hooks or other packages.
Package Evaluation: Not every package will perfectly fit your needs - adjust or create your own solutions when necessary.
Aggregate Data Once: Pre-compute and save aggregated data to avoid repetitive calculations and queries.

9. The Result: Performance and Cost Efficiency

These optimizations led to tangible results:

Cost Reduction: Monthly savings of $2,000.
Peak Capacity: Serving 30,000 peak concurrent users for just $1,000/month.

Quick Recap

If you're looking to scale your Meteor application, here are the key takeaways:

Offload heavy jobs to external processes.
Use methods instead of publications where possible.
Optimize MongoDB queries with compound indexes and smart schema design.
Leverage Redis Oplog to minimize oplog tailing overhead.
Cache data to speed up responses.
Think "MongoDB," not "Relational."
Secure your cluster.

Almost forgot

We use AWS EBS to deploy our servers, with 4Gb memory and 2vCPUs. It's configured to autoscale, having in mind that NodeJS uses only one vCPU, memory is almost always at 1.5gb. And for MongoDB we use Atlas, this also auto scales but it has an issue, autoscaling takes about an hour to scale up when it has a heavy load, so we created a system that predicts usage given the amount of assemblies we have and scales Mongo cluster accordingly for that period.

Meteor 3.1.1 is here!

Gabs Ferreira — Tue, 04 Feb 2025 16:18:27 +0000

Meteor 3.1.1 is here! This latest patch brings performance improvements, critical fixes, and updates based on community feedback.

You can check out all that's new about his version in this video, where I had a chat with the core team:

Or just keep reading :)

Performance improvements: faster real-time processing

One of the highlights of Meteor 3.1.1 is a boost in real-time performance. Our team refactored the synchronous queue for parallel processing and optimized MongoDB observers to handle initial documents more efficiently.

Previously, Meteor 3.1 had some performance regressions when dealing with reactive flows, limiting the number of connections it could handle. This patch resolves those issues and improves Meteor 3's scalability, outperforming previous Meteor 2 versions in terms of handling more simultaneous connections.

Deprecation of Async Allow/Deny Rules

Based on community feedback, async rules have been deprecated, and the API has been streamlined to focus on just insert, update, and remove operations. Additionally, test coverage has been expanded to address edge cases identified by developers.

Introducing Meteor.deprecate

Meteor now includes a Meteor.deprecate API, which was initially designed for internal use but is now accessible to library developers. This feature allows more precise tracking of deprecated functions and API calls, helping developers transition smoothly when changes occur. Although it's not yet fully documented, advanced users can explore it in the Meteor source code.

Node.js Upgrade and Community Fixes

This version also includes an upgrade to the latest Node.js version, along with multiple community-driven fixes. The team has addressed several GitHub issues, improved the Accounts package, and implemented security updates. It also introduces fixes for Windows users, ensuring a more stable development environment across platforms.

Meteor RPC: A New Approach to API Calls

A significant addition to the Meteor ecosystem is the release of Meteor RPC, launched in December, a new package designed to streamline remote procedure calls (RPC) and enhance real-time capabilities.

This package, powered by Zod for runtime validation, brings improved TypeScript support and a more modern approach to defining and calling APIs in Meteor. It's already powering Galaxy, meaning if you're a Galaxy user, you're already benefiting from it!

If you want to explore Meteor RPC, check out the official blog post or join the conversation on Discord.

How to Migrate your MongoDB Database to Galaxy Hosting

David Amaral — Fri, 17 Jan 2025 12:53:22 +0000

Migrating a database can be quite a challenge, right?

At Galaxy, we truly understand how stressful technical tasks can be and are here to make things easier for you. Hence, we created this follow-up article to facilitate your first MongoDB database migration to our Galaxy cloud. These steps are recommended for databases up to 15GB in size and unsuitable for MongoDB clusters in sharded mode.

Please note that this procedure will have downtime. If you need to migrate a larger database or complex structure without downtime, please contact our specialists via our support chat.

Get your environment ready!

To complete this tutorial, we only need Docker, as it runs the container for all migration steps installed.

Step 1: Set Up Docker

Why Docker?

Docker simplifies migrations by running pre-configured containers, avoiding manual installations and dependencies.

Install Docker:

Download and install Docker from Docker. It’s quick and supports all major operating systems.

Step 2: Prepare Database Details

Make sure you have your connection strings from your source and destination databases. This example shows a connection string for Galaxy hosting:

mongodb://admin:passwordEncodedb@user_testcluster-01.mongodb.galaxy-cloud.io:30010,user_testcluster-02.mongodb.galaxy-cloud.io:30010,user_testcluster-03.mongodb.galaxy-cloud.io:30010/admin?replicaSet=test_replicaset

Step 3: Stop your application

We don't want inconsistent data, right?
So, at this step, we need to stop our application so that it does not write any data to our database. After a complete stop, we can proceed with the migration.

When ready, start the migration process by executing the following command:

docker run --rm –name mongo-migration-tool -d \
  -e SOURCE_URI="" \
  -e TARGET_URI="" \
  -e DB_NAME="example_db_name" \
  meteor/galaxy-mongodb-migrate:202409101534

This will start a container that will dump the source database and restore this dump in the destination database.

You can verify if the container is running by executing the command:

# docker ps | grep mongo-migration-tool

Also, you can verify the backup progress by examining the logs of this container with the command:

# docker logs mongo-migration-tool

Step 4: Verify and Secure

After it is complete, the container is stopped and removed. You can now see all the data on your destination database.

Inspect the Data:

Use tools like MongoDB Compass to confirm successful migration.

Create New Users:

Enhance security by creating dedicated database users in Galaxy.

Limitations and Recommendations

Database Size: For databases over 15GB, alternative methods may be more effective.
Sharded Mode: This process does not support sharded MongoDB configurations.

Step 4: Configure your application to your new connection string

After a successful migration, you can change your app's configuration and restart it to use the data in your database located on our Galaxy MongoDB hosting.

Wrapping Up

Migrating your MongoDB database to Galaxy Hosting is an essential step in leveraging the full potential of our reliable and scalable cloud platform.

Remember, this guide is tailored for databases up to 15GB and non-sharded configurations. If your requirements fall outside these parameters or you prefer a migration with no downtime, don’t hesitate to contact our support team using the chat button on your Galaxy account. We’re here to assist you every step of the way. Also, you can review the official Galaxy documentation for more information.

If you haven't created a Galaxy account yet, now's the perfect time to do so and you can test it out with a free plan! It allows you to effortlessly host a variety of applications, including Node and Meteor, with even more options coming soon. Don't miss out on this opportunity, create your account now!

Happy migrating!