Forem: Harry Adel

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.

Apple Sign-In using Hapijs

Harry Adel — Sat, 30 Mar 2024 13:32:01 +0000

Recently, I've been tasked with enabling Apple Sign-In using Hapijs but the content online that relates to this part is very scarce. So, I've decided to come up with my own little tutorial that connects everything together from the start to the very end.

This tutorial is split up into two parts, the first is about configuring your Apple developer account and getting the required credentials while the second part is how to use these credentials to set up the authentication flow.

Part 1

We need to attain the following credentials from Apple:

Team/App ID

Apple lets your create an application that encompasses all of your services. It might seem like an over kill but it makes sense when you've an application that has multiple fronts like web, IOS or Vision OS, you name it. It's one huge umbrella for all of your "team" needs. The biggest takeaway here is to write down the Team ID you get when you create an application and also be sure to configure it to allow Apple sign-in.

Service/Client ID

Now, we're going to create a services or a client that initiates such login attempts. As an example, I'm going to name our application "devtools" and the domain for it is "devtools.io". Apple is going to require you to provide an identifier for your service and it's customary to enter in your domain reversed, in our case "io.devtools". This is going to be our Client ID, so don't forget to write it down. Keep in mind, Apple doesn't allow entering localhost so put down any name and later in this tutorial, I'll show you to test things locally easily.

Key ID

Finally, Apple requires you to use a private key to sign your communications with it for an extra layer of protection. You're going to download a p8 file that we're going to use later on. Don't forget to write down the Key ID.

When you're done with part you should end up with the following env variables:

APPLE_CLIENTID
APPLE_TEAMID
APPLE_KEYID
APPLE_CALLBACK

And the .p8 key file.

Part 2

Before diving into the code, there're few adjustments we need to make in order to be able to run our application locally on HTTPs and to also route to the proper domain name.

Generating locally signed SSL certificates

We're going to create self signed certificates in order to be able to use them in our application and place them in a directory called certs.

openssl req -x509 -out localhost.crt -keyout localhost.key \
  -newkey rsa:2048 -nodes -sha256 \
  -subj "/CN=localhost" -extensions EXT -config <( \
   printf "[dn]\nCN=localhost\n[req]\ndistinguished_name = dn\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature\nextendedKeyUsage=serverAuth")

Host configuration

Go ahead and edit /etc/hosts so that devtools.io routes to our application.

127.0.0.1  devtools.io

In our index.js, use our locally signed certificates:

const server = Hapi.server({
  host: process.env.HOST,
  port: 443, // Default HTTPS port
  tls: {
    key: fs.readFileSync(
      path.resolve(__dirname, "certs/localhost.key"),
      "utf8"
    ),
    cert: fs.readFileSync(
      path.resolve(__dirname, "certs/localhost.crt"),
      "utf8"
    ),
  },
});

You might have to use sudo to run your application. Now fire up your browser and visit devtools.io, and you'd be met with something that looks like this:

Type in thisisunsafe in your browser so that chrome'd allow to visit the website.

Configuring Apple Strategy

The meaty part which you've been looking for. Apologies if this part is messy but it was no easy task. But I'll try to explain things to the best of my ability.

profile function is triggered after a successful authorization/token request. Because Apple is the cool company we all know and love, to verify the id_token it sends back you have to fetch a list of public keys and match it with key ID (kid) in header of the received token.

We then use jwk-to-pem to convert the public key into something jsonwebtoken can use to verify the signature.

Also, you'd find that I parse a property called credentials since I asked for the user's email and name in scope but it's something I had to monkey patch into the library.

https://github.com/hapijs/bell/pull/494

const apple = {
    auth: "https://appleid.apple.com/auth/authorize",
    token: "https://appleid.apple.com/auth/token",
    name: "apple",
    protocol: "oauth2",
    useParamsAuth: true,
    profile: async (credentials, params) => {
      const decodedToken = jwt.decode(params.id_token, { complete: true });
      const applePublicKey = await axios.get(
        `https://appleid.apple.com/auth/keys`
      );
      const rsaKey = applePublicKey.data.keys.find(
        (key) => key.kid === decodedToken.header.kid
      );

      try {
        const resp = await jwt.verify(params.id_token, jwkToPem(rsaKey), {
          algorithms: [decodedToken.header.alg],
        });

        credentials.profile = {
          id: resp.sub,
          email: JSON.parse(credentials.user).email,
          displayName: `${JSON.parse(credentials.user).name.firstName} ${
            JSON.parse(credentials.user).name.lastName
          }`,
        };
        return credentials;
      } catch (e) {
        console.log("Token verification failed");
      }
    },
  };

We finally get to use the .p8 key Apple gave us at the very beginning to sign our token.


const privateKey = fs.readFileSync(
  path.resolve(__dirname, "./secret_key/AuthKey_XSYG2M3R.p8"),
  "utf8"
);

function getSecretKey() {
  const claims = {
    iss: process.env.APPLE_TEAMID,
    iat: Math.floor(Date.now() / 1000),
    exp: Math.floor(Date.now() / 1000) + 86400 * 180,
    aud: "https://appleid.apple.com",
    sub: process.env.APPLE_CLIENTID,
  };

  let signOptions = {
    algorithm: "ES256", // you must use this algorithm, not jsonwebtoken's default
    keyid: process.env.APPLE_KEYID,
  };

  const token = jwt.sign(claims, privateKey, signOptions);

  return token;
}

server.auth.strategy("apple", "bell", {
    clientId: process.env.APPLE_CLIENTID,
    clientSecret: getSecretKey,
    provider: apple,
    forceHttps: true,
    isSecure: true,
    scope: ["email", "name"],
    providerParams: { response_mode: "form_post" },
    password: "cookie_encryption_password_secure",
    location: () => process.env.APPLE_CALLBACK,
  });

It's very crucial to add this piece of code as bell is unable to route you properly back to the application. Shout out to annahassel

const fixAppleCallbackForBell = (request, h) => {
  if (request.method === "post" && request.path === "/api/auth/apple") {
    const {
      raw: { req },
    } = request;
    let payload = "";

    return new Promise((resolve, reject) => {
      req.on("error", reject);
      req.on("data", (chunk) => {
        payload += chunk;
      });

      req.on("end", () => {
        request.setUrl(`/api/auth/apple?${payload}`);
        resolve(h.continue);
      });
    });
  }

  return h.continue;
};

server.ext("onRequest", fixAppleCallbackForBell);

That's pretty much it. Let me know if you've any questions.

This article wouldn't have been possible without the knowledge shared in these articles:

Researching and sharing knowledge in this article took quite a considerable amount of time. I'd appreciate if you can sponsor me on Github.

Genesis of a Framework: Unveiling the Meteor Story

Harry Adel — Fri, 23 Feb 2024 16:23:55 +0000

Given Meteor has been around for almost 11 years now, I think it's important to document its early beginnings and origin for the future generation of developers and there's no one better to tell us about Meteor than one of its original creators -- Geoff Schmidt!

What made me feel that this is even more important to document is the scarcity of information about Meteor initial stages illustrated by this forum thread that has resurfaced during categorization of old threads.

I've come to know about many fascinating stories of Meteor's inception through Geof Schmidt old Quora account and today I'd like to share some of the best stories about Meteor's first years.

Table of contents:
- How Meteor creators met
- Differences between Meteor and Luna
- Other possible Meteor names
- Meteor pros in the eyes of its creators
- Meteor original website design
- Conclusion

How Meteor creators met

How a little talk during a holiday party followed by a visit and an email later led to the recruitment of David Greenspan (Etherpad creator).

How did David Greenspan (Etherpad creator) team up with Geoff Schmidt (Asana employee #9, worked on Luna) and team to form Meteor?

Differences between Meteor and Luna

Probably the most intriguing fact about Meteor is that it's based on another Framework called "Luna" used at Asana and how Meteor inverts the same principle.

Web Application Frameworks: What are the differences between Meteor and Luna?

Other possible Meteor names

Ever wondered why Meteor creators chose such a name? Did you now that Polymer was one of the potential names?

Is "Meteor" (web framework) a pun on Luna or Comet?

Meteor pros in the eyes of its creators

You can ask any hardcore developer on the official Meteor forums about why you should go with Meteor and you'd get a pretty solid answer but it's always interesting to me to know what the original creators liked about Meteor and what type of problems were they attempting to solve.

In lay terms for someone with only basic software development knowledge, what is cool about Meteor?

Meteor original website design

Lastly, there's no better way to part ways but to share little trivia about the original Meteor website design.

Who designed Meteor's original website?

Conclusion

Congratulations, now you're a bit closer to understanding the awesomeness of Meteor and its lore. Hopefully

About me 👋

I'm a long time Meteor enthusiast and all around fan who likes to spread the word about Meteor and recently I had been accepted into Github sponsors program which I'd appreciate if you can donate to, thanks!

Meteor And DDP

Harry Adel — Wed, 08 Apr 2020 01:31:26 +0000

In this article we're going to talk about the core technology powering Meteor and granting us the ability to create reactive real-time applications.

DDP is an acronym for Distributed Data Protocol. Don't fall for the fancy name. It's simply a protocol that specifies how to communicate data in JSON. DDP is built using SockJS which is powerful library offering WebSocket emulation, so it'd allow for WebSocket communication in environments that doesn't support WebSockets. Also, It abstracts away all the low level stuff that goes into making WebSockets communication possible. In short, DDP is nothing but a customized version of SockJS server/client setup.

Learning about this was such a revelation for me because I finally came to understand why Meteor is nothing but a set of great tools carefully integrated together by some very smart people.

DDP supports two basic operations:

Remote Procedure Calls (RPC).
Subscribing to set a documents where the server continuously keeps the client updated about changes to these documents.

What's RPC? It's another fancy name for invoking server side operations by the client.

You can already tell how those two very basic operations can power Methods and Pub/Sub pattern of Meteor. It's something that we shall go in great detail in the future. For now, let's keep things simple.

Now, fire up a simple Meteor application.

curl https://install.meteor.com/ | sh

meteor create simple-app
cd simple-app
meteor

Open up the browser, navigate to localhost:3000. Bring up the networks tab in the web console, select WS and click on websocket then reload the page. You'd end up with something similar to the following picture.

As you can see there's a lot going on here, so I'd like to focus only on few messages here.

The first one being the "connect" message as the client attempts to establish a connection specifying the DDP version used then the server replies with "connected" and sets a unique "session". This "session" is used to differentiate clients accessing the server, so that later on Meteor can tell which message needs to sent out to what clients in later interactions.

Another delightful thing that you might notice if you leave the browser running for a while is the "ping/pong" messages. This is a heartbeat check to ensure that the connection between the server and client is maintained because if it's not the client'd try to reconnect.

As you can tell, there's a lot more to DDP than this, we've only scratched the surface. You can learn more about the specification here.

For now, keep toying with your Meteor application and witness what funny messages pop in your console for now. In the next few articles we shall go in great detail about what each message mean and how we can build better Meteor applications.

Meteor 1.9 ❤️ Node 12

Harry Adel — Thu, 09 Jan 2020 13:55:54 +0000

Meteor 1.9 is finally out! Supporting Node 12!

There're even more awesome changes which are about to hit soon like updating to Cordova 9 and MongoDB to 4.2. What a way to start 2020!

And what's even more exciting is that Meteor Meetups are slowly coming back. You can view Meteor Meetup NYC where they talk about the new roadmap and next steps.

You can join the forums to discuss the release here.

Happy new year guys!

Meteor Galaxy Roadmap

Harry Adel — Thu, 19 Dec 2019 17:00:47 +0000

Another great news hits the Meteor community: Meteor Galaxy, the official platform for hosting Meteor application, gets a news a roadmap.

The new plan features:

Autoscaling
Native app build and publish
Deploy from Git push
New Pricing Plan

They took into consideration many of the suggestions provided on the Meteor forums.

With a plan for Meteor and Galaxy one can only anticipate the awesome future that awaits us!

Meteor Roadmap Announcement

Harry Adel — Wed, 11 Dec 2019 13:35:18 +0000

A new roadmap has been released detailing the next steps for Meteor, catering to many of the community requests and most importantly encouraging everyone to participate.

The most notable features of this roadmap are:

Update to Node.js 12
Ultra-thin Meteor (Mongo-less Meteor)
Hot Module Replacement
Update Cordova to 9
Documentation updates

This announcement sets out a clear example on how the new Meteor management intends to correct past mistakes, mainly, the lack of communication.

Again, if you've a couple of minutes to spare, please take a look at the new roadmap.

Meteor 1.8.2 is out

Harry Adel — Sat, 30 Nov 2019 09:44:00 +0000

As the title suggest a new minor version of Meteor is out. The biggest update I'd like to highlight is the inclusion of typescript, which you can add to existing projects by running meteor add typescript or creating an new one with meteor create --typescript new-typescript-app.

Filipe Névola, the new Meteor evangelist, wrote a beautiful article on medium detailing the changes that I highly recommend.

I hope you have a nice day, bye!

Tiny acquires Meteor

Harry Adel — Wed, 09 Oct 2019 10:59:06 +0000

Yes, you read it correctly! Tiny just acquired Meteor couple of days ago.

For those of you who don't know it yet Meteor.js is a framework that has been around for almost 8 years and there has been lots of ups and downs. Below I'll try to get you up to speed about Meteor and what to anticipate in the near future.

Meteor primer

Meteor.js was first unveiled publicly in April 2012. In a time where most of the technologies we use today either weren't around or wasn't considered as robust, Meteor provided a streamlined experience building realtime applications in a matter of minutes with little to no configuration. It had its own template engine (Blaze), packaging system and a bundling system allowing you to ship to Android/IOS using Cordova.

Recent history

Sadly, things hasn't been going as strong for Meteor lately. Lots of new technologies started popping around. In essence Meteor has been a victim of its own success. More importantly, it didn't help out that Meteor Development Group, the company behind Meteor, decided to sidestep Meteor in favor of GraphQL and put it on life support.

Meteor had only one contributor, Ben Newman, for three years! And I must assert that he did a great job. [If one guy kept Meteor going, imagine what a team would do!]

The community wasn't thrilled about the current affair of the situation and raised this matter in a recent issue which has been culmination of increasing discontent at the situation. The morale had seen better days, though many both long-time Meteor developers and new-comers still advocate for it as an incredible prototyping tool that can get your business up in no time.

What the future holds

Honestly, I'm hyper optimistic about the future of Meteor. And I'll try to make my case as clear as possible.

Meteor gets to have a life of its own, with a company supporting it and a dedicated dev Team.
Many amazing developers of the community decided to band together and create an organization maintaining vital community Meteor packages.
Typescript has been added and the core is getting converted to it one module at a time. In general, the code is being made more accessible to have more contributors on board.
Release 1.9 is in the works to be out and it shall rock Node 12! How exciting it that?!

I humbly encourage all of you to give Meteor a try, participate in the community discussion around the acquisition, suggest new ways to improve Meteor, and maybe say hi in the community organization slack channel!

Big shout out to David Panart and Jan Dvorak for proof-reading and providing suggestion.