Forem: Jan Küster 🔥

I'm frozen and I cannot move

Jan Küster 🔥 — Fri, 13 Mar 2026 15:44:02 +0000

This text is 100% handmade, like the code I am writing...

Recent developments in the AI realm made me think a lot about my next moves in order to not fall behind. The pace is so fast that I am very picky about what to do, because I cannot waste much of my time learning new things that I might not finally use in my daily workflow.

I have to admit, that I ever was a late adopter. I am consciously waiting for hypes being over (or becoming a real thing) and watching technology to proof itself, before fully committing to it and throwing my money at it. I am not the type who buys the next new shiny thing, plays with it for a week and then throws it away if it does not serve the purpose I expected it to.

However, the situation is different now. While I am watching AI coding tools and agents to proof themselves to become a serious help in software engineering, everybody else is doing it already, despite all the downsides. I am still hesitating to ship code that I am not fully aware of, because the output of coding tools and agents totally exceeds my capabilities to review. Output speed triples but my QA seems to slow down by 10x.

At that point I am now standing in some kind of void, frozen from this situation and I cannot move in any direction. On the one hand, manual programming feels wrong in 2026 (damn, it used to be fun!). It feels like making fire with stones while everybody else uses a blow torch. At the same time I am hesitating to go all in on agentic coding as I am watching people burn their entire house, because they left the blow torch doing its work...

Is this just my perception or is this a real thing? Am I the only one who is not seeing a clear direction where to move next?

Wasted Open Source efforts 😮

Jan Küster 🔥 — Wed, 10 Sep 2025 08:29:52 +0000

Long time no see my friends! 👋

Today I got notified by GitHub stale bot that a PR of mine in the famous PyTorch repo got closed by stale bot. 🤖
Yes, by a bot; not by an author or repo owner but a bot.
You may argue that this is normal for huge projects like this one but by looking deeper into the PR this reveals to me how much wasted effort is out there in open source!

How it all began

In June 2025 I wanted to try a tool for one shot speech cloning.
The project was based on PyTorch and while installation via Docker is intended to be reproducible, in reality it is not.

At first, I cloned the repo and ran docker build:

docker build -t f5tts:v1 .

This already took (as you might know from similar projects) ages to download and build. 😴

After the build was finally complete, I tried to run the project via

docker container run --rm -it --gpus=all --mount 'type=volume,source=f5-tts,target=/root/.cache/huggingface/hub/' -p 7860:7860 ghcr.io/swivid/f5-tts:main f5-tts_infer-gradio --host 0.0.0.0

There, I got stuck with the following entirely confusing error message:

docker: Error response from daemon: could not select device driver "" with capabilities: [[gpu]].

Thank you for nothing. Anyway, I searched the web for a good amount of time, until I finally found the solution. On Linux I need to manually install the Nvidia container toolkit if you want to use PyTorch with GPUs:

https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html

Well, this was neither described in the repo nor in the PyTorch repo.
Nowhere. Who would ever know this? Nobody, right!? This seemed perfect for a little pull request.

My Motivation for the PRs

I wasted time and got emotionally affected by this and I thought that others should have a better developer experience with this. Plus the effort for the PR is minimal.

This is living open source to me! I solved something and save time for all of us by making it available to the rest of the world. In turn you do the same for me and we benefit altogether.
What a nice little dreamworld I am living in.

Waking up from the dreamworld: the most unfriendly GitHub conversation I have had in years 🤬

Well, I thought it might be beneficial to everyone to add a line to the installation instructions to save everyone's time. The reponse was totally unexpected though. Read for yourself:

Docker installation is missing requirements for cuda support #1073

jankapunkt posted on Jun 03, 2025

Checks

[x] This template is only for bug reports, usage problems go with 'Help Wanted'.
[x] I have thoroughly reviewed the project documentation but couldn't find information to solve my problem.
[x] I have searched for existing issues, including closed ones, and couldn't find a solution.
[x] I am using English to submit this issue to facilitate community communication.

Environment Details

The documentation should note, that the container will not run, if the nvidia docker toolkit is not installed and configured.

If you don't install the toolkit, you will get

docker: Error response from daemon: could not select device driver "" with capabilities: [[gpu]].

I can open a PR and add it to the docs if you like.

Steps to Reproduce

install docker (follow official docker installation guide)
follow installation instruction for Docker setup, defined in Readme

✔️ Expected Behavior

Installation should be reproducible. When following the installation for Docker step by step, it should start without issues.

❌ Actual Behavior

docker container run --rm -it --gpus=all --mount 'type=volume,source=f5-tts,target=/root/.cache/huggingface/hub/' -p 7860:7860 ghcr.io/swivid/f5-tts:main f5-tts_infer-gradio --host 0.0.0.0
docker: Error response from daemon: could not select device driver "" with capabilities: [[gpu]].

View on GitHub

While this obviously their choice as owner, I was rather shocked by the total lack of empathy and aggressiveness against me as if I was a burden or something.

What would a newcomer think in such a situation? Honestly,I hope no newcomer would have to face such bullsh*t but I fear this way of communication is not an exception.

Anyway, the obvious outcome of this was to step up and make the PR directly to the where the issue was caused in the first place.

Going big: PR in the official PyTorch repo

I am no shy person when it comes to action so I opened the same PR on the PyTorch repo, willing to face any upcoming trouble and discussion that might come up.

docs: link to Nvidia Container Toolkit in README #155102

jankapunkt posted on Jun 04, 2025

The Nvidia Container Toolkit is needed on Linux Distributions to properly run Docker images with --gpus flag.

The dependency is OS-level and cannot be pinned from within the container.

Otherwise containers will not run and provide and ambiguous error message

docker: Error response from daemon: could not select device driver "" with capabilities: [[gpu]].

View on GitHub

Accepting the PR was already blocked by CLA assistant, making me sign some bureaucratic documents online with a digital signature, complying to some legalese terms nobody understands (not even the PyTorch devs and maintainers) besides a few lawyers. 🤢
No worries, I didn't read as I was supposed to because I just wanted to open the PR.

Then it was waiting for the CI. I changed just a README so please no fails. Fortunately everything passed.

One day later a maintainer added the triaged label and requested reviews from other maintainers. Awesome, it looked like this passed initial triage and would not be rejected as "not important" as in the other repo beforehand.

But then: silence. Nothing. No reaction. No comment or review. After a month stale bot notified the PR getting marked stale and maintainers can remove the stale label.
I commented "not stale" but this had no effect: Two months after I opened the PR it got closed by stale bot. What a 💩

My personal thoughts

Fortunately the PR was just an additional line in a README but it was also a test - a test how contributions are honored and if people care on the small things that developers care about because they are the ones to fiddle with it.

It seems nobody cared about the efforts of ohers.

From this point I am really in doubt of whether I will open a PR to one of the huge repos again. It is much easier to create a gist and spread the word plus it saves me some annoying conversations.

Anyway, if you ever get into the issue on Linux, Docker and PyTorch telling you docker: Error response from daemon: could not select device driver "" with capabilities: [[gpu]]. then you now know to install the Nvidia Docker Toolkit.

Reactive Data Structures in MeteorJS - Reactive Stack

Jan Küster 🔥 — Thu, 28 Nov 2024 15:13:00 +0000

MeteorJS brings client-side reactivity out of the box. No matter which frontend framework you choose, you will always have an integrated reactivity that synchronizes your data and the UI. This is one of the core strengths of MeteorJS.

But that's not the only advantage. It allows you to write your data structures of any complexity and while you access them using their normal API, reactivity is handled under the hood automatically.

The tutorial is also available as a video:

Goal of this tutorial

In this tutorial I will show you how to write your own reactive data structure using a simple stack implementation.

At the end you will have a fully functional stack, that automatically updates UI and autorun functions when elements are pushed or popped.

Short reminder: What is a stack?

A stack manages data using the list-in-first-out (in short, LIFO) principle. The last item that is pushed onto the stack will be the first item that is accessed when popped from the stack.

Underlying items are inaccessible until they become the top item by popping the stack.

CC0 wikimedia commons

Let's start coding

1. Create a new project

First of all, make sure MeteorJS is installed on your machine. In case you have no existing MeteorJS project available, create one by opening your terminal and enter:

$ meteor create

Provide a name and the frontend framework you intend to use. for this tutorial, I will use Blaze. However, the reactive stack will work with any of the frontends, available in MeteorJS.

2. Remove boilerplate

In the next step, remove the boilerplate from the client/main.html.
It should look like this now:

<head>
  <title>Meteor App</title>
</head>

<body>
  <h1>Reactive Data Structures</h1>
</body>

Then remove the boilerplate from client/main.js or client/main.jsx if you chose React or Solid. It should look like this now:

import { Template } from 'meteor/templating';
import './main.html';
import './main.css';

3. Initial Stack implementation

Now, create a new file under client/ReactiveStack.js and implement a basic stack. In this first approach, the focus is on the data structure itself and not the reactivity.

export class ReactiveStack {
  constructor () {
    this.items = []
  }

  push (item) {
    this.items.push(item)
    return this.items.length
  }

  pop () {
    const item = this.items.pop()
    return item
  }

  peek () {
    return this.items.at(-1)
  }

  all () {
    return  [].concat(this.items)
  }

  size () {
    return this.items.length
  }
}

4. Integrate the stack into the UI

You can now add a simple template that includes the ReactiveStack. Update your client/main.html file to the following:

<head>
  <title>reactive-datastructures</title>
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>

<body>
  <h1>Reactive Data Structures</h1>

  {{> stack }}
</body>


<template name="stack">
  <h2>Stack</h2>

    <!-- user input -->
    <input type="text" name="push" class="item-input">
    <button class="push-btn">Push</button>
    <button class="pop-btn">Pop</button>

    <!-- reactively peek the top item -->
    <div>top item: {{topItem}}</div>

    <div>List:</div>
      <ul>
        {{#each item in items}}
          <li>{{item}}</li>
        {{/each}}
      </ul>
</template>

🤓 A quick explanation about this template

The template renders the stack as a list of items, using an {{#each}} loop. Read the Blaze docs if you don't know how these work.

The top item is delivered by the {{topItem}} helper. The user input is a simple text input and two buttons for push and pop. The topmost item is constantly peeked from the stack.

5. Adding Template logic

The template from the previous step won't work at all, since you have defined only the rendering logic. It doesn't know about a stack, items and topItem. Let's add them by updating client/main.js to the following:

import { Template } from 'meteor/templating';
import {ReactiveStack} from './ReactiveStack'
import './main.html';

Template.stack.onCreated(function () {
  // create a new reactive stack
  const instance = this
  instance.stack = new ReactiveStack()

  // simple demonstration of autorun
  // within templates, based on reactive changes
  instance.autorun(() => {
    const size = instance.stack.size()
    const top = instance.stack.peek()
    console.debug({ size, top })
  })
})


// reactive helpers to use within the template
Template.stack.helpers({
  topItem () {
    return Template.instance().stack.peek()
  },
  items () {
    return Template.instance().stack.all().toReversed()
  }
})

// event listeners for the buttons
Template.stack.events({
  'click .push-btn' (e, instance) {
    e.preventDefault()
    const input = instance.$('.item-input')
    const item = input.val()
    instance.stack.push(item)
    input.val(null) // clear input
  },
  'click .pop-btn' (e, instance) {
    e.preventDefault()
    instance.stack.pop()
  }
})

Try it out by navigating to http://localhost:3000. You will see that there is nothing reactive yet. This will change with the next step.

6. Make it reactive

Let's add some magic. 🧙‍♂️ This is where Tracker comes into play.

Tracker has a simple way to track computations using its Dependency class. While Tracker offers complex functionality to support many use cases, this step focuses solely on two methods this time:

changed - to inform about data has changed
depend - to inform about data is observed and Tracker is "active" (the method is called within an active computation, e.g. within an autorun).

These two functions are basically responsible for invoking a new computation call each time they are called. In order to make our ReactiveStack truly reactive, we simply add this dependency to it and call changed on any change to items and depend on any read.

Afterwards, the stack looks like this:

import { Tracker } from 'meteor/tracker'

export class ReactiveStack {
  constructor () {
    this.items = []
    this.dep = new Tracker.Dependency()
  }

  push (item) {
    this.items.push(item)
    this.dep.changed()
    return this.items.length
  }

  pop () {
    const item = this.items.pop()
    this.dep.changed()
    return item
  }

  peek () {
    if (Tracker.active) this.dep.depend()
    return this.items.at(-1)
  }

  all () {
    if (Tracker.active) this.dep.depend()
    return  [].concat(this.items)
  }

  size () {
    if (Tracker.active) this.dep.depend()
    return this.items.length
  }
}

Now, navigate back to http://localhost:3000 and try again. At this point, the template will automagically update.

This is because in Blaze, every Template.helper is actually a wrapped autorun computation that invokes a re-render of the attached DOM elements.
Updating the stack invokes the surrounded autorun which itself invokes a rerender of the attached Blaze view with the updated data.

Congratulations, you have implemented a ReactiveStack. 🎉

Where to go from here?

Keep looking (aka follow me) for upcoming articles on more Reactive Data Structures in MeteorJS. Alim, StoryTeller and I also covered the whole topic of reactivity (with focus on signals) in episode 62 of our weekly live stream "This week in MeteorJS".

If you're interested in getting in touch with the community, then join the MeteorJS forums and become a member today.

About me 👋

I regularly publish articles about MeteorJS and JavaScript here on dev.to. I also recently co-hosted the weekly MeteorJS Community Podcast, which covers the latest in Meteor and the community.

You can also find me (and contact me) on GitHub, Twitter/X and LinkedIn.

If you like what you read and want to support me, you can sponsor me on GitHub or buy me a book from my Amazon wishlist.

Transform any MeteorJS App to a PWA in 2024

Jan Küster 🔥 — Mon, 28 Oct 2024 14:54:15 +0000

TL;DR: It's easier than ever to transform your MeteorJS app into a PWA. Only few things have changed since my original article from 2020. These are mostly improvements on ServiceWorker, Manifest file and Head tags. Transforming to PWA will be a great benefit for your app's performance, UX and SEO.

What are PWAs?
Why should I make my MeteorJS app a PWA?
Enough talk, show me how to do it
1. Add a service worker
2. Provide a manifest
3. Add Head entries
4. Force ssl
Where to go from here?
About me

What are PWAs?

According to web.dev PWAs are

[...] web apps built and enhanced with modern APIs to deliver enhanced capabilities, reliability, and installability while reaching anyone, anywhere, on any device, all with a single codebase.

This makes them very different from native apps, which are build specifically for their target platforms (desktop or mobile devices). PWAs instead leverage the universal availability of the web platform. Does this sound familiar as a MeteorJS developer? Right, MeteorJS does so, too.

Why should I make my MeteorJS app a PWA?

With MeteorJS you build your apps by default and primarily for the web platform (although you can also build for desktop using Electron and for mobile using Cordova or React Native). They rely on a single codebase, as PWAs do, and use JavaScript across the full stack.

Transforming your MeteorJS app into a PWA is a low-hanging fruit that comes with great benefits for your users in terms of performance (caching), SEO (manifest, meta tags), user experience (responsive design) or universal availability (offline capabilities).

Enough talk, show me how to do it

As a preliminary requirement you either need to have an existing MeteorJS app, optimally using a responsive design library, such as Tailwind or Bootstrap.

If you don't have one, you can create it with ease. Simply installing MeteorJS, then enter the following commands:

$ meteor create --tailwind pwa-example
$ cd pwa-example
$ meteor

1. Add a service worker

The ServiceWorker is the core component that drives your PWA.

It takes the form of a JavaScript file that can control the web page/site that it is associated with, intercepting and modifying navigation and resource requests, and caching resources in a very granular fashion to give you complete control over how your app behaves in certain situations (the most obvious one being when the network is not available).
MDN Service Worker API

To integrate a ServiceWorker you need to create a new folder and fetch the foundation file from jamauro/pwa-kit.

$ mkdir -p public
$ curl "https://raw.githubusercontent.com/jamauro/pwa-kit/refs/heads/main/sw.js" >> ./public/sw.js

You can extend or modify it to your needs or leave it as a good default. Your next goal is to init the ServiceWorker as soon as possible. For this, create a startup file:

$ mkdir -p imports/startup/client
$ touch imports/startup/client/serviceworker.js

Add the following content to the file:

Meteor.startup(async () => {
  try {
    await navigator.serviceWorker.register('/sw.js');
  } catch (error) {
    console.error('Service Worker registration failed:', error);
  }
});

Finally, you need to import the startup file in client/main.js or client/main.jsx (depending on which frontend you have chosen)

import '../imports/startup/client/serviceworker';

That's it! You're already halfway-through on your way to your PWA.

But in MeteorJS, most traffic between clients and the server happens through DDP, a WebSocket communication protocol. ServiceWorkers work on HTTP-level.

That's correct. However, the MeteorJS client app itself is still a bundle of HTML, JavaScript, CSS and various assets and it is beneficial to control most of these resources in the most performant way possible. Additionally, Meteor does not restrict you from using HTTP requests, for example via fetch.

2. Provide a manifest

In the next step you will provide a manifest file that describes your app and configures appearance and behavior, when installed as PWA.

In order to do that, create a new JSON file in your public folder via

$ echo "{}" >> public/app.webmanifest

Then you need to provide at least the following minimal information:

{
  "name": "your app name",
  "short_name": "app name",
  "icons": [
    {
      "src": "/icons/icon-192.png",
      "type": "image/png",
      "sizes": "192x192"
    },
    {
      "src": "/icons/icon-512.png",
      "type": "image/png",
      "sizes": "512x512"
    }
  ],
  "theme_color": "#0096FF",
  "background_color": "#0096FF",
  "start_url": "/",
  "scope": "/",
  "display": "standalone"
}

As you can see, there are several icons included. Make sure to adjust the paths to match your icons and that you have at least an icon sized in 192x192px and 512x512px available under these paths!

If you don't then you can use the following code to grab two placeholder icons from my older article:

$ mkdir -p public/icons
$ curl -o public/icons/icon-192.png https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fi%2Fid91jftqd0ualcuirtyf.png
$ curl -o public/icons/icon-512.png https://media.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fi%2Fevszcjg6ix64lkcc5wb0.png

To show you the awesomeness of these images, let me link them here again:

3. Add Head entries

In order to make your manifest file and icons discoverable you need to link them in your HTML head using the meta and link tags in your client/main.html file:

<head>
    <title>Meteor App</title>
    <meta charset="utf-8">
    <meta http-equiv="x-ua-compatible" content="ie=edge">
    <meta
          name="viewport"
          content="width=device-width, height=device-height, viewport-fit=cover, initial-scale=1, maximum-scale=1, minimum-scale=1, user-scalable=no"
    >
    <meta name="mobile-web-app-capable" content="yes">
    <meta name="apple-mobile-web-app-capable" content="yes">
    <link rel='manifest' href='/app.webmanifest'>
    <link rel='icon' type='image/png' sizes='192x192' href='/icons/icon-192.png'>

    <!-- TODO: update colors based on your theme color -->
    <meta name='msapplication-TileColor' content='#0096FF'>
    <meta name='theme-col4. Force sslor' content='#0096FF'>

    <!-- optional - these icons require further action -->
    <link rel='icon' type='image/png' sizes='32x32' href='/icons/favicon-32x32.png'>
    <link rel='icon' type='image/png' sizes='16x16' href='/icons/favicon-16x16.png'>
    <link rel='mask-icon' href='/icons/safari-pinned-tab.svg' color='#0096FF'>
    <link rel='apple-touch-icon' href='/icons/apple-touch-icon.png' />

    <noscript>
        <style>
            body:before { content: 'Sorry, your browser does not support JavaScript!'; }
        </style>
    </noscript>
</head>

While this tutorial provides you the minimal set of icons, required for a working PWA, you need to action to meet platform-specific icon formats in order to be compliant.

Also note, there are various optimizations in head tags load order, something you might want to further investigate, too.

4. Force ssl

The ServiceWorker requires HTTPS, which you can easily enforce via

$ meteor add force-ssl

If you use Galaxy (Meteor Cloud) as your hosting platform, then this is sufficient on it's own and you need no further configuration when you deploy as subdomain of meteorapp.com. If you use a custom domain then you can configure SSL in a single step.

If you deploy to another hosting provider or envirely custom environment, then you need to make sure you have SSL certificates configured correctly on your own. Meteor-UP might be a good choice in this case, as it provides SSL config via let's encrypt out of the box.

There are also other resources linked in this Meteor guide section on SSL.

Where to go from here?

You should checkout jam:offline if you want to gradually add offline-capabilities to your new upgraded PWA.

If the provided ServiceWorker is not sufficient for your needs, then you might checkout Google workbox and its recipes.

If you think about push notifications, then you might want to consider activitree:push or solutions like Novu. If you want to be free of any vendor infrastructure then you might want to implement Web Push Notifications for PWAs, which are also supported by ServiceWorkers.

The web.dev guide on PWA covers nearly every aspect of PWAs and how they work.

Finally, we also covered PWAs in one of our livestreams episodes "This Week in MeteorJS":

About me 👋

You can also find me (and contact me) on GitHub, Twitter/X and LinkedIn.

If you like what you read and want to support me, you can sponsor me on GitHub or buy me a book from my Amazon wishlist.

MeteorJS 3.0 major impact estimated for July 2024 ☄️ - here is all you need to know 🧐

Jan Küster 🔥 — Mon, 24 Jun 2024 18:14:25 +0000

The next major MeteorJS release is coming in July 2024! After more than two years of development, this is the final result. The first discussions started in June 2021 and there has been multiple alphas, betas, rcs and a huge amount of package updates. These were constantly battle-tested by the Meteor Core team and the Community, shaping the features and performance of the platform one by one.

Back in 2021 - the Fibers situation
Biggest changes
Will it have consequences?
Conclusion
Resources to help you migrate your Meteor app

Back in 2021 - the Fibers situation

MeteorJS emerged from a JavaScript framework towards a true full-stack development platform, batteries included. One of its greatest advantages was to provide features like optimistic UI, zero-config, reactivity out of the box and support for many popular front-ends, which are still among its core features nowadays.

Since pre-1.0 versions, MeteorJS relied on fibers (coroutines) as its back-end for async programming, long before async/await became a thing. That was revolutionary for developers: writing async code naturally, in sync-style, without callbacks or other nesting structures, resulting in more comprehensible code and a better developer experience.

In April 2021, fibers became incompatible with Node 16 and therefore, Meteor was pinned to Node 14. It was clear that that replacing fibers with async/await for the entire ecosystem was the only future for MeteorJS. That way, it would always be up-to-date with the latest Node LTS and support the majority of NPM packages out there.

Biggest changes

The core-repository development for this major release gathered over 2300 commits, affecting over 800 files, split in over 200 pull requests, involving contributors from the Meteor Core team and the Community. The efforts for all affected packages are uncountable as they are distributed across the whole community.

The following table lists the most impactful changes:

change	what happend
dropping Fibers	replace any `fibers`-reliance with `async/await`
top-level await	use `async/await` without the need for an IIFE
async database	make all MongoDB interactions `async/await`
async accounts and oauth	ensure accounts, 2FA, passwordless and OAuth packages are async and thus, still zero-config
ARM support	finally support MeteorJS on ARM architectures
replace connect with express	drop connect to use express as webserver
docs upgrade	the entire documentation system was rewritten, replacing hexo with docusaurus, integrating Ask AI into the new docs
upgrade Node	stick to the latest Node LTS (20 as of writing this article)
update DDP	make the whole DDP/Websocket infrastructure and data layer compatible with the `async/await` while avoid breaking isomorphism where possible
update build system	make the build system (isobuild) work without `fibers`
Galaxy 2	the official zero-config hosting platform for MeteorJS apps has been upgraded with a facelift and many quality of life features

Furthermore, there were many fixes, patches, and updates to NPM dependencies and skeleton projects, all aimed at ensuring that MeteorJS remains zero-config by default for many of its core features.

Will it have consequences?

If you are new to MeteorJS:

No worries! Just follow the new docs to create a new project with Meteor 3.0 and develop amazing apps quickly.

$ npm install -g meteor
$ meteor create --release 3.0-rc.4 # soon --release is not required anymore

If you have an existing Meteor apps or packages:

Every (I repeat: every) Meteor app out there was affected! They had to be rewritten in order to being able to upgrade towards 3.0 or otherwise being stuck on Node 14.

This especially involves any database interaction, the backbone of most MeteorJS apps. It also applied to any package with reliance on fibers. Consider the following example:

import { Meteor } from 'meteor/meteor'
import { Mongo } from 'meteor/mongo'

const Tasks = new Mongo.Collection('tasks')

Before 3.0, using fibers

Meteor.methods({
  updateTask ({ _id, text }) {
    const taskDoc = Tasks.findOne({ _id })

    if (taskDoc.createdBy !== this.userId) {
      throw new Meteor.Error(403, 'permission denied', 'not owner')
    }

    return Tasks.update({ _id }, { $set: { text }})
  }
})

After 3.0, using async/await

Meteor.methods({
  async updateTask ({ _id, text }) {
    const taskDoc = await Tasks.findOneAsync({ _id })

    if (taskDoc.createdBy !== this.userId) {
      throw new Meteor.Error(403, 'permission denied', 'not owner')
    }

    return Tasks.updateAsync({ _id }, { $set: { text }})
  }
})

It looks not that much but beware that it breaks isomorphism, another core concept of MeteorJS, where code can be shared across server and client. This, combined with the size and structure of medium or large-sized apps can result in a migration effort of multiple months, involving multiple developers.

Another big task was to resolve the version conflicts in the packages, since all of the MeteorJS core packages were updated to a new major version. Thankfully, the Meteor Community Ambassadors (StoryTellerCZ, Alim Gafar, and I) collaborated to create a detailed guide covering this topic:

youtube.com

Conclusion

The next major MeteorJS release is coming in a few weeks, and of course, there will be changes if you have Meteor apps and packages. To help you prepare for all of them, I have made a list below to help you.

Resources to help you migrate your Meteor app

Read the migration guide
Read on how to prepare your 2.x app for async
Read the new meteor 3.0 docs
Read on extended Node 14 support with security patches
Subscribe to the Meteor Community Dispatches podcast to stay up to date
Consult StorytellerCZ, Meteor ambassador and one of the (if not the) most active contributors from the community for help
Join the Meteor forums and ask for help and guidance

I hope you enjoy this read and see you on Meteor Community!

About me 👋

You can also find me (and contact me) on GitHub, Twitter/X and LinkedIn.

If you like what you read and want to support me, you can sponsor me on GitHub or buy me a book from my Amazon wishlist.

5 core concepts you should know about MeteorJS in 2024

Jan Küster 🔥 — Mon, 29 Apr 2024 15:30:18 +0000

MeteorJS is a JavaScript development platform for web- and mobile apps. It's most suited for, but not limited to, building single page applications (SPA), mobile apps, and complex web apps with feature-rich clients.

meteor / meteor

Meteor, the JavaScript App Platform

Meteor is an ultra-simple environment for building modern web applications.

📚 Create your applications using modern JavaScript

Benefit from the latest technology updates to rapidly prototype and develop your applications.

✨ Integrate technologies you already use

Use popular frameworks and tools right out-of-the-box. Focus on building features instead of configuring disparate components yourself.

💻 Build apps for any device

Use the same code whether you’re developing for web, iOS, Android, or desktop for a seamless update experience for your users.

🔥 Getting Started

How about trying a tutorial to get started with your favorite technology?

React
Blaze
Vue

🚀 Quick Start

On your platform, use this line:

> npx meteor

🚀 To create a project:

> meteor create

☄️ Run it:

cd my-app
meteor

🧱 Developer Resources

Building an application with Meteor?

Deploy on Galaxy
Discuss on Forums
Join the Meteor Discord by clicking this invite…

View on GitHub

It's is actively developed since 2012 and thus, among the most stable platforms in the JavaScript ecosystem. Chances are high, you have heard of it or knew it from past experiences.

In this article I want to present you the 5 core concepts of MeteorJS and their state in 2024. Compare for yourself, if this is still the MeteorJS you know from back then.

True Full Stack

MeteorJS uses JavaScript across the whole stack, from DB to client. This philosophy is one of the most important factors of why getting started with Meteor is such an ease:

you only need to deal with one programming language.

On the database-level it automatically integrates with MongoDB, the biggest NoSQL database out there. Every Meteor release has a specific MongoDB binary bundled. There is no need for additional setup and you can start using it right away, due to a very carefully crafted integration of the MongoDB JavaScript driver.

In contrast to the tight coupling on the database-level, MeteorJS is very flexible in supporting many of the popular frontends. By default it supports React, Vue (2 + 3), Svelte and Solid. It also provides core-support for TypeScript, GraphQL (via Apollo), Tailwind, Chakra-UI, plus whatever you want to integrate via NPM packages.

Great	tech	MeteorJS	supports

Finally, it has it's own years-long battle-tested frontend Blaze and adding other frontends is also possible via build plugins.

Creating a new project with these technologies is as easy as it gets by using the builtin meteor create dialog:

youtube.com

WebSocket and DDP

By default clients connect to the server via WebSocket and communicate using a well-defined protocol (DDP; Distributied Data Protocol). No need to manage things on your own.

With this you can for example declare and call RPC-style endpoints (Meteor Methods) or subscribe to published data (Meteor Publications) as easy as it gets:

// server/main.js
const Todos = new Mongo.Collection('todos')

Meteor.methods({
  async addTask ({ title }) {
    const { userId } = this
    return Todos.insertAsync({ title, userId })
  }
})

Meteor.publish('myTasks', function () {
  const { userId } = this
  return Todos.find({ userId })
})

// client/main.js
const Todos = new Mongo.Collection('todos')

Meteor.subscribe('myTasks')

// yes, top-level await 
await Meteor.callAsync('addTask', { title: 'do laundry' })
await Meteor.callAsync('addTask', { title: 'clean kitchen' })

// ... subscription ready

await Todos.find().fetchAsync() // reactive!

There is also an extensive guide, that also covers the DDP lifecycle of a Method call in detail.

Optimistic UI

For every method there is a client-side "stub", which is basically a simulation of what is likely to happen on the server. If we defined this Method in client and server code, as all Methods should be, a Method simulation is executed in the client that called it. The client enters a special mode where it tracks all changes made to client-side collections, so that they can be rolled back later. When this step is complete, the user of your app sees their UI update instantly with the new content of the client-side database, but the server hasn’t received any data yet.

In the meantime the server gets called and is likely to produce the same result, for which no further updates to the UI are needed. If the server produces a different result, then the UI will quickly update to comply with the "truth", returned from the server.

This works in particular, since there is also an optimistic id-generation for the documents in the client-side MongoDB collections.

Zero Config

MeteorJS comes with full batteries included. This means, there is no config needed for creating a development-build or production-build or to provide auto-reload and hmr. This is all taken care of by Meteor's build system.

$ meteor create myproject
# ... create your project
$ cd myproject && meteor
# runs at localhost:3000

There is no config or code required for connecting clients to server, establishing messaging or rules for their interaction. This is all handled by the aforementioned DDP protocol.

There is no config or code needed for password based authentication and minimal config needed for login with external OAuth providers, such as Twitter/X, Facebook, GitHub, Google, Meetup or Meteor developer accounts. Same applies to passwordless authenticaion and 2FA.

Deployment to Galaxy (managed hosting for Meteor apps) can be done in a single terminal command. Even easier it is by using push-to-deploy via their GitHub integration. Alternatively you can deploy to your own managed infrastructure using the free and open-source deployment tool "Meteor-Up" with ease.

Despite all these out-of-the-box experiences, many things are still configurable. For example, you can write your own OAuth2 integration for third parties, such as Apple or use an external bundler like Vite:

Meteor.js with Vite, Solid, and Tailwind CSS

Frederico Maia ・ May 10 '23

#meteor #solidjs #vite #tailwindcss

ESNext

MeteorJS has always strived to be in sync with the latest ESNext, following the latest Babel versions or implement things on their own. To name a few examples: import/export were available very early on as core part of MeteorJS; Promises support started in 2015; async/await became available in 2016;nullish coalescing came day it entered the specifications; full typescript integration in core by 2019 after years of being supported by community packages (since 2016).

MeteorJS will continue to be on ESNext, giving devs the ability to be up-to-date, simply by updating their apps using meteor update since these features are baked into the ecmascript core package.

Community Packages

While the list contains five core concepts, there is one meta-level concept that is crucial for the MeteorJS ecosystem. It's all the packages, developed and maintained by the community!

Many packages are zero-config drop-ins to provide an extended experience to the MeteorJS core functionality.

Some of them play such an important role and are used by so many projects, that they got moved to Meteor Community Packages, an org to maintain and improve the most popular packages and to ensure a vital ecosystem:

Meteor-Community-Packages / meteor-collection2

A Meteor package that extends Mongo.Collection to provide support for specifying a schema and then validating against that schema when inserting and updating.

Collection2 (aldeed:collection2 Meteor package)

A Meteor package that allows you to attach a schema to a Mongo.Collection. Automatically validates against that schema when inserting and updating from client or server code.

This package requires the simpl-schema NPM package, which defines the schema syntax and provides the validation logic.

Meteor-Community-Packages / meteor-roles

Authorization package for Meteor, compatible with built-in accounts packages

meteor-roles v3

Authorization package for Meteor - compatible with built-in accounts package.

There are also older versions of this package:

meteor-roles v3

Contributors

Thanks to:

Authorization

This package lets you attach roles to a user, which you can then check against later when deciding whether to grant access to Meteor methods or publish data. The core concept is very simple, essentially you are creating an assignment of roles to a user and then checking for the existence of those roles later. This package provides helper methods to…

View on GitHub

These are just two example among over 60 repositories of the Meteor-Community-Packages org. Finally, some packages even make it to the core, such as the aforementioned typescript package. This shows the constant importance of community packages as vital part of an active and alive development platform.

About me 👋

I regularly publish articles about Meteor.js and JavaScript here on dev.to. I also recently co-hosted the weekly Meteor.js Community Podcast, which covers the latest in Meteor.js and the community.

You can also find me (and contact me) on GitHub, Twitter/X and LinkedIn.

If you like what you read and want to support me, you can sponsor me on GitHub, send me a tip via PayPal or sponsor a book from my Amazon wishlist.

I fixed the "Save draft" Button on dev.to - No Accidental Publishing Anymore 😇

Jan Küster 🔥 — Mon, 25 Mar 2024 12:02:54 +0000

Today I accidentally published an article AGAIN, because "publish" and "safe draft" are so close together.

I even opened a discussion, which got no responses so far (which I think existed somewhere else or I am the only one with this issue...).

Cover image by Francisco De Legarreta C. on Unsplash

How to fix it?

I use Greasemonkey and Tampermonkey, depending on the browser.
The fix script is rather simple:

observe the DOM using MutationObserver in
use body as observe target, in case the user navigates to the edit route from dashboard or preview route
"wait" until the editor-actions are added as childList to the article-form
if they're added, get the second button ("save draft" button) and update it's margin-left style

The script looks like the following:

// ==UserScript==
// @name     dev.to save button space
// @version  1
// @grant    none
// ==/UserScript==
const BUTTON_STYLE = '200px'
const target = document.querySelector('body')


const callback = (mutationList, observer) => {
  for (const mutation of mutationList) {

    if (mutation.type === 'childList' && mutation.target.id === 'article-form') {
      const actions = mutation.addedNodes[0]

      if (actions && actions.id === 'editor-actions') {
        Array.from(actions.children)[1].style.marginLeft = BUTTON_STYLE
      }
    }
  }
}

// Create an observer instance linked to the callback function
const observer = new MutationObserver(callback)

// Start observing the target node for configured mutations
observer.observe(target, { attributes: true, childList: true, subtree: true })

Also available as gist: https://gist.github.com/jankapunkt/a442d10a2d3cda905843ca35645007d8

Feel free to comment or optimize in any way :-)

About me 👋

You can also find me (and contact me) on GitHub, Twitter/X and LinkedIn.

If you like what you read and want to support me, you can sponsor me on GitHub, send me a tip via PayPal or sponsor a book from my Amazon wishlist.

SpeechSynthesis in <= 256 characters (Web Speech API)

Jan Küster 🔥 — Sun, 24 Mar 2024 13:09:03 +0000

This is a submission for DEV Challenge v24.03.20, One Byte Explainer: Browser API or Feature.

Explainer

Make texts & UIs more accessible by using SpeechSynthesis: Create a new SpeechSynthesisUtterance + given text, pitch, rate, volume, lang, and voice (vary by OS and browser). Tap into various events. Finally, pass the utterance to speechSynthesis.speak → 🔊

Additional Context

No external tools were used for the above text in any circumstance. 🤞

The SpeechSynyhesis is the "output" part of the Web Speech API, where the input counterpart is SpeechRecognition.

Despite its potential in terms of accessibility (people with limited reading skills or generally low literacy), it hasn't been developed in years! Custom voices cannot be loaded, although remote voice loading is generally implemented.

Alternatives are either closed + commercial or require a server to generate the voice and stream it as audio to the client. It's time for the webdev community to shed some light on this and not let speech synthesis become a walled garden solution.

I also wrote an article about maximising cross-browser compatibility for speech synthesis here on dev.to:

Cross browser speech synthesis - the hard way and the easy way

Jan Küster 🔥 ・ Dec 7 '21

#webdev #browser #javascript #standards

Cover image by Scott Major on Unsplash

Build Your Own Uptime Monitor with MeteorJS + Fetch + Plotly.js ☄️🔭

Jan Küster 🔥 — Fri, 08 Mar 2024 13:44:52 +0000

In this tutorial I'll going to show you how to create your own uptime monitor in six easy steps. The app will use of the following stack, database to frontend:

MongoDB to store our data as documents, close to JS objects
MeteorJS to build and run our app and handle the data layer out-of-the-box
fetch at the heart of the monitoring requests to the external server
React as our frontend library
Plotly as our chart renderer

Concept and Architecture
Create a New React Project with MeteorJS
Implementation
- Step 1 - Configuration and Configurability
- Step 2 - Create Collections
- Step 3 - Create a Handler for the Collections
- Step 4 - Create an Uptime Request
- Step 5 - Server Startup
- Step 6 - The Monitoring Frontend
Where to go from here
About me

Concept and Architecture

There is an HTTP endpoint on your external server that is constantly requested by your Meteor app's server using fetch.
Each response and it's status, including timeouts and latency measures, is stored as a "document" in the Database, which is MongoDB by default.
Meteor "watches" the collection of documents and "publishes" updates of the collection to clients, that "subscribe" to it. This allows live-monitoring to be set up for custom periods of time.
The React client application subscribes to the live changes and uses Plotly to display them as a line graph showing uptime and response time for a given period.

Please note that you should only use this for websites that you own or have the permission to monitor. Make sure that you always act within the law.

Create a New React Project with MeteorJS

If you do not have MeteorJS installed on your system, you may want to perform this quick install of the latest stable version:

$ npm install -g meteor
# on Linux||MacOS, you can also use the shell-installer script via
$ curl https://install.meteor.com/ | sh

Then, it's time to create a new project, once the meteor tool is installed and available:

$ meteor create uptime

This creates a new React-based Meteor project in the folder uptime.

Note: If you don't want to use React, then you can also see what other frontends are available by running meteor create --help. Note, however, that this tutorial focuses on Meteor+React

Go to the uptime folder and install some dependencies, then run the project for the first time:

$ cd uptime
$ meteor npm install react-plotly.js plotly.js node-abort-controller
$ echo "{}" >> settings.json
$ meteor --settings=settings.json

Your project is now running on http://localhost:3000

Implementation

Most of the following steps are on the server. However, shared (isomorphic) code between client and server is placed in a separate folder called /imports. A new React project should have this folder by default, though.

Step 1 - Configuration and Configurability

For our uptime measurements we use a simple HTTP HEAD request. We use HEAD, because there is no response body sent over the wire and being parsed.

However, the request can be configured using Meteor's settings.json file, similar to .env, allowing for easy changes in the future without the need to modify any code.

Let's create a new monitor in settings.json:

{
  "monitors": {
    "myDomain": {
      "name": "MyDomainXYZ",
      "method": "HEAD",
      "url": "https://mycooldomain.xyz/reachability",
      "timeout": 10000,
      "interval": 5000,
      "response": 204
    }
  }
}

This configuration involves sending a HEAD request to the specified URL every 5 seconds and measuring the response time. The expected response is a 204 status code, but if there is no response within 10 seconds, the server will be considered 'down' and the request will be aborted.

It is important to note that using other request methods besides HEAD may take longer to process and could potentially consume more server resources.

Step 2 - Create Collections

To send data to the client and persist it between server restarts, two MongoDB collections are required: one to preserve the overall monitor status and another to store the summary of each request as a document.

Create both collections in /imports/collections/MonitorCollection.js and /imports/collections/StatusCollection.js:

import { Mongo } from 'meteor/mongo'
export const MonitorCollection = new Mongo.Collection('monitor')

import { Mongo } from 'meteor/mongo'
export const StatusCollection = new Mongo.Collection('status')

They will be used later to automatically sync the data from the server to the client using "publish/subscribe".

Step 3 - Create a Handler for the Collections

Instead of directly accessing the collections we actually want to control inflow and outflow of data. For this we create a Monitor object in server/Monitor.js, that will manage all this for us.

import { Meteor } from 'meteor/meteor'
import { MonitorCollection } from '../imports/collections/MonitorCollection'
import { StatusCollection } from '../imports/collections/StatusCollection'

export const Monitor = {}

First, we want to be able to initially create a status for a configured domain, so that it's status/info is available, even if we haven't fired a request yet:

// ... continue in server/Monitor.js

Monitor.init = async ({ name, url, method, interval }) => {
  return StatusCollection.upsertAsync({ name }, {
    $set: { name, url, method, interval } 
  })
}

This will also update the status, in case we changed our configuration in settings.js.

Okay, now let's think about what we actually want to measure. We need a name as key, a timestamp of the request, a duration, a hasTImedOut flag and an error, in case we want to read error details.

Furthermore, we want to update status only once it has changed and not every time a new document arrives. A simple first implementation could look like this:

// ... continue in server/Monitor.js

Monitor.add = async document => {
  const { name, hasTimedOut, duration, error } = document
  const status = await StatusCollection.findOneAsync({ name })
  let statusChanged = false

  // we just went down :-/
  if (status.up && hasTimedOut) {
    status.up = false
    statusChanged = true
  }

  // we're back in business :-)
  if (!status.up && !hasTimedOut) {
    status.up = true
    statusChanged = true
  }

  if (statusChanged) {
    console.debug('[Monitor]: status changed:', status)
    await StatusCollection.updateAsync(status._id, { $set: status })
    // here is a good spot to send an Email to
    // inform about the status change!
  }

  await MonitorCollection.insertAsync(document)
}

Finally, we want to define the amount of data, send to the client. We do this by defining Meteor Publications. On the one hand, we want to publish the status of the monitor as a single document:

Meteor.publish('status', function ({ name }) {
  return StatusCollection.find({ name },  { limit: 1 })
})

On the other hand we want a good bunch of request summaries, that will help us to build a nice graph of the uptime and response duration:

// ... continue in server/Monitor.js

Meteor.publish('monitor', function ({ name }) {
  return MonitorCollection.find({ name }, { limit: 250, hint: { $natural: -1 }})
})

Note the hint: { $natural: -1 } which tells the collection to so a natural backwards search (start with the newest entry), omitting the need for sort.

Step 4 - Create an Uptime Request

Now, that we have set up a collection management, we still need a handler that fires and evaluates our requests by our given configuration.

For this we create a class this time. Create a new file server/UptimeRequest.js and start with the following:

import { fetch } from 'meteor/fetch'
import { AbortController } from "node-abort-controller"
import { PerformanceObserver, performance } from 'node:perf_hooks'

export class UptimeRequest {
  constructor ({ name, method, url, timeout, response }) {
    // config
    this.name = name
    this.method = method
    this.url = url
    this.timeout = timeout
    this.expectedResponse = response
    this.actualResponse = null

    // results / measurements
    this.response = null
    this.timestamp = null
    this.performance = null
    this.error = null
    this.hasTimedOut = null
    this.response = null
  }

  async fire () {
    // here we implement the actual request
    // and measure the outcome
  }

  toDocument () {
    // here we will return results that matter
  }
}

As you can see there is no interval as this class will be instantiated each time for a new request, thus one instance represents one request.

Let's implement the fire method:

//... in the UptimeRequest class

async fire () {
    this.timestamp = new Date()

    // prepare performance measures
    // see https://nodejs.org/api/perf_hooks.html#performanceentryduration
    const observer = new PerformanceObserver((items) => {
      items.getEntries().forEach((entry) => {
        this.performance = entry
      })
    })
    observer.observe({ entryTypes: ["measure"], buffer: true })

    const start = `${this.name} - start`
    const ended = `${this.name} - ended`
    const controller = new AbortController()
    const options = {
      method: this.method,
      priority: 'high',
      redirect: 'error',
      signal: controller.signal
    }

    const timeout = setTimeout(() => {
      this.hasTimedOut = true
      controller.abort()
    }, this.timeout)

    try {
      performance.mark(start)
      this.response = await fetch(this.url, options)
    } catch (error) {
      this.error = error
    } finally {
      performance.mark(ended)
      clearTimeout(timeout)
      performance.measure(this.url, start, ended)
      observer.disconnect()
    }

    this.actualResponse = this.response?.status

    // post checkup
    if (!this.error && this.response.status !== this.expectedResponse) {
      this.error = new Error('Response code mismatch')
    }

    // normalize error
    if (this.error) {
      const error = {}
      Object.getOwnPropertyNames(this.error).forEach(prop => {
        error[prop] = this.error[prop]
      })
      delete error.stack
      this.error = error
    }
  }

// ...

Without going into too much details, this method creates a fetch request with a so called AbortSignal that aborts the request, once our given timeout has been exceeded. On top it's surrounded by Node's native performance measurement to measure the overall request-response duration.

You can read up everything that happens in this method using the following resources:

Finally we want to provide a summary as document to the outside consumers by implementing a simple toDocument method:

//... in the UptimeRequest class

  toDocument () {
    return {
      name: this.name,
      response: {
        expected: this.expectedResponse,
        actual: this.actualResponse,
      },
      fired: this.timestamp,
      duration: this.performance?.duration ?? 0,
      hasTimedOut: !!this.hasTimedOut,
      error: this.error
    }
  }

// ...

Step 5 - Server Startup

We can finally run our server-side code that will request the external server and saves the results and status in the database. For this, remove all code in server/main.js and replace it with this one:

import { Meteor } from 'meteor/meteor'
import { UptimeRequest } from './UptimeRequest'
import { Monitor } from './Monitor'

Meteor.startup(async () => {
  const { myDomain } = Meteor.settings.monitors

  await Monitor.init(myDomain)

  const monitor = async () => {
    const request = new UptimeRequest(myDomain)
    await request.fire()
    return Monitor.add(request.toDocument())
  }

  Meteor.setInterval(monitor, myDomain.interval)
})

On startup we first register or update our domain (see the Monitor.init method in step 1.3) and then run a request for each interval, adding the result to the collections and updating the status.

Step 6 - The Monitoring Frontend

The client part is much shorter and will actually fit in one step. This is, because here it combines the magic of Meteor's reactivity together with the magic of Plotly's auto-generation of charts, just to save you hours and hours of coding! 🧙‍♂️

For this you only need to change the file imports/ui/App.jsx to the following:

import React from 'react'
import { MonitorCollection } from '../collections/MonitorCollection'
import { StatusCollection } from '../collections/StatusCollection'
import { useTracker, useSubscribe, useFind } from 'meteor/react-meteor-data'
import Plot from 'react-plotly.js'

const name = 'MyDomainXYZ'

export const App = () => {
  // subscribe to status, call
  // statusLoading() to know if it's loading or not
  const statusLoading = useSubscribe('status', { name })

  // subscribe to monitor docs,
  // use monitorLoading() to know if it's loading or not
  const monitorLoading = useSubscribe('monitor', { name })

  // the actual status doc, which will be undefined,
  // as long as the subscription is still loading
  const [status] = useFind(() => StatusCollection.find())
  const [uptime, duration] = useTracker(() => {
    const docs = MonitorCollection.find({}, {
      // make sure the client sorts the docs,
      // in case they arrive in a different order
      // than the server queried them
      sort: { fired: 1 }
    })
    const updatime = {
      x: [], // doc index as Date
      y: [], // up or down
      type: 'scatter'
    }

    const duration = {
      x: [],
      y: [],
      type: 'scatter'
    }
    docs.forEach((doc, index) => {
      updatime.x.push(doc.fired)
      duration.x.push(doc.fired)

      updatime.y.push(doc.hasTimedOut ? 'down' : 'up')
      duration.y.push(doc.hasTimedOut ? 0 : doc.duration)
    })
    return [updatime, duration]
  }, [])

  return (
    <div>
      <h1>Uptime Monitor for "{name}"</h1>
      <StatusInfo status={status} loading={statusLoading() || monitorLoading()}/>
      <Plot data={[uptime]} layout={{ width: 800, height: 400, title: 'Uptime' }} config={{ responsive: true }}/>
      <Plot data={[duration]} layout={{ width: 800, height: 400, title: 'Duration' }} config={{ responsive: true }}/>
    </div>
  )
}

// pure component, could be used with memo
const StatusInfo = ({ status, loading }) => {
  if (loading || !status) return (<div>Status loading...</div>)

  return (
    <div>
      <span>Status: {status.up ? 'up' : 'down'}</span><span> | </span>
      <span>URL: {status.url}</span><span> | </span>
      <span>Method: {status.method}</span><span> | </span>
      <span>Interval: {status.interval / 1000}s</span>
    </div>
  )
}

The result are two line-graphs that update every 5 seconds, as defined in our config:

The magic behind this very short code is actually the hooks, provided by the react-meteor-data package, which is already included in every new Meteor-React project. Here are some excerpts:

`useTracker`

You can use the useTracker hook to get the value of a Tracker reactive function in your React "function components." The reactive function will get re-run whenever its reactive inputs change, and the component will re-render with the new value.

To provide some more context: This hook uses Meteor's Tracker to listen on changes in a Data-set, such as our two collections. Under the hood there is an observer that runs, every time a document is added, removed or updated on this collection, invoking a Tracker computation, which in turn invokes a new React computation, similar to what you already know from other React hooks.

`useSubscribe`

At its core, it is a very simple wrapper around useTracker (with no deps) to create the subscription in a safe way, and allows you to avoid some of the ceremony around defining a factory and defining deps. Just pass the name of your subscription, and your arguments.

`useFind`

The useFind hook can substantially speed up the rendering (and rerendering) of lists coming from mongo queries (subscriptions). It does this by controlling document object references. By providing a highly tailored cursor management within the hook, using the Cursor.observe API, useFind carefully updates only the object references changed during a DDP update.

Where to go from here

The app in this tutorial is far from complete. However, I compiled a few ideas for your next steps with this one:

update to Meteor 3.0 and deploy to an ARM device like a Raspberry PI (we may cover this in the future if demand is high)
deploy your app to Meteor Cloud (managed hsoting) or your own infrastructure using Meteor-Up
extend the app to monitor multiple clients
use a job / cron-job library, instead of setInterval
create a dashboard for your monitors
add Meteor Accounts to manage users, authentication etc.
improve the Plot layouts and make them visually more appealing
use caching and capped collections or redis-oplog for scaling

About me 👋

You can also find me (and contact me) on GitHub, Twitter/X and LinkedIn.

If you like what you read and want to support me, you can sponsor me on GitHub, send me a tip via PayPal or sponsor a book from my Amazon wishlist.

Dead or not dead 💀 - Exploring the term and why Meteor.js is super-alive! ☄️

Jan Küster 🔥 — Tue, 16 Jan 2024 12:47:15 +0000

I recently picked up a comment on Reddit that directly feeds into the never-ending "Meteor is dead" ~~FUD~~ talk. Usually, I immediately join these kinds of conversation and beam a huge list of facts straight into the heads of them peoplezzZz to prove a point. 🛸

Well, this time I thought different. Let's skip this highly annoying type of interaction and cover the "dead debate" beyond Meteor.js and on a much deeper level. 🤯

Don't worry, as the end of the article will still contain all the facts on Meteor.js, so next time I can beam the article into them brainzzZz. 🛸

‼️Trigger warning‼️ The following article includes themes and topics about death that go beyond the realm of software engineering and web development.

Dead or not dead? 💀

We all know, in JavaScript there is only hype-driven-development (hdd) as the one and only methodology to rule them all. If you don't ride the hype-train then you're dead. Thankfully, this is just a superstition and far from being correct. However, many users feel the JS ecosystem is moving very fast and new tools emerge on a weekly basis.
If your software can't keep up with and ride the hype-train constantly then it becomes dead, right?

Well, it's not that easy. The term "xyz is dead" can actually refer to many more things than that and it also depends on the context and the intention of the person who used it.

At this point we can't clearly say what "dead" means to a software, as there is no generally agreed definition for it.

However, I don't want to go any further without a clear definition of what "dead" actually should refer to, when speaking about software, tools and frameworks.

When we should NOT consider a software as "dead" 😇

The great part of this is, that there is already an article that unwrapped this question in an amazing way. I highly suggest you to read on "What do we really mean when we say that software is ‘dead’ or ‘dying’?" by Richard Gall, before continuing to read. It perfectly summarizes misconceptions about software being considered "dead".

Furthermore, the concept of "dead" seems to be used too often in order to coin less popular or aged software as being not usable or that it should be avoided without reasoning why. If objectively evaluated, some of the software/libraries coined as "dead" are actually far from it.

Famous examples in web development

jQuery

considered unpopular
active releases
>2m installs)
constant development since 2006(!)

ember.js

interest declined
however, well matured and far from being dead

less

lost the battle to scss
still over 4m weekly installs)
active development, although with pauses but nothing indicating death

Interesting fact: the famous state of js survey dropped the term "avoid" and replaced it by "harder to recommend currently", when categorizing libraries into quadrants

When we should consider a software as "dead" 😵

I believe, that we can validly categorize a software as "dead" or "alive", if there would be clear list of criteria for it.

For this, let me bring in some context from the real life: We have various concepts of someone being dead: clinically dead, brain death, legal death, biologically dead. For clinical death, there are specific criteria for physicians to diagnose the death of a person (without doubt). They may vary by country or even by state but in general they are very clear and unambiguous factors.

Of course, there are fundamental differences between humans and software:

humans can live on their own, software always needs at least one external entity to advance any step in the lifecycle; not considering the whole AI debate here 🧐
humans have a limited time for reanimation (the time from cardiac arrest to severe organ damage); software can be reanimated at any time
humans who are lost cannot be restored, rebuild or reverse engineered; software can; not considering the whole trans-humanism debate here 🧐

From the above factors we can now build a very clear

Clinical Software Death

A software can be considered as "dead" when the following factors are fulfilled:

the software is confirmed to be "abandoned", "archived" or any other form of "active development stopped" by it's owners

the software is in one of the following states:

it's non-functional (has critical bugs; memory leaks; critical performance issues)

it's incomplete (missing critical features)

it's vulnerable (security; dependencies)

chances are low for any considerable effort to change these two factors

The status of being "dead" is not fixed and can change, if one or more of the above factors change for the positive.

In an early version of the article I listed two projects here on the verge to death. However, they were still alive and as I know from the debate around "Meteor.js is dead" this would only create FUD. In contrast I advise you kindly to use the above list and do your check-marks on some projects you personally consider(ed) dead.

My 2cents on this 🪙

I found the whole topic becoming increasingly morbid the more I dealt with all these death themes and criteria. Due to this, I even dropped some sections (e.g. about "Zombieware" as it became ridiculous 🧟‍♂️🧟‍♂️🧟‍♂️).
I also think this whole death theme is a fundamental consequences of the negative framing of "is XYZ dead?". The question already sets a negative foundation for the whole upcoming debate, where proponents become highly defensive (often seen and sometimes practiced myself), while opponents may use invalid arguments ("nobody uses xyz today") or even become offensive. 🤬

I would even go that far to say, that if such a question is deliberately used to undermine the credibility of whatever software, then it could be described as dead-framing.

A change in perspective 🔭

Instead of this, I propose that everyone rethinks this terminology. We have seen, that a clinical software death is very rare (at least of you read the linked article above). A better alternative would be to ask

How alive is software/tool/framework xyz?

On the one hand, this question would not frame the involved software in a negative way and criticism on the software will not sound immediately offensive.

At the same time it allows for a more distinct evaluation, because it's an open question that cannot be answered with a simple "yes, because..." or "no, because...". Let's all consider this for the next time. ❤

Finally, at this point I'd love to transit over to the Meteor.js part of the article.

How alive is Meteor.js? ☄️

TL;DR: it's very alive and has never been dead (trust me, bro) but you better be reading the facts! 🛸 This part might also be interesting to you, in case you want to evaluate Meteor.js as your next fullstack development platform.

Meteor Software - Build with Meteor.js, deploy on GalaxyThe full-stack JavaScript framework for real-time apps - Meteor.js

Meteor.js is an open source platform for building Web, Mobile, and Desktop applications.

meteor.com

Let's get back to the initial topic that inspired me to write this article. For this I will check the current state of the Meteor.js ecosystem against the above criteria for clinical software death.

Ownership and Company backing 👔

For a project to not being abandoned there needs to be an owner that is present and reachable. For Meteor this is currently Meteor Software. They took over the ownership, when Tiny Capital acquired Meteor from Meteor Development Group (MDG) in 2019.

The company has currently 12 employees, working on the Meteor.js core, packages, documentation and the community around it. The team distributes across the globe with a great portion being located in Brazil. Furthermore, Meteor Software operates on providing cloud services around the Meteor.js platform, so they have an ongoing interest in it being continuously "alive and well".

Meteor.js core development ⌨️

meteor / meteor

Meteor, the JavaScript App Platform

Meteor is an ultra-simple environment for building modern web applications.

📚 Create your applications using modern JavaScript

Benefit from the latest technology updates to rapidly prototype and develop your applications.

✨ Integrate technologies you already use

Use popular frameworks and tools right out-of-the-box. Focus on building features instead of configuring disparate components yourself.

💻 Build apps for any device

Use the same code whether you’re developing for web, iOS, Android, or desktop for a seamless update experience for your users.

🔥 Getting Started

How about trying a tutorial to get started with your favorite technology?

React
Blaze
Vue

🚀 Quick Start

On your platform, use this line:

> npx meteor

🚀 To create a project:

> meteor create

☄️ Run it:

cd my-app
meteor

🧱 Developer Resources

Building an application with Meteor?

Deploy on Galaxy
Discuss on Forums
Join the Meteor Discord by clicking this invite…

View on GitHub

The Meteor.js core platform is developed by the Meteor Software team on GitHub. There is a constant stream of commits since it's initial work in Nov. 2011. Also, contributions never really stopped, as you can also see in the following contribution graph
from the GitHub repository:

Integrations with popular tools and libraries 🔨

Meteor officially supports various popular frontends and technologies.

React (default)
Blaze (Meteor's original frontend)
Vue 3 + vite
Vue 2
Svelte
Solid
Chakra-UI
TypeScript
Tailwind
Apollo

Official support means, that there are ongoing commits in the repo to ensure these integrations into the stack and their documentation are up-to-date.

Use meteor create with options from the above list and try out a new project and see for yourself! You can also find the source for these commands in the respective skeleton projects.

Meteor.js package ecosystem and package development 📦

Meteor.js is built on top of Node.js and is fully compatible to packages you can find in the NPM registry. Some packages of Meteor core are also NPM packages.

However, during early days of Meteor.js an own package ecosystem emerged in order to provide zero-config integration with Meteor, MongoDb, Tracker, compilers and many more from the platform.

There are 14,646 packages available for Meteor.js as of today. Packages get constantly published by users and there is also Meteor-Community-Packages (MCP), a GitHub org under which very popular / widespread packages are kept maintained or improved with new features.

Community Activity 🤝

Meteor has an active community of developers, individual as well as institutional.

Communication heavily resides around the Meteor forums which contains a stream of topics up until back to 2014/2015 (31.3k topics with 217K posts overall as of today). Some members from that time are still active there as well.

Additionally there are active Slack and Discord spaces as well. Many of the packages beyond Meteor-Community-Packages are actually developed and published by members of the Meteor.js community.

Conclusion ✅

the software is confirmed to be "abandoned", "archived" or any other form of "active development stopped" by it's owners

Not at any time, as you can see in the repository and its commit history.

the software is in one of the following states:

it's non-functional (has critical bugs; memory leaks; critical performance issues)

it's incomplete (missing critical features)

it's vulnerable (security; dependencies)

A project of this size and in constant development will always contain one or more of the above as it hardly becomes "feature complete" as opposed to packages or small libraries. For Meteor.js you can see 222 open issues as of today, which reside around these topics. Most of them are related to "it's incomplete" as Meteor currently does a transition to a new Major version.

chances are low for any considerable effort to change these two factors

If development would stop or be dropped by Meteor Software chances are very high that the community will jump in and continue development.
Additionally, there are various companies running a business on top Meteor apps, which will make it more likely ongoing development is ensured.

Disclaimer 🧐

I have to state a disclaimer here for those among y'all, who are already throwing the "full circle" argument at me. 🍅
Yes, I created the definition myself and applied it to the Meteor.js framework and it's all working out positive. However, I tried to be as objective as possible when creating criteria for a definition. I think I came up with one, you could also apply to any other project. And yes, the majority of evaluated software would not be considered dead, according to this criteria. That's the whole point.

Anyway, I'm also open for improvements of the criteria as my final goal is to either rationalize the term "dead" when speaking about software or even getting rid of it at all! In the end it's all about tools getting the job well done for their purpose. Personal opinions and preferences should be secondary to this.

About me 👋

I regularly publish articles here on dev.to about Meteor.js and JavaScript. Recently I also co-host the weekly Meteor.js community podcast, which contains the newest from Meteor.js and the community.

You can also find (and contact) me on GitHub, Twitter/X and LinkedIn.

If you like what you are reading and want to support me, you can sponsor me on GitHub, send me a tip via PayPal or sponsor me a book form my Amazon wishlist.

Gradually upgrading a Meteor.js project to 3.0

Jan Küster 🔥 — Fri, 15 Dec 2023 12:28:47 +0000

TL;DR - In this first part of the Migration series we will start upgrading an existing Meteor.js project to 3.0 (alpha). We will be using a determined strategy that should apply to any existing Meteor.js project. Focus is fixing dependency conflicts during the update process.

Follow-up articles will show how to fix dependencies (packages and build-tools) by example 💪

What is Meteor.js 3.0 and why should I care? ☄️
- Meteor 3.0 is still in Alpha, why doing this now? 🧐
- Biggest challenges while migrating to 3.0 🏗️
A Generic Migration strategy 🧩
- Part 1 - Preparations 📝
- Part 2 - updating to 3.0 and dependency triage 🔬
- Part 3 - Fixing a dependency 🔥
- Part 4 - migrate your project code ⌨️
- Step 5 - deployment 🚀
Summary and Outlook 🔭
About me 👋

What is Meteor.js 3.0 and why should I care? ☄️

If you already know about Meteor's next major version then you can safely skip this section.

Meteor.js 3.0 is an upcoming major release. The platform is moving away from Fibers (coroutines) in favor of Node's native async-await implementation. The reason behind this step is, that Fibers are not compatible anymore with Node (add links here), beginning with version 16. Due to this circumstance, Meteor is stuck in at Node 14 and this brings lots of implications (security, maintenance, being up to date etc.) for any developer and company.

meteor / meteor

Meteor, the JavaScript App Platform

Meteor is an ultra-simple environment for building modern web applications.

📚 Create your applications using modern JavaScript

Benefit from the latest technology updates to rapidly prototype and develop your applications.

✨ Integrate technologies you already use

Use popular frameworks and tools right out-of-the-box. Focus on building features instead of configuring disparate components yourself.

💻 Build apps for any device

Use the same code whether you’re developing for web, iOS, Android, or desktop for a seamless update experience for your users.

🔥 Getting Started

How about trying a tutorial to get started with your favorite technology?

React
Blaze
Vue
Svelte

Next, read the documentation and get some examples.

🚀 Quick Start

On your platform, use this line:

> npm install -g meteor

🚀 To create a project:

> meteor create my-app

☄️ Run it:

cd my-app
meteor

🧱 Developer Resources

Building an application with Meteor?

Deploy…

View on GitHub

However, this transition to async-await comes with a massive impact on the very core of Meteor's execution model: In the past you were able to write sync-style code for async operations, for example a MongoDB-Collection fetch:

const document = MyCollection.findOne({ title: 'foo' })

This MongoDB operation has always been async in nature, but Meteor used Fibers to keep track of thing in a way, that the above code resolved without the need of Promises or async/await. In 3.0 operations like these will be replaced by they native Promise implementations and therefore require to be awaited:

const document = await MyCollection.findOneAsync({ title: 'foo' })

This implies a necessary upgrade for every Meteor.js project out there.

Meteor 3.0 is still in Alpha, why doing this now? 🧐

Depending on the size of your project and your team being able to work on such an upgrade you will face challenges on a varying scale and this article should help you to get a first glimpse on the upcoming effort.

This will also help you to make a much better estimation with regards to the complexity and effort of the upcoming migration.

The API of the Alpha versions is 99% stable and most development resides around details or bugs. You can therefore safely start upgrading and refactoring, while you later will only have to switch from Alpha to the stable release.

I have already compiled some steps for preparing your existing projects that won't require an update to 3.0 yet:

Prepare your Meteor.js project for the big 3.0 release!

Jan Küster ・ Nov 1 '23

#meteor #javascript #webdev

Biggest challenges while migrating to 3.0 🏗️

From my current efforts I could compile a short but fundamental list of challenges and their manageability:

Challenge	Manageability
Direct dependency conflicts	Easily manageable for your own packages; requires manual fixing for third-party packages
Indirect dependencies version conflicts	Will definitely require manual cloning and fixing
Build tools	Will depend on the complexity of the plugin; will require manual fixing
Breaking Isomorphism	Manageable with big efforts; may require major architectural changes, depending on how much your projects rely on isomorphic code
Rewrite code to use async/await	Involves effort but manageable; read the official docs and my article on this topic for more info
Deployment	Managed for you, when using Galaxy; effort when doing custom deployment; for example with MUP; involves finding correct images, may require to build custom images

As you can see the actual change in your project's code is just a small portion of the overall challenges. This is why this article series tries to deal with all the other parts of it.

A Generic Migration strategy 🧩

My goal for this article was to provide a generic strategy that any of us could apply on their existing projects. Of course, the effort and complexity will vary but the overall procedure should work for anyone. A good approach is to start with a smaller project to get used to the process. Once you succeeded there you will already know most of the intricacies in order to be ready for your larger projects.

This strategy involves using git and assumes to commit often in order to being able to revert to the state of the last step/substep. This will apply for the project, as well as for cloned dependencies. The following example shows how to hard-revert to a certain commit hash:

# show the full list of commits on this branch
$ git log
 commit 126669f9b29f9172bea4ebaf0599670bd4493f03 (HEAD -> migrate-3.0, origin/master, origin/HEAD)
Merge: a8ac876 7dc118a
Author: Jan Küster <info@jankuester.com>
Date:   Mon Nov 28 16:37:38 2023 +0200

    migration(1.2): prepared project structure
# reset to the latest commit, omit anything newer than this commit
$ git reset --hard 126669f9b29f9172bea4ebaf0599670bd4493f03

The following is a high-level overview of the strategy

Part 1 - Preparations 📝

1.1 Work on an exclusive branch

commit any remaining changes
checkout your most recent development branch
checkout a new branch, exclusively to migration towards 3.0: git checkout -b migrate-3.0

1.2 Prepare project structure for fixing dependency conflicts

if project is in top-level
- create a new folder src and move project files in this folder
- keep all Git-related files in top-level
create a lib folder in top-level (next to src) where all package-repos will be cloned, that may contain multiple packages or nested structures (see this example)
create packages folder for package-repos that have a direct structure (see this example)
commit your state

1.3 Upgrade to latest 2.x

run meteor update --release=2.13.3 (or newer; see the changelog)
if this causes issues you have to fix them first (out of scope; see the migration notes on the specific versions in the docs)
commit your state

Optional:

place `jkuester:migration-helper (after all core-packages, but before all non-core packages)
flag all non-core packages as # fixme:async that use sync mongo/cursor calls or create sync style methods/publications
more at my previous article Prepare your Meteor.js project for the big 3.0 release!

1.4 Prepare next update to 3.0

Clear any caches of package version
- clear all entries .meteor/versions file
- remove .meteor/local folder
- comment all packages, expect core packages in .meteor/packages
- remove @ suffix from all entries
commit your state

Part 2 - updating to 3.0 and dependency triage 🔬

Important note

During this phase you will often have to run/rerun the app in order to see which dependencies cause a conflict. However, since many of your packages are commented you should not expect the app to successfully start. You will likely then encounter other errors. But that's not the point of this step, it's only about resolving dependency conflicts.

2.1 Update only with core packages

run update meteor update --release=3.0-alpha.19
all core packages should have upgraded successfully and there should be no error message, involving version conflicts (other errors are to be expected, though)
if there is a version conflict, then
- make sure the packages left uncommented in this step were only core packages!
- comment all core-packages that are involved with the conflict and flag them as fixme:core
- if you are 100% sure this is a core-package problem then open an issue in the Meteor GitHub repository
- best would be to also add the issue link to the comment flag: fixme:core (link to issue)
- if you are < 100% sure then reach out to the community on the Forums, Slack or Discord
else commit your state

2.2 Uncomment non-core packages stepwise (loop)

uncomment a single non-flagged non-core package
try to rerun the app
if this package cause a version conflict
- comment and flag as fixme:deps
- Proceed with step 3 for this package
else commit your state
if there are commented packages left in .meteor/packages then proceed with Step 2.2
else proceed to step 4

Part 3 - Fixing a dependency 🔥

This step has the scope of a single dependency (package or build tool).

3.1. Determine the package's location

if it's one of your local packages then keep it in it's place
else look up the package name on Packosphere
look for the GitHub link on the package's page and navigate to the repository
- if this package contains no GitHub repository link then you need to contact the owner to open this package or provide an upgrade, you may also seek help in the community
fork the repository
check the folder structure and determine, whether to place it in packages (proceed with 3.2) or in lib (proceed with 3.3)

3.2. Clone the package into `packages`

select the green button in the repo (labelled "code") and select the repo link (favorably ssh)
cd into the packages folder
run git clone <link>
cd into the new cloned package
run git checkout -b migrate-3.0
if you get fatal: A branch named 'migrate-3.0' already exists. then you are still in the packages folder!

3.3. Clone the package into `lib`

select the green button in the repo (labelled "code") and select the repo link (favorably ssh)
cd into the lib folder
run git clone <link>
cd into the new cloned package
run git checkout -b migrate-3.0
if you get fatal: A branch named 'migrate-3.0' already exists. then you are still in the top-level folder!
now you need to link the content of this package (or a subdirectory of the package) with your packages folder
cd back into src/packages
link using ln -sf ../../lib/<repo-name>/path/to/package

3.3 Fixing the package versions

open package.js in your editor/IDE
fix api.versionsFrom, it should look something like api.versionsFrom(['2.8', '3.0-alpha.19'])
search for further dependencies that caused confwhat-is-meteorjs-30-and-why-should-i-care-licts
fix their required dependency version, for example api.use('minifier-css@1.6.0 || 2.0.0-alpha300.19')
continue with all dependencies in this file until no conflicts occur
commit this state in the package
commit this state in your project

3.4 Fixing the package's code to use async-await

It might be a good opportunity to review the package's code for usage of being involved in any MongoDB Collection or Cursor activity or any imports of 'fibers/future' or Promise.await inside the package's code. If any of them is the case then you will have to migrate this code as well, in order to have the package function properly.

It might be exhausting to realize that the package you used for years and which ran fine now of sudden needs thewhat-is-meteorjs-30-and-why-should-i-care-se big changes. You have basically three options now:

A) find a replacement (causing your project code to be rewritten to the new package's api)
B) contact the package maintainer (can take from a day to infinity to be fixed)
C) do it on your own (involves effort but you are in control of the situation)

This step assumes you go with option C and the follow-up articles will deal with this situation in detail.

3.5 post-fix cleanup

you may have to update the package's tests as well
document and commit your changes
push to your fork git push origin migrate-3.0 while being in the package repository folder
If you want to make this fix available for others then I encourage you to open a pull request

Part 4 - migrate your project code ⌨️

At this step you should have resolved all dependency conflicts and committed the current state.
If not, make sure this is the case, in order to being able of reverting to the state of this commit at any time.

This is the time where your own project code is to be migrated. In an optimal world you may have done this already when being on Meteor 2.x. If you didn't, worry not! 🧙‍♂️

Here are a few important resources, that might help you to advance in your own code migration:

Guides on upgrading to async/await

The following link should help you with the majority of issues when migrating your projects.

How to migrate to Meteor Async in Meteor 2.x | Meteor Guide

How to migrate your application to async methods and be ready to 3.0.

guide.meteor.com

Migrating to Meteor 3.0 | Meteor Guide

How to migrate your application to Meteor 3.0.

guide.meteor.com

Prepare your Meteor.js project for the big 3.0 release!

Jan Küster ・ Nov 1 '23

#meteor #javascript #webdev

Help and support for your upgrade process

Engage with the Meteor community if you're getting stuck or if you want to share your migration success or if you simply want to get in touch with fellow Meteor developers.

Background topics

If you are interested in the more technical reasons behind this whole migration topic when you might want to check out these links.

Original discussion about how Meteor should execute native async/await

Part 5 - deployment 🚀

You are finished with your migration and your project runs fine, including all tests. That's awesome! 💪
However, now it's time to get this up and running on the target infrastructure

Deploying a Meteor app can be done in multiple ways but you have to be aware that your deployment environment is 3.0 ready!

Hosting on Galaxy

First of all, there is Meteor Cloud, the official hosting platform (formerly known as Galaxy) by Meteor Software, the company backing the Meteor.js ecosystem and core contributors to the Meteor.js open source repository.

With the Meteor Cloud managed services you will already face a Meteor 3.0-enabled environment and you can easily deploy your app in one command. You can try their services with the free plan, perfectly suitable for demos, MVP or proof of concepts.

Deployment to Galaxy is a no-brainer, either via a single cli-command or automated via push-to-deploy. You can read it all up in the deployment guide:

Deploy to Galaxy | Galaxy Docs

Learn how to deploy on Galaxy by setting up Push to Deploy. The easiest and fastest way of deploying your Meteor app.

galaxy-guide.meteor.com

Custom Hosting using Meteor-Up (MUP)

For those who need alternatives, for example hosting on-premise, there is a great tool out there that simplifies the deployment process a lot: Meteor-Up

meteor-up.com

zodern / meteor-up

Production Quality Meteor Deployment to Anywhere

Meteor Up

Production Quality Meteor Deployments

Meteor Up is a command line tool that allows you to deploy any Meteor app to your own server.

You can install and use Meteor Up on Linux, Mac and Windows. It can deploy to servers running Ubuntu 14 or newer.

This version of Meteor Up is powered by Docker, making deployment easy to manage and reducing server specific errors.

Read the getting started tutorial.

Features

Single command server setup
Single command deployment
Deploy to multiple servers, with optional load balancing and sticky sessions
Environment Variable management
Support for settings.json
Password or Private Key (pem) based server authentication
Access logs from the terminal (supports log tailing)
Support for custom docker images
Support for Let's Encrypt and custom SSL certificates

Roadmap

Server Configuration

Auto-restart if the app crashes
Auto-start after server reboot
Runs with docker for better security and isolation
Reverts to the…

View on GitHub

With this option you are entirely free to choose where your Meteor apps will run. Of course, this also brings the duties to manage the entire infrastructure on your own.

Furthermore, you will have to get deeper into Docker and Images in order to be able to successfully deploy your 3.0 app using MUP.

Summary and Outlook 🔭

With this article you were given methods and resources to migrate your app towards Meteor 3.0 with a big focus on resolving dependencies.

If you have any questions or trouble with any step of this process, please don't hesitate to share it in the comments or get in contact with the community:

In the next article I will demonstrate the migration process from 2.x to 3.0 with an example app that runs into some dependency conflicts. Together we will solve these conflicts, fix up the code and make the app run again but on the latest 3.0 alpha version.

About me 👋

You can also find (and contact) me on GitHub, Twitter/X and LinkedIn.

If you like what you are reading and want to support me, you can sponsor me on GitHub, send me a tip via PayPal or sponsor me a book form my Amazon wishlist.

Prepare your Meteor.js project for the big 3.0 release!

Jan Küster 🔥 — Wed, 01 Nov 2023 11:04:21 +0000

Meteor.js 3.0 is an upcoming major release with lots of breaking changes. The platform is moving away from Fibers to use Node's native async await implementation.

In this article I'm going to show you a few techniques to detect code that requires changes in order to be ready for this upcoming Meteor.js 3.0 release. 🧙‍♂️

Photo by Susan Q Yin on Unsplash

Note, that this will not be a complete or perfect analysis, because you may end up with some false-positives or missing pieces. Consider it as a helping hand to aid the start for the transition. 🤝

Another primary goal is to be non-intrusive to your current application. This means, there should be no breaking effect to your current application by implementing the techniques, presented in this article.

This is important, because any breaking effect (server crashes etc.) creates frustration and decreases the chance of people finally starting to migrate now.

Background / why this is important? ☝

If you know all about Meteor.js 3.0 then you can safely skip this section.

Meteor.js is around for over 10 years now, and it's core API-structure did not change significantly. I previously showed this in another article on migrating an ancient Meteor.js project.

However, while Meteor.js pioneered the fullstack technologies until about 2016 it eventually lost its amazing momentum in about 2017 (read here on the why and how).

The JavaScript ecosystem evolved and like in the cambrian explosion we saw a multitude of tools, frameworks and libraries emerging.
A vast majority seemingly adopted the async/await pattern,
while asynchronous code execution in Meteor.js was implemented using coroutines via Fibers.

Finally, the release of Node 16 became basically incompatible with fibers and thus, Meteor.js got stuck on Node 14. This implied a major rewrite of a large potion of the platform's internals as it all depended on fibers. Further, it implied that all Meteor.js projects and packages required a major rewrite as well.

This is where YOU come into play.

How do I know, if I need to migrate? 🤔

This answer is simple: you will have to! 🤓

This is, because all pre-3.0 projects run on a security-patched Node 14 (read here how to apply the patched version) and you will need Meteor 3.0 to be back on the safe side of the Node game by being able to use the latest Node LTS for your deployments.

How do I know what to migrate? 🤔

This is a rather complex situation with no simple answer. There are basically three big parts of your codebase to review:

Mongo Collection and Cursor usage
Meteor Methods + Publications
Meteor Packages that depend on the "old" code style

There is also an official list of core functionality that
is to be migrated. It's part of the "How to migrate to Meteor Async in 2.x" guide.

Each of these come with a different approach, different complexity and constraints. Implementation also varies, whether a static analysis is desired or if runtime analysis is okay, too. Let's take a look at each of them, one by one.

Mongo Collection and Cursor usage 💽

In classic mode (using fibers) the Mongo collection calls to the MongoDB driver were executed within a Fiber and thus could be written in sync-style code, while being magically async under the hood:

const document = collection.findOne({ foo: 'bar' })

In the new async mode (using async/await) we need to change this to an async counterpart:

const document = await collection.findOneAsync({ foo: 'bar' })

This change targets the following Mongo.Collection methods:

Class mode	Async Mode	Notes
`insert`	`insertAsync`	on `Mongo.Collection`
`update`	`updateAsync`	on `Mongo.Collection`
`remove`	`removeAsync`	on `Mongo.Collection`
`findOne`	`findOneAsync`	on `Mongo.Collection`
`createIndex`	`createIndexAsync`	on `Mongo.Collection`
`count`	`countAsync`	on `Mongo.Cursor`
`forEach`	`forEachAsync`	on `Mongo.Cursor`
`map`	`mapAsync`	on `Mongo.Cursor`
`fetch`	`fetchAsync`	on `Mongo.Cursor`

Additional info

Note, that Cursor.count is deprecated and you should consider migrating to Collection.countDocuments or Collection.estimatedDocumentCount.

Static analysis 🔬

If you want to analyze their sync usage statically you would have to either write an isobuild plugin or a babel plugin.

The hardest challenge here is to get rid of the ambivalence due to the very common naming of the methods. For example: forEach and map are typical Array methods and may create lots of false-positives. You will likely have to track, if the variable.

Additional Info

There seems to be a discussion in the Meteor forums about an ESLINT plugin for static analysis. I suggest you to keep watching the topic, if this is an alternative to you.

Runtime analysis 🔬

This approach is rather easy to implement and produces no false-positives. However, detection requires the code to run, which therefore requires a great test-coverage in order to really cover all possible calls. We can do that by monkey patching the methods mentioned above.

Big plus: we can also detect usage in dependent Meteor packages, if we make sure the pathing occurs before the package code runs on startup. This is fortunately very easy as you just need to follow these steps:

1. Create a local package 📦

If your Meteor project does not contain a packages folder then you need to create one:

$ cd your-great-project
$ mkdir -p packages # needs to be on the same level as server, client, imports etc.
$ cd packages

Then you create a new local package with a unique name:

$ meteor create --package jkuester:migration-helper
$ cd ../ # back to project root
$ meteor add jkuester:migration-helper

Let's change the following method in package.js in order to immediately execute the code on startup (not to be confused with Meteor.startup, which runs after all startup code):

Package.onUse(function (api) {
  api.versionsFrom('2.3')
  api.use('ecmascript')
  api.use('mongo')
  api.addFiles('migration-helper.js', 'server')
})

Finally, open the Meteor packages list at your-great-project/.meteor/packages and move the entry for the package at the very top of the file in order to apply the patches before any other package code runs.

2. Create a new patch function 🔨

Stay in the package and edit the main file migration-helper.js which the following code (yes, you can copy/paste):

import {Meteor} from 'meteor/meteor'
import {Mongo} from 'meteor/mongo'
import {ValidatedMethod } from 'meteor/mdg:validated-method'

// some common pattern
const newLine = /\n/g
const whiteSpace = /\s+/g

// return the current location
// of function execution, considering
// multiple levels of wrappers
const getLocation = () => {
  const e = new Error('')
  const lines = e.stack.split(newLine)
  return lines[3].replace(whiteSpace, ' ').trim()
}

// monkey-patch a Collection/Cursor proto function
// to inject some analysis code without altering
// the original behavior
const patch = (proto, name) => {
  const original = proto[name]
  const className = proto.constructor.name

  proto[name] = function (...args) {
    const self = this
    const location = getLocation()
    const isWrappedAsync = location.includes(`as ${name}Async`)

    if (!isWrappedAsync) {
      console.warn(`Deprecated: ${className}.${name} needs to be migrated to ${name}Async in collection "${self._name}"!`)
      console.warn('=>', location)
    }
    return original.call(self, ...args)
  }
}

// apply patching to Mongo.Collection functions
const mNames = ['insert', 'update', 'remove', 'findOne', 'createIndex']
const mProto = Mongo.Collection.prototype
mNames.forEach(name => patch(mProto, name))

// applying patches Mongo.Cursor functions
const cNames = ['count', 'forEach', 'map', 'fetch']
const cProto = Mongo.Cursor.prototype
cNames.forEach(name => patch(cProto, name))

Start your Meteor project or run your tests and look for the deprecation messages. You can also replace the console.warn with throw new Error to make the tests fail but that will also likely prevent your app from running - this is up to you how to handle things here.

Meteor Methods ☄️

Most of the time you will define Methods and Publications statically on startup. This allows us to create a neat little tool that provides a summary of all our methods and publications.

Consider the following example, which inserts a new document into a Mongo.Collection (similar to what happens in the Meteor tutorials):

// server/main.js

Meteor.methods({
  'createTodo' (text) {
    const userId = this
    const docId = TodosCollection.insert({ text, userId })
    return TodosCollection.findOne(docId)
  }
})

Building on top of the previous section, we continue to extend our migration helper package in order to detect the migration needs for this method. Let's start with Meteor Methods by patching the Meteor.methods function. You can continue in migration-helper.js by simply adding the following code at the end of the file:

// ...continueing in migration-helper.js

const asyncLine = /\s*return Promise.asyncApply\(\(\) => {\n/g

// scans a function body for the above pattern
// to detect async functions
const analyze = ({ name, fn, location, type }) => {
  const source = fn.toString()
  const lines = source.split(byNewline)
  const isAsync = asyncLine.test(lines[1])

  if (!isAsync) {
    console.warn(`Deprecated (${type}): ${name} is not async, consider migrating now.`)
  }
}

What is this actually good for?

Let me explain: In Meteor.js 2.x (using Fibers) any async declared function gets recompiled by the Meteor build tool, transforming async functions into this Promise.asyncApply. It basically connects the given function to a Fiber that keeps track of the execution stack.

In turn - every Method or Publication that is not transformed into this Promise.asyncApply will not contain this pattern on line 1. Thus, we can detect that this function is not async yet.

Let's apply this to Meteor.methods; you can simply continue at the end of the file:

// ...continueing in migration-helper.js

const originalMethods = Meteor.methods

Meteor.methods = options => {
  const location = getLocation()
  const entries = Object.entries(options)
  const type = 'Method'
  entries.forEach(([name, fn]) => {
    analyze({ name, fn, location, type })
  })

  return originalMethods(options)
}

Restarting the project yields to the following output:

W20231102-15:28:12.775(1)? (STDERR) Deprecated (Method): createTodo is not async, consider migrating now.
W20231102-15:28:12.776(1)? (STDERR)   => at module (server/main.js:15:8)

And during tests or runtime we will see a message like this:

W20231102-15:32:31.550(1)? (STDERR) Deprecated: Collection.insert needs to be migrated to insertAsync in collection "todos"!
W20231102-15:32:31.551(1)? (STDERR) => at Collection.Mongo.Collection.<computed> [as insertAsync] (packages/mongo/collection.js:1004:46)
W20231102-15:32:31.560(1)? (STDERR) Deprecated: Collection.findOne needs to be migrated to findOneAsync in collection "todos"!
W20231102-15:32:31.561(1)? (STDERR) => at MethodInvocation.createTodo (server/main.js:26:28)

Both indicating the createTodo method needs some migration efforts. Let's do that:

Meteor.methods({
  'createTodo': async function (text) {
    const userId = this
    const docId = await TodosCollection.insertAsync({ text, userId })
    return TodosCollection.findOneAsync(docId)
  }
})

The warnings are gone and you have safely prepared this method for the major 3.0 update.

Meteor Publications ☄️

If you have already implemented the functions from the Meteor Methods section before then patching publications is as easy as it can get:

const originalPub = Meteor.publish

Meteor.publish = (name, fn) => {
  const location = getLocation()
  const type = 'Publication'
  analyze({ name, fn, location, type })
  return originalPub(name, fn)
}

Note, that publications return cursors using .find which does not need to be migrated to async. Therefore this may create some false-positives for functions that use no other Mongo.Collection or Mongo.Cursor functions that have to be async.

Validated Methods ☄️

A special case is, when using ValidatedMethod via mdg:validated-method. If you don't know the package, I highly suggest to check it out as it's the recommended way (add guide link) to create method with builtin argument validation.

We will not be able to detect non-async methods passed to the ValidatedMethod constructor as with the Meteor.methods pattern, described above. This is, because we basically can't override/monkey-patch an ES6 constructor function the same way we do with any other function.

Fortunately we still have two alternative ways for detection.

Detect using a mixin 🔍

This works by creating a mixin function that detects the options.run function the same way we detect the Meteor.methods. However, there is one disadvantage - you have to assign the mixin to every ValidatedMethod construction options and at that point you'll likely check each method manually.

Therefore, this approach makes only sense if you use a factory-function to create your Methods, which acts as a single point of construction. In that case, it's rather easy to inject the mixin into your validated methods:

export const createMethod = options => {
  options.mixins = options.mixins ?? []
  options.mixins.push(checkAsyncMixin)
  return new ValidatedMethod(options)
}

const checkAsyncMixin = options => {
  const { name, run } = options
  analyze({
    name: name,
    location: getLocation(),
    type: 'ValidatedMethod',
    fn: run
  })
  return options
}

Detect at runtime 🔬

If you don't use a pattern, similar to the above-mentioned factory-function, then you still have one more option here. However, this will only detect the methods at runtime, and you will either have to have a decent test-coverage or other ways to make sure that every of your methods are called.

It works by overriding the _execute prototype method, which will run on every method invocation for methods, declared using ValidatedMethod:

const originalExec = ValidatedMethod.prototype._execute

ValidatedMethod.prototype._execute = function (...args) {
  const self = this

  analyze({
    name: self.name,
    location: getLocation(),
    type: 'ValidatedMethod',
    fn: self.run
  })
  return originalExec.call(self, ...args)
}

Summary and outlook 🔭

I showed in this article how to easily detect parts of your Meteor 2.x server environment that need change in order to be 3.0-ready. I purposefully leaved out the client side as this easily exceeds the scope of a short and simple article.

Since Meteor.js supports many client side libraries and frameworks this may be subject to specific articles for each of them, and I encourage everyone to step up and start writing on their experience
with them.

You can use this code and refactor / modify it to your needs or simply use the package jkuester:migration-helper.
It's listed on Packosphere and available on GitHub, too:

Packosphere Link 📦

packosphere.com

GitHub repository ⌨️

jankapunkt / meteor-migration-helper

Detect which parts of your Meteor.js server environment need to be migrated in your current 2.x code.

Meteor.js Migration Helper

Detect which parts of your Meteor.js server environment need to be migrated in your current 2.x code.

No need to upgrade to 3.0 now to find out, what's still using Fibers.

There is also an article, which covers this packages functionality https://dev.to/jankapunkt/prepare-your-meteorjs-project-for-the-big-30-release-14bf

Installation

$ meteor add jkuester:migration-helper

Now open in your Meteor.js project the file .meteor/packages and move the entry jkuester:migration-helper to the top, in order to also detect dependency packages that still use Fibers.

Run detection

This is a runtime detection. In order to cover all detectable structures you need to either run your Meteor.js application or the tests.

The more your tests cover of your code (test-coverage), the better you will be able to detect these.

Detect validated methods using mixins

This package also provides a mixin to be used with mdg:validated-method

You can import it via

import { checkAsyncMixin } from 'meteor/jkuester:migration-helper'
// ...

…

View on GitHub

About me 👋

You can also find (and contact) me on GitHub, Twitter/X and LinkedIn.

If you like what you are reading and want to support me, you can sponsor me on GitHub, send me a tip via PayPal or sponsor me a book form my Amazon wishlist.

Forem: Jan Küster 🔥

I'm frozen and I cannot move

Wasted Open Source efforts 😮

How it all began

My Motivation for the PRs

Waking up from the dreamworld: the most unfriendly GitHub conversation I have had in years 🤬

Docker installation is missing requirements for cuda support #1073

Checks

Environment Details

Steps to Reproduce

✔️ Expected Behavior

❌ Actual Behavior

Going big: PR in the official PyTorch repo

docs: link to Nvidia Container Toolkit in README #155102

My personal thoughts

Reactive Data Structures in MeteorJS - Reactive Stack

Goal of this tutorial

Short reminder: What is a stack?

Let's start coding

1. Create a new project

2. Remove boilerplate

3. Initial Stack implementation

4. Integrate the stack into the UI

5. Adding Template logic

6. Make it reactive

Where to go from here?

About me 👋

Transform any MeteorJS App to a PWA in 2024

Table of Contents

What are PWAs?

Why should I make my MeteorJS app a PWA?

Enough talk, show me how to do it

1. Add a service worker

2. Provide a manifest

3. Add Head entries

4. Force ssl

Where to go from here?

About me 👋

MeteorJS 3.0 major impact estimated for July 2024 ☄️ - here is all you need to know 🧐

Table of contents

Back in 2021 - the Fibers situation

Biggest changes

Will it have consequences?

If you are new to MeteorJS:

If you have an existing Meteor apps or packages:

Conclusion

Resources to help you migrate your Meteor app

About me 👋

5 core concepts you should know about MeteorJS in 2024

meteor / meteor

Meteor, the JavaScript App Platform

📚 Create your applications using modern JavaScript

✨ Integrate technologies you already use

💻 Build apps for any device

🔥 Getting Started

🚀 Quick Start

🧱 Developer Resources

True Full Stack

WebSocket and DDP

Optimistic UI

Zero Config

Meteor.js with Vite, Solid, and Tailwind CSS

Frederico Maia ・ May 10 '23

ESNext

Community Packages

Meteor-Community-Packages / meteor-collection2

A Meteor package that extends Mongo.Collection to provide support for specifying a schema and then validating against that schema when inserting and updating.

Collection2 (aldeed:collection2 Meteor package)

TOC

Meteor-Community-Packages / meteor-roles

Authorization package for Meteor, compatible with built-in accounts packages

meteor-roles v3

Table of Contents

Contributors

Authorization

About me 👋

I fixed the "Save draft" Button on dev.to - No Accidental Publishing Anymore 😇

How to fix it?

About me 👋

SpeechSynthesis in <= 256 characters (Web Speech API)

`useTracker`

`useSubscribe`

`useFind`