Forem: Gabriel Grubba

Faster Server Startup in Meteor 3.4 with Deferrables

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

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

Why were those functions added?

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

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

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

New API

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

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

Meteor.deferrable

In the docs, we can see it in action:

import { Meteor } from "meteor/meteor";

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

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

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

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

Meteor.deferDev

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

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

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

And to use it is very simple:

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

  await Meteor.deferDev(connectToExternalExpensiveService);

Meteor.deferProd

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

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

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

Using deferrable with values

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

You can see this logging example:

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

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

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

Very cool, eh?

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

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

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

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

Migration & Conclusion

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

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

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

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

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

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

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

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

The fastest way of creating a real-time app with Zod and TypeScript

Gabriel Grubba — Thu, 12 Dec 2024 23:21:34 +0000

Table of Contents
1. Table of contents
2. Introduction
3. Getting started
4. Creating a project
5. Starting our app
6. The chat collection
7. The chat module
8. The front-end
9. The main page
10. The chat page
11. Deployment
12. Conclusion

Introduction

When creating real-time apps such as chats or dashboards, we usually consider Node.js and its many frameworks. In this tutorial, I’ll show you the most productive to create real-time apps with Zod and TypeScript.

Most of you might think I'll talk about a new JavaScript framework, but if you have been around the JavaScript community long enough, you may have heard of Meteor.js.

In this tutorial, I'll show this new take on creating Meteor applications and why it is so productive. At the end, you will have a working real-time chat app that uses Zod for its validations and full-blown TypeScript support for your APIs

Getting started

Ensure you have meteor installed on your machine.

In case you do not have it installed, you can run the following command:

npx meteor

This will install the Meteor CLI tool on your machine.

Creating a project

meteor create

It will prompt you for the name of your new app and which skeleton you want to use. I chose super-chat as the name of our app and the TypeScript starter scaffold.

Then, we can enter the directory and start installing the packages needed to start our guide:

cd super-chat && meteor npm i meteor-rpc @tanstack/react-query zod react-router-dom@6

The packages that we are installing are a requisite for meteor-rpc to work:

zod: for runtime validation
@tanstack/react-query: for querying data in the client
meteor-rpc: to abstract Meteor methods and Publications in a nice and modern way.

We are also installing react-router-dom for routing in our app.

Setting up our React app

Before continuing, we need to set up our React app. You can follow react-query and react-router guides or you can paste this snippet in your imports/ui/App.tsx:

import React, { Suspense } from "react";
import { QueryClient, QueryClientProvider } from "@tanstack/react-query";
import { BrowserRouter, Routes, Route } from "react-router-dom";

const queryClient = new QueryClient();
export const App = () => (
  <QueryClientProvider client={queryClient}>
    <BrowserRouter>
      <Routes>
        <Route
          index
          element={
            <div>
              <Suspense fallback={<h1>Loading...</h1>}>
                Hello from Super-Chat!
              </Suspense>
            </div>
          }
        />

        <Route path="/chat/:chatId" element={<div>Chat!</div>} />
      </Routes>
    </BrowserRouter>
  </QueryClientProvider>
);

Then, we will delete Hello.tsx and Info.tsx as we will not need them.

Starting our app

The first thing we need to do is remove all code from main.ts and then create our server entry point with the createModule from meteor-rpc; at this point, your main.ts file should look like this:

import { createModule } from "meteor-rpc";

const server = createModule().build();

export type Server = typeof server;

The chat collection

We must first have our ChatCollection to store our messages and chat groups. To achieve this, we will create in server/chat/model.ts our ChatCollection. The code should look like this:

import { Mongo } from "meteor/mongo";

export interface Message {
  text: string;
  who: string;
  createdAt: Date;
}

export interface Chat {
  _id?: string;
  messages: Message[];
  createdAt: Date;
}

export const ChatCollection = new Mongo.Collection<Chat>("chat");

Our app will not be very complex, and this will be our only collection. We will store every message from every chat, containing who sent it, text it sent, and it was created.

The chat module

Now, we must consider what methods or functions our chat will need. Every chat app has these features:

you can create a chat room;
you can send a message to a chat room;
you can see all chat rooms in real-time;
you can see a conversation in real-time;

With that in mind, use the createModule from meteor-rpc and the module.addPublication for the real-time features and module.addMethod for the remote calls.

I'll create a TypeScript file in server/chat/module.ts, which we will use as our entry point for our functions.

import { createModule } from "meteor-rpc";
import { ChatCollection } from "./model";
import { z } from "zod";

export const ChatModule =
  createModule("chat")
    .addMethod("createRoom", z.void(), async () => {
      return ChatCollection.insertAsync({ createdAt: new Date(), messages: [] });
    })
    .addMethod(
      "sendMessage",
      z.object({ chatId: z.string(), message: z.string(), user: z.string() }),
      async ({ chatId, message, user }) => {
        return ChatCollection.updateAsync(
          { _id: chatId },
          {
            $push: {
              messages: { text: message, who: user, createdAt: new Date() },
            },
          }
        );
      }
    )
    .addPublication("room", z.string(), (chatId) => {
      return ChatCollection.find({ _id: chatId });
    })
    .addPublication("rooms", z.void(), () => {
      return ChatCollection.find();
    })
    .buildSubmodule(); // this is very important, don't forget to call this method

Voilá! We have almost everything ready on our server. We now must register this module in our server/main.ts, and then we can move to the client side.

On server/main.ts will look like this when we register our chat module:


import { createModule } from "meteor-rpc";
import { ChatModule } from "./chat/module";

const server = createModule().addSubmodule(ChatModule).build();

export type Server = typeof server;

And with that, we have our backend working!

The front-end

Our app currently only has the imports/ui/App.tsx and has no server-side interaction. To change that, we should have our API entry point to import our server API calls. In my app, I will call this entry point client.ts, and it will be located in our imports/api/client.ts. Also, we should clean up our API folder while there, removing the links.ts file. Here is what my server.ts looks like:

import { createClient } from "meteor-rpc";
import type { Server } from "/server/main";

export const client = createClient<Server>();

It is essential to import only the type Server from the server; if you try importing anything else, our build will fail because Meteor protects us from importing server files and possibly leaking secret files. Types are fine because they are removed at build time.

This variable server within the client scope is what we will use to interact with our server.

The Main page

The first thing we should create in our front end is the main page, where it should be placed the button to create a new chat room and the links for all available chat rooms; with those requirements in mind, we should make a Main.tsx file in our imports/ui directory, this file should look like something like this:

import React from "react";
import { client } from "../api/client";
import { useNavigate } from "react-router-dom";

export const Main = () => {
  const navigate = useNavigate();

  const { data: rooms } = client.chat.rooms.usePublication();

  const createChatRoom = async () => {
    const room = await client.chat.createTheRoom();
    navigate(`/chat/${room}`);
  };

  return (
    <div>
      <h1>Welcome to chat!</h1>
      <button onClick={createChatRoom}>
        Click me to generate and go to a chat room
      </button>
      <br />
      <span>Or select a chat from the list below to go to that chat room</span>
      <h3>Chats:</h3>
      {rooms.length === 0 && (
        <span>We do not have rooms yet, so why don't you create one?</span>
      )}
      <ul>
        {rooms?.map((room) => (
          <li key={room._id}>
            <a href={`/chat/${room._id}`}>Chat room {room._id}</a>
          </li>
        ))}
      </ul>
    </div>
  );
};

And we should update our App.tsx to include our Main.tsx page:

// ....
    <BrowserRouter>
      <Routes>
        <Route
          index
          element={
            <div>
              <Suspense fallback={<h1>Loading...</h1>}>
                <Main />
              </Suspense>
            </div>
          }
        />
// ....

Our app should look something like this:

However, our chat page still looks blank when we click to join a room or create a new one. We should solve that!

The chat page

Firstly, we should create a Chat.tsx in imports/ui; in this component, we should use our chatId parameter to pass to the server so that it knows in which room it should add the message and also which room are we listing for updates.

Also, we should create and validate our input fields. In the end, we should have a file that looks something like this:

import React, { useReducer } from "react";
import { client } from "../api/client";
import { useNavigate, useParams } from "react-router-dom";

export const Chat = () => {
  let { chatId } = useParams();
  const navigate = useNavigate();
  const {
    data: [chatRoom],
  } = client.chat.room.usePublication(chatId as string);

  const [state, dispatch] = useReducer(
    (
      state: { who: string; message: string },
      action: { type: string; value: string }
    ) => {
      switch (action.type) {
        case "who":
          return { ...state, who: action.value };
        case "message":
          return { ...state, message: action.value };
        default:
          return state;
      }
    },
    { who: "", message: "" }
  );
  const sendMessage = async () => {
    if (state.who === "" || state.message === "") {
      alert("Please fill in both fields");
      return;
    }
    await client.chat.sendMessage({
      chatId: chatId as string,
      message: state.message,
      user: state.who,
    });
    dispatch({ type: "message", value: "" });
  };

  return (
    <div>
      <button onClick={() => navigate("/")}>Go back to main page</button>
      <h2>Chat in room: {chatId}</h2>
      <div>
        <label htmlFor="who">Who:</label>
        <input
          id="who"
          onChange={(e) => dispatch({ type: "who", value: e.target.value })}
          value={state.who}
        />
      </div>
      <div>
        <label htmlFor="message">Message:</label>
        <input
          id="message"
          onChange={(e) => dispatch({ type: "message", value: e.target.value })}
          value={state.message}
        />
      </div>
      <button onClick={sendMessage}>Send message</button>
      <h3>Messages:</h3>
      {chatRoom.messages.length === 0 && <span>No messages yet</span>}
      <ul>
        {chatRoom.messages.map((message, i) => (
          <li key={i}>
            <span>{message.who}:</span> {message.text}
          </li>
        ))}
      </ul>
    </div>
  );
};

It looks big, but bear with me. On this component, we listen for every message within a conversation based on its chatId. We can call the sendMessage method defined in the server. Also, we have our validation for when sending messages.

Do not forget to add this component to our App.tsx router file.

Let's take a look at it in action:

Deployment

Now that we have our app done, we can deploy it. All you have to do is run this command, and you will have it deployed in Galaxy Cloud for free with an included MongoDB:

 meteor deploy <your-app-name>.meteorapp.com --free --mongo

Conclusion

One of the best features that meteor-rpc brings to our Meteor apps is the structured object to call from; in other words, every method that is defined and has IntelliSense; if you have not tested it yourself, you can see it in this video:

You can check the complete source code here, and if you have any issues with meteor-rpc package, please let us know either in the repo of the package or get in contact with me via my X account

Meteor v3 uses express under the hood – How to use and deploy it.

Gabriel Grubba — Mon, 04 Mar 2024 12:15:00 +0000

If you have never heard of Meteor, here is a blog post from @harryadel in which he tells a little bit about the genesis of this 10-year-old framework. Also, check the About section in our docs.

As you might have seen from this PR and in our forums Meteor v3(it is still in beta, but you can follow the progress here) will be released with a new engine, expressjs.

This blog post focuses on how to use and deploy meteor v3 and test this new engine. You can check the final code in GitHub

Why use Express with Meteor?

You might wonder why Express can be used with Meteor if Meteor provides everything that is needed to connect with the front end. For the cases where it is required to expose data to another client or multiple clients, for example, you have a dashboard that is your Meteor app, and you have clients that can consume that data. You can use Express for this case and provide an HTTP endpoint.

Meteor installation

You can check the meteor installation section in our docs for more details and troubleshooting in case of installation problems.

Having Node.js v14 in your machine run:


npm i -g meteor

Or using curl if in OSX or Linux:


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

Creating your app

Having meteor installed on your machine, you can create your app running the following command:

meteor create 3.0-beta-app --release 3.0-beta.6

This command will create a meteor app in the 3.0-beta-app folder. To enter this folder, run cd 3.0-beta-app.

Temporary issue

Before starting our app for this release, we had an issue with react-meteor-data. To solve it, run the following command:

meteor remove react-meteor-data && meteor add react-meteor-data@3.0.0-beta300.1

You should see a result like this one:

Having all our dependencies installed and all is okay, if you run the command meteor in the root of your project, you can see in localhost:3000 this page:

Working with express

To start using Express in your project, you should add this import in the server/main.js file:

import { WebApp } from "meteor/webapp";

This interface is where you can register your endpoints.

You can use the WebApp.handlers as your express instance as you typically would. For example, this is how we create a GET endpoint that returns all links from the LinksCollection, the end result should look like this in your server/main.js file:


import { LinksCollection } from "/imports/api/links";
import { WebApp } from "meteor/webapp";

WebApp.handlers.get("/all-links", async (req, res) => {
  const links = await LinksCollection.find().fetchAsync();
  res.json(links);
});

// other code ...

If you check your app in http://localhost:3000/all-links, your page should look like this:

And that is all you need to have your app running and using Express.

Deploy

The easiest part is deploying; you can use the Meteor Cloud for free to test your app.

If you host your project in any Git provider(GitHub, for example), you can use this tutorial to deploy your project, and when you commit a new change, it will deploy a new container for you.

In this tutorial, I will use the CLI for simplicity. In the root of your project, run the following command:

meteor deploy mycollexpressapp.meteorapp.com --free --mongo

When you are deploying, you should change mycollexpressapp.meteorapp.com for a URL that you like

When you deploy your project, you can access https://mycollexpressapp.meteorapp.com/all-links, and all your links should be there in a way similar to what we have locally.

Conclusion

Given what you have seen today, I would love to see what apps you can create using Meteor v3 and Express.

Please ping us on X(formerly Twitter) with your project; we would love to showcase it.

Meteor is getting new docs!

Gabriel Grubba — Wed, 24 Jan 2024 19:13:40 +0000

We are in the process of migrating documentation from the current site to the new one. You can follow the status in this PR, and the preview site is here.
In the near future, we will move our guide to the same site.

This blog post will briefly show how the new Meteor.js docs will look while explaining why we are doing this change.

Before

Now

Why are we making this change?

Our current docs have more than eight years of existence, and because of that, code examples, APIs, and the UI sometimes feel outdated. In this spirit of change coming with Meteor.js v3, we decided that while updating our docs to match the new API, we should adjust the docs to fit our vision of the future of Meteor.js: Modern and connected to the JavaScript ecosystem.

API Index

In this new version, we have added an API index, a page that lists all Meteor.js APIs. It behaves similarly to an index page for a book; every item on this page links to its documentation.

Information architeture

While redesigning our new docs, we changed how the information is grouped and displayed on the page. We kept related information together.

Also, every page has an on this page section(index), so you know which API you have on this page.

Why Vitepress?

While researching which static site generator we would use, we had a lot of frameworks to pick up from, but only some addressed our needs.
While choosing, we needed it to have a good "default" template, out-of-the-box plugins, and be easy to extend its functionalities. From our research, the one that matched most criteria and felt the easiest to start and progress with was Vitepress.

We are proud of the work that we have done in these new docs. It has been a challenging journey, and there is much more to it.

If you liked what you saw today, please react to this post and do not forget to follow us on our socials:

New Meteor.js 2.14, updates to CLI and Tracker changes

Gabriel Grubba — Wed, 13 Dec 2023 12:36:54 +0000

Meteor.js has released version 2.14, which includes several updates and improvements. Here are some of the key features of this release:

Meteor CLI is being modernized

In this release, we have added two new features to the CLI. You can now open your browser directly by adding --open to your run or test command. Starting from v2.14, your meteor CLI can also help you through the creation of your project, giving you options and projects from which you can choose to start using it. Ensure your meteor tool is in 2.14 and run meteor create in your terminal.
We have made a demo video for these features:

Note that this is a feature on top of what we currently have in the meteor create command.

Addition of `firstRunPromise`

For some scenarios, it is necessary to await the completion of an invocation of a Tracker.autorun, meaning that before this feature with many of our codes becoming async, this test would fail:


Tinytest.addAsync('tracker - async function - synchronize', async test => {
  let counter = 0;

  Tracker.autorun(async () => {
    test.equal(counter, 0);
    counter += 1;
    test.equal(counter, 1);
    await Promise.resolve();
    test.equal(counter, 1);
    counter *= 2;
    test.equal(counter, 2);
  });

   Tracker.autorun(async () => {
    test.equal(counter, 2);
    counter += 1;
    test.equal(counter, 3);
    await Promise.resolve();
    test.equal(counter, 3);
    counter *= 2;
    test.equal(counter, 6);
  });
});

Now, with this new feature, we can rewrite our test so that it can pass now:

Tinytest.addAsync('tracker - async function - synchronize', async test => {
  let counter = 0;

  await Tracker.autorun(async () => {
    test.equal(counter, 0);
    counter += 1;
    test.equal(counter, 1);
    await Promise.resolve();
    test.equal(counter, 1);
    counter *= 2;
    test.equal(counter, 2);
  }).firstRunPromise;

  await Tracker.autorun(async () => {
    test.equal(counter, 2);
    counter += 1;
    test.equal(counter, 3);
    await Promise.resolve();
    test.equal(counter, 3);
    counter *= 2;
    test.equal(counter, 6);
  });
});

You can choose between awaiting the .firstRunPromise property or just await for the Tracker.autorun. Both options have the same output.

Dependencies updates

You can check all changes in the changelog

In this release, we updated some dependencies. The most notable ones are:

MongoDB driver to v4.17.2;
Typescript to v4.9.5;
Cordova v12.0.1 for Android and v7.0.1 for iOS;

For Cordova users, check our Migration Guide. There is a breaking change that needs action.

Special note about Meteor v3

We are in Meteor v3.0-alpha.19. To see what is missing for our beta and official release, you can check this GitHub discussion here.

For those who want to see an app running in Meteor v3, we have successfully migrated the SimpleTasks app to be running in the 3.0-alpha.19. You can check it running in galaxy and the migration PR here

Special thanks

We want to extend special thanks to the following contributors for their contributions to this release:

Thank you for your hard work and dedication to the Meteor.js community!
We encourage all users to update to Meteor.js 2.14 to take advantage of these new features and improvements.
For more information about Meteor.js, please visit the Meteor.js website.

Happy coding!

Meteor Core issues for Hacktoberfest 2023

Gabriel Grubba — Mon, 02 Oct 2023 12:20:18 +0000

Hacktoberfest is here! This is a fun and exciting event that happens every October to celebrate open source. It's a global happening that invites developers of all levels to contribute to open-source projects. Whether you're a coder, designer, writer, or just love technology, Hacktoberfest is a great opportunity to get involved and make a positive impact on the world of open source. Get ready to join the party!

In the same spirit as Jan's post, we present today a few issues that we believe could benefit from your expertise and creativity. This post will present some history and some context to the issues, and if, for some reason, the issue is not clear, you can always ping the Meteor team on GitHub.

Without further ado, here are the issues that we thought the community to work on:

The complete list of hacktoberfest issues that you can contribute can be seen here in this link

Making the Meteor.user API clearer

The issue states that Meteor.user has some edge cases that should be corrected. To solve this, adding a section about the possibility of it being undefined and updating the types is likely necessary.

Documenting the main meteor function

This issue was partially solved back in the day, but we, as the maintainers, think this documentation could be in a much better place. Following along with the issue, much of the work involves moving docs from one place to another.

Accounts not being able to correctly set their db name

In Meteor.js v2.12, we added a new feature: the ability to set whatever name you would like for your Accounts collection. However, this feature only updates some possible cases. The objective to solve this issue is not only to be able to add any name to a collection, but also to add some tests to ensure that this new feature works correctly and covers this edge case.

Add --open to our command line

Many tools have this command to open the user's browser on startup, for example, Vite and Angular. Meteor should have this feature as well. In the issue, the maintainers have listed most places where changes are necessary to implement this feature.

Make meteor create more interactive

Currently, the meteor create command is not only non-interactive but sometimes requires clarification if it accepts more than one flag when creating an app. We have created this issue to make the Meteor create command more interactive, similar to Vite's npm create vite\@latest command. Additionally, as shown in the issue, this feature must come with some updates to the styling of our command.

Add TypeScript variations to meteor create

Currently, the meteor create command does not handle a combination of commands. For example, the issue shows that if you combine --vue and --typescript, you will get a React app with TypeScript. This happens because we do not have the boilerplate to serve a Vue + TypeScript app, and the CLI does not recognize flags being used in that manner.

The issue explains possible options to implement this feature. It also includes a to-do list so that the implementer can follow along with the necessary steps to make this feature.

Our goal is to make the Meteor ecosystem even more user-friendly and feature-rich. If you have any questions or need further clarification, don't hesitate to reach out to us on GitHub. So, get ready to roll up your sleeves and dive into these exciting issues. Let's make this Hacktoberfest one to remember!

Calling Rust code from Go - the Gambiarra way

Gabriel Grubba — Wed, 12 Apr 2023 04:27:54 +0000

Did you know that Rust has been voted the 'most loved programming language' for five years in a row by the Stack Overflow community? It's no wonder why Rust has gained such popularity - its unique features make it a powerful tool for systems programming. But what if you want to use Rust in conjunction with another language? In this post, we'll explore how you can call Rust code from Go with a more "gambiarra" approach, and how this approach can be useful for migrating apps to Rust.

A more correct way.

Before we start we need to address the post that triggered this idea in me, is this a great post(RUSTGO: CALLING RUST FROM GO WITH NEAR-ZERO OVERHEAD) from Filippo Valsorda, I wanted to make a version with this but in a different(probably a way less performant version of it) but with the migration of projects in mind instead of having something living together, and calling with thought an FFI. The idea is simple and there is a repo with a minimal viable example here. Without further ado, to make this happen the only thing you will need to add to your rust code is clap if it does not have it, and yes, you probably see where we are going with this. We are making our Rust code a CLI program and using the thing every language that I know has, the ability to call other programs, something as we do in Go with exec.Command from the os/exec library.

How does this work?

Visual model of what is happening.

The steps you will need to follow are:

Create entry points for your code with the parameters you need (clap will help a lot with this). Your rust code should return as output like text or it can write to a file that should be read from your main app program later. The .Output method will return a buffer with every single thing that was printed from your Rust program, if you expect from you rust code a more complex response, write to a file and read.
Compile your rust to an executable in the host machine, which can be done before starting the main app.
In your main app, for example in Go, when you need to call this module/feature/thing-that-you-need-that-is-in-rust you make a terminal call to it using your main app and unmarshal it as it was another API call.

And there you go, you have yourself two living projects that can talk to each other. This can be really useful when migrating apps to Rust.

In practice

For to have at least an example of this in action I will show what I did in the example project:

Our Rust code is below:



use clap::Parser;

/// Simple program to greet a person
#[derive(Parser, Debug)]
#[command(author, version, about, long_about = None)]
struct Args {
    /// Name of the person to greet
    #[arg(short, long)]
    name: String,

}

fn main() {
    let args = Args::parse();

    println!("Hello, {}!", args.name)

}

Is the example from clap as its starting point and well what we will do is compile this code using cargo build --release and then in our Go code we will call this binary like this:



package main

import (
    "fmt"
    "os/exec"
)

func main() {
    output, err := exec.Command("./rust-code/target/release/rust-code", "--name", "John").Output()
    if err != nil {
        fmt.Println(err.Error())
    }
    fmt.Println(string(output)) // will print "Hello, John!"
}

Now we have something that works, this can be done in almost any language that compiles to an executable and it can be called within the command line. Sure that is not the most reliable way of doing things, as we do not have a great type system in our favor and we hurt performance as we are creating and making objects all the time but is the most straightforward way and in my opinion the easiest way to go from language x to language y.

New Suspense Hooks for Meteor

Gabriel Grubba — Mon, 20 Mar 2023 13:42:48 +0000

As we learned in the previous part of this series, why and how we could use Suspense. This article will discuss and show how to use Meteor's newly added suspendable hooks.

With the changes coming to Meteor, especially with its fibers-free future, we decided to add to our hooks collection react-meteor-data a few hooks that can deal with those new async methods.

For starters, we need to address that useFind still works as it always did on the client;
it was implemented using synchronous functions, so it was safe from change. But important to note that if you are using the useFind hook on the server, for example, while using SSR, you will need to use the newly added suspense/useFind hook. This is important because now you cannot do a sync database search with the current implementation of useFind in the server, but with the newly added Suspense version, you can.

Before showing examples, we would like to show another made-suspendable hook: useSubscribe now. Instead of using an isLoading function to know when the subscription is ready, we made it use the Suspense API. Let's look at how it was before and how it will be:


// before
// Tasks.jsx
function Tasks(){
    const [hideDone, setHideDone] = useState(false);
    const isLoading = useSubscribe("tasks");
    const filter = hideDone ? { done: { $ne: true }  } : {  };
    const tasks = useFind(
        () => TasksCollection.find(filter, { sort: { createdAt: -1 } }),
        [hideDone]
    );

    if (isLoading()) return <Loader />

    // render the tasks
}

// With suspense
// Tasks.jsx (have a Suspense wrapper outside with fallback={ <Loader /> }
function Tasks(){
    const [hideDone, setHideDone] = useState(false);
    useSubscribe("tasks");
    const filter = hideDone ? { done: { $ne: true }  } : {  };
    const tasks = useFind(
        TasksCollection,
            [filter, { sort: { createdAt: -1 } }],
        [hideDone]
    );

    // render the tasks
}

It looks and feels almost the same. We just moved the isLoading to the outside, and now we have a much more declarative code with a better Developer experience.

The changes regarding the useFind are how you build your function. Now you should pass the Collection, the arguments, and its dependencies.

What about useTracker?

In this part, there will be a change to suspend when async. This is due to how Suspense works under the hood(a simple explanation: we need a way to track the promises when they are thrown, for a longer version, check the previous article from this series ). One of the things we will need to add one key to each useTracker instance.

// before
// Tasks.jsx

function Tasks(){
    const isLoading = useSubscribe("tasks");
    const { username } = useTracker(() => Meteor.userAsync())
    const tasksByUser = useTracker(() => 
             TasksCollection.find({username}, { sort: { createdAt: -1 } }).fetch()
    );

    if (isLoading()) return <Loader />

    // render the tasks
}

// With suspense
// Tasks.jsx (have a Suspense wrapper outside with fallback={ <Loader /> }
function Tasks(){
    useSubscribe("tasks");
    const { username } = useTracker("user",() => Meteor.userAsync()) 
    const tasksByUser = useTracker("tasksByUser", () =>
         TasksCollection.find({username}, { sort: { createdAt: -1 } }).fetchAsync() // fetch will be async
    );

    // render the tasks
}

It seems more bloated due to the addition of strings, but now we do not need to think about loading states, and for some of them, the new react rendering engine improves our performance, and the reactivity is maintained between renders.

Why are these changes so significant?

If, in your case, you only used useFind as before, without SSR and without using useTracker with async dependencies such as calling a fetch from a collection, then you may not need to update as these changes are just new API areas for solving the newly added functionalities that were added in Meteor 3.

Making Promises Suspendable

Gabriel Grubba — Mon, 20 Mar 2023 13:35:41 +0000

This is a two-part article in which we focus first on understanding the foundations of the reasons to use the Suspense API, and in the next part, we will discuss how to use the New Suspense hooks for Meteor

I will explain how to make your promises go into suspense mode and what it takes to get there.

I recommend two articles for theory on this side that helped me understand how React deals with async values. One is from Dan Abramov - Algebraic Effects for the Rest of Us, and the other is from Radosław Miernik - On throw in React

Why use suspense?

As this good article explains, Suspense gives us two great features:

Declarative code which means that React Suspense simplifies the process of writing UI code by allowing developers to declare what they want the UI to look like rather than writing code that tells the UI how to render step-by-step. One example of this feature is the removal of the use isLoading variable. By placing this variable above the UI code, developers can ensure that their code is in sync with the UI. This eliminates the need for awkward if statements.
Better end-user experience with Suspense. You can use the newly added concurrent rendering engine in React. This Suspense feature gives the end user a better feeling of how the UI looks and acts because react only will update what it needs.

Theory aside, here is my gist, which is why this article exists. You can use this playground as well.

Now I will explain how this works. First, you will need a cache map to store your promises. As React suspends, the promise and then fulfills it, you need a way to track this specific promise (this was a part that I struggled with a lot to understand, it has to be the exact same promise each time). If there is no value in the given key, the hook will create an entry in the map with this promise and throw it. Here is where the magic happens. The suspensify hook looks like the snippet below in its first run:

function suspensify<T>(key: string, promise: Promise<T> | null, deps: DependencyList = [], lifespan = 0): T {
  const cached = cacheMap.get(key)
    **//    ˆˆˆ this is undefined. all code below is not ran
  /* ... code ...*/
 const entry: Entry = {
    deps,
    promise: new Promise((resolve, reject) => { // here you work in your promise / waitable value. remember to set the result and error
      promise
        .then((result) => {
          entry.result = result
          resolve(result)
        })
        .catch((error) => {
          entry.error = error
          reject(error)
        })
    })
  }

  cacheMap.set(key, entry)
  throw entry.promise
// ˆˆˆˆthis is where we jump into the fallback
}

Before we talk about the return side of the suspense API, I would like to point out that when you pass in a null value is the same as saying that you want it to return null and not run the hook, as we cannot put an if statement above a hook, this is the way to deal with control flow.

Well, when the hook runs again (yes, that is how suspense works), we will go to the if that was above the entry creation:

function suspensify<T>(key: string, promise: Promise<T> | null, deps: DependencyList = [], lifespan = 0): T {
  const cached = cacheMap.get(key)
  //    ˆˆˆ now we have a value here
  useEffect(() =>
    () => {
      setTimeout(() => {
        if (cached !== undefined && isEqual(cached.deps, deps)) cacheMap.delete(key)
                // ˆˆˆˆclean when the hook unmounts.
      }, lifespan)
    }, [cached, key, ...deps])

  if (promise === null) return null // we talked about this one

  if (cached !== undefined) {
    if ('error' in cached) throw cached.error
                                                        // ˆˆˆˆtrigger error boundary
    if ('result' in cached) {
      const result = cached.result as T
      setTimeout(() => {
        cacheMap.delete(key)
      }, lifespan)
      return result // resolve suspense
    }
    throw cached.promise // as we have not got any result or err we should wait a bit more
  }

/* ... code ...*/
}

There are some caveats. We need to address that setTimeout that works as “defer” they are necessary because after we return the value of the promise, we need to clean this key, as it may be required to run another code when this component mounts again. You can adjust the lifespan if you want to reuse the same value in other places but be careful not to live in old data, an excellent way to start is with 0 and then increase the lifespan of this key result.

And there you go, you have learned a bit about how Suspense works and how you can use it today to deal with your promises.

React Query already supports Suspense, and Relay is our most outstanding example of Suspense API in practice.

If you got interested in what you saw here and want to see implemented versions of a library using the suspense API, you could check the next chapter of this article series, where is shown the New Suspense hooks for Meteor

Using Discord as your CDN.

Gabriel Grubba — Fri, 16 Dec 2022 14:31:56 +0000

Sometimes you are an indie developer or just creating a prototype, and you can't afford to set up a bucket on S3. For those times, I created this straightforward API to solve the issue of saving images in a database.

You have to set up a bot, and the service will take care of the rest.

To save the images, you must send him a form post with the field file. The bot will save the photo and send it back as a URL so you can keep it in your database. In this blog post, I will explain what I've done and how you can set up for yourself this fantastic service.

Side note:
Thought that this post is not sponsored by Meteor Cloud. I recommend their service, and they have a free tier where you have a MongoDB instance that can be used to save that URL I mentioned above.

How to use it?

I will start linking the source code repo and ask you to give it a star.

If you want to run locally, you will need to set up a .env file with some info that the bot requires to work, and that is all. When you run the main function, it should create a web server where you can send a post request to it and store your photos dynamically. Again if you want a more detailed version of how to set up and run this service in your cloud infrastructure, you can check the source code repo. In this post, I will focus on how I did it.

How is it done?

As you can see in the source code, this is a Go code, so it is straightforward as it can be.

Creating HTTP server and Bot connection

In this first part of the main function, we have created the fiber HTTP server, and the creation of the /sendFile route. When this route is called, passing the file field, we have the creation of our discord bot using this excellent library called discordgo. We also open the WebSocket to talk to the Discord servers.

func main() {
    app := fiber.New()
    app.Use(cors.New())

    app.Post("/sendFile", func(ctx *fiber.Ctx) error {
        dg, err := discordgo.New("Bot " + os.Getenv("BOT_TOKEN"))

        if err != nil {
            fmt.Println("error creating Discord session,", err)
            return fiber.NewError(fiber.StatusBadRequest, "error creating Discord session")
        }

        err = dg.Open()
        if err != nil {
            fmt.Println("error opening connection,", err)
            return fiber.NewError(fiber.StatusBadRequest, "error opening connection,")

        }

Getting the file and the channel

After creating the bot, we need to check if the file can be transformed into a stream. We do size and file type checking.


        file, err := ctx.FormFile("file")

        if err != nil {
            fmt.Println("Error getting file", err.Error())
            return fiber.NewError(fiber.StatusBadRequest, "Error getting file")
        }
        // do the checks and return a file to be sent to discord
        osFile, err := media.ToOSFile(ctx, file)
        if err != nil {
            fmt.Println("Error saving the file", err.Error())
            return fiber.NewError(fiber.StatusBadRequest, "Error saving the file")
        }

Wrapping up and sending the URL

After doing all the necessary checks, we wrap the data into a struct that will be sent to discord and delivered to the bot. When sending the message is done, we gather the attachment URL and send it back to the user. We disconnect and clean up the server, so it is ready to receive another HTTP call.


data := &discordgo.MessageSend{
            Files: []*discordgo.File{
                {
                    Name:        file.Filename,
                    ContentType: file.Header.Get("Content-Type"),
                    Reader:      osFile,
                }},
        }

        msg, err := dg.ChannelMessageSendComplex(os.Getenv("CHANNEL_ID"), data)

        if err != nil {
            fmt.Println("Error sending the message ", err.Error())
            return fiber.NewError(fiber.StatusBadRequest, "Error sending the message")
        }

        r := new(Return)
        r.Url = msg.Attachments[0].URL

        // clean up and return
        if err := os.Remove(media.Path); err != nil {
            fmt.Println("Was not able to remove file", err.Error())
            return fiber.NewError(fiber.StatusBadRequest, "Was not able to remove file")
        }

        defer func(dg *discordgo.Session) {
            err := dg.Close()
            if err != nil {
                fmt.Println(err)
            }
        }(dg)
        return ctx.JSON(r)

    log.Fatal(app.Listen(":" + os.Getenv("PORT")))
}

Conclusion

With less than 100 lines, you can set up a bot a discord bot and make it do extraordinary things for you. I hope that this blog post is helpful to you in any way!

If you did like this content, please follow me on GitHub and Twitter for more! Also, liking this post will help me a lot. See you soon!

Making TUI kanban app with BubbleTea | MongoDB Atlas Hackathon 2022 on DEV

Gabriel Grubba — Sat, 26 Nov 2022 22:16:02 +0000

What I built

A TUI(A terminal app with UI) Kanban app

I've taken what I saw in this playlist that was made by @bashbunni and took it to the next level.

I've made some adjustments and in order to this app be able to connect to a MongoDB and saved the data of the user.

Category Submission:

Think Outside the JS Box

App Link

repo

As it is a self-hosted app, you can download it and run it with the commands:

make sure that you provide a MongoDB URL in the .env file, the same way it is shown in the .env.example

go get
go run .

Screenshots

The main view:

The loading view:

The edit/add view:

Description

This full-CRUD app runs in your terminal with a beautiful UI.
It has three columns, To-do, In Progress, and Done columns. Where you can add tasks to the queue and edit them, changing the description or task location

Link to Source Code

repo

Permissive License

Background

I've decided to build this app because I wanted to learn Go and BubbleTea. Creating new features/recreating an app is an excellent way to get this knowledge.

Also, as a maintainer of an OSS project(MeteorJS) that has MongoDB as its first-class citizen, I wanted to see what other MongoDB drivers look like with other languages that are not JS. And got happy with the results.

How I built it

(How did you utilize MongoDB Atlas? Did you learn something new along the way? Pick up a new skill?)
I used MongoDB Atlas to save user's data in the database. So that whenever you close your terminal, you will not lose any data.

I would say that I learned a lot about Go and BubbleTea and how to use them to make glamorous command-line apps.

Also, I think I got better at MongoDB in general. After all, I could turn my language-specific understandings with MongoDB into general ones because I used them in an unfamiliar language.

Additional Resources/Info

Demo video:

Showing all CRUD operations

Started deleting old documents from DB

Created some task

Edit its column

Apaixone-se pela CHARM stack

Gabriel Grubba — Mon, 10 Oct 2022 21:53:28 +0000

Disclaimer

Esse post é uma tradução de um post de nome parecido feito por mim no blog oficial do MeteorJS com alguns ajustes para se adequar ao público brasileiro. Conhecimento tem sempre que estar disponível. Sempre que possivel, em meu tempo livre, irei estar traduzindo os posts de forma que o público brasileiro tenha esse conhecimento de ponta de forma nativa sobre esse framework que eu me apaixonei e posso estar trabalhando 100% do meu tempo nele.
Venha comigo nessa viagem com MeteorJS.

O que é MeteorJS

Acho que é sempre uma boa dar pelo menos uma relembrada no que é o MeteorJS.

"MeteorJS é um framework fullstack para desenvolvimento de aplicações cross-platform"

Produtividade é algo que o MeteorJS tem em seu coração faz um bom tempo, a ideia de código isomórfico, que faz com que você escreva menos e foque realmente no que importa é simplismente sensacional.

O que é e qual a razão dessa stack?

Caso queira tem o repo onde você poderá acompanhar todas as explicações das decisões técnicas.

Existe uma demo rodando aqui.
O objetivo de qualquer stack é te deixar mais produtivo em alguma tarefa, no caso da CHARM é levar essa produtividade a outro nível. Detalhadamente a stack é composta por:

MeteorJS - Fullstack framework focado em produtividade que usa RPC e Sockets embaixo do capô;
ReactJS - Lib de UI para criação de interfaces web;
Chakra UI - Biblioteca focada em simplicidade e produtividade;
MongoDB - Banco de dados NoSQL para criação de aplicações de maneiras mais práticas e rápidas;
Meteor Cloud - Provedor cloud acoplado a CLI do meteor, fazendo lançamentos de apps de maneira fácil, com bancos de dados incluido.

Como o projeto está estruturado?

Como muitas coisas da vida, o template desse projeto é inspirado nos trabalhos de Alex Kondov: Tao of Node e Tao of React

Muitos apps Meteor são feitos de maneira similar a um monorepo com suas divisões para front e back end declarado respectivamente em ui e api. Você pode ter uma pasta compartilhada para dividir código em sua codebase, como exemplo o front e back utilizarem dos mesmos tipos.

Uma boa pratica que é boa de ser ressaltada é a de organizar suas pastas por funcionalidade do sistema, não por funcionalidade técnica. Pensando sempre nos dóminios de sua aplicação.

Colocaremos tudo que será reutilizado em uma pasta chamada common que indica que ela estará no front e back.

Decisões do backend

Neste template, o banco de dados de escolha é o MongoDB, que é incluso automaticamente quando se cria um projeto MeteorJS. Também foi adicionado pacotes externos para ajudar com algumas rotinas especificas que você poderá encontrar, são eles: simpl-schema andpercolate:migrations. O primeiro para validar objetos e schemas em runtime e o outro para criar migrações no banco de dados.

Migrações do banco de dados

Quer um exemplo de como estruturar suas migrações ?

Use api/db/migration.js como refêrencia

Esse tipo de funcionalidade pode vir a ser útil a depender do tamanho da tua aplicação. Toda vez que o servidor começar, ele rodará o código que está localizado em api/main.js

import { Meteor } from "meteor/meteor";
import { Migrations } from "meteor/percolate:migrations";
import "./db/migrations";
import "./tasks/tasks.methods";
import "./tasks/tasks.publications";

/**
 * This is the server-side entry point
 */
Meteor.startup(() => {
  Migrations.migrateTo("latest");
});

Ele pega todas as migrações que ainda não foram aplicadas e as roda.

Um bom exemplo de utilização de migrações é quando há mudançãs em como seu banco está estruturado e você gostaria de alterar dados ou ter dados padrão para trabalhar em cima.

Para mais detalhes você pode olhar as docs.

Schemas

Schemas são uma maneira de garantir que os dados que vem de fora de sua aplicação estão conforme você os definiu, limpos e sanitizados.

Optamos pelo uso do simpl-schema e você pode observar seu uso em api/tasks/tasks.collection.js, fazendo isso, todos os dados que passam pelo banco de dados estão validados e seguem nossa estrutura definida.

Não esqueça de olhar as docs em caso de dúvidas.

Conectando-se ao servidor

Mantendo a ideia de ter uma pasta para cada funcionalidade, faremos a mesma coisa para conectar-se ao front-end. Similarmente ao tRPC e Blitz.js usaremos as chamadas remotas que em Meteor tem o nome de Meteor Methods em nosso template algumas chamadas ficam em api/tasks/tasks.methods.js.

/**
 * Remove a task.
 * @param {{ taskId: String }}
 * @throws Will throw an error if user is not logged in or is not the task owner.
 */
export const removeTask = ({ taskId }) => {
  checkTaskOwner({ taskId });
  TasksCollection.remove(taskId);
};
...
Meteor.methods({
  insertTask,
  removeTask,
  toggleTaskDone,
});

Para chamar esse method teremos de chamar ele por seu nome dessa maneira:

onDelete={taskId => Meteor.call('removeTask', { taskId })}

This sample comes from ui/tasks/TaskItems.jsx.

Decisões do Frontend

React com Meteor é ❤

Para nosso framework de frontend escolhemos o React por sua simplicidade e ecossistema. Meteor tem um pacote para fazer queries usando hooks, deixando você pensar apenas nas soluções que você precisa dar vida. Para mais informações veja o repo do react-meteor-data

O coração da produtividade: Chakra-UI

Para nossos componentes de UI, Escolhemos Chakra-UI pela sua simplicidade e produtividade. Que é comparavél com o que temos em nosso backend com meteor. Criando um fluxo de produtividade inigualável. Está incluso, modo light e dark em nosso template. Para a lista completa de componentes, veja nas docs do Chakra-UI

Ficou interessado?

Depois dessa maravilhosa explicação de nossa stack, espero que tenha vontade de testar e brincar com nosso template. Você pode clicar aqui para ver ele. Se houver alguma dúvida, pode nós mandar mensagem em nossas redes. Não esqueça de dar star no nosso Github também.

Forem: Gabriel Grubba

Faster Server Startup in Meteor 3.4 with Deferrables

Why were those functions added?

New API

Meteor.deferrable

Meteor.deferDev

Meteor.deferProd

Using deferrable with values

Migration & Conclusion

The fastest way of creating a real-time app with Zod and TypeScript

Table of contents

Introduction

Getting started

Creating a project

Setting up our React app

Starting our app

The chat collection

The chat module

The front-end

The Main page

The chat page

Deployment

Conclusion

Meteor v3 uses express under the hood – How to use and deploy it.

Table of contents:

Why use Express with Meteor?

Meteor installation

Creating your app

Temporary issue

Working with express

Deploy

Conclusion

Meteor is getting new docs!

Why are we making this change?

API Index

Information architeture

Why Vitepress?

New Meteor.js 2.14, updates to CLI and Tracker changes

Meteor CLI is being modernized

Addition of firstRunPromise

Dependencies updates

Special note about Meteor v3

Special thanks

Meteor Core issues for Hacktoberfest 2023

Making the Meteor.user API clearer

Documenting the main meteor function

Accounts not being able to correctly set their db name

Add --open to our command line

Make meteor create more interactive

Add TypeScript variations to meteor create

Calling Rust code from Go - the Gambiarra way

A more correct way.

How does this work?

In practice

New Suspense Hooks for Meteor

What about useTracker?

Why are these changes so significant?

Making Promises Suspendable

Why use suspense?

Using Discord as your CDN.

How to use it?

How is it done?

Creating HTTP server and Bot connection

Getting the file and the channel

Wrapping up and sending the URL

Conclusion

Making TUI kanban app with BubbleTea | MongoDB Atlas Hackathon 2022 on DEV

What I built

Category Submission:

App Link

Screenshots

Description

Link to Source Code

Permissive License

Background

How I built it

Additional Resources/Info

Apaixone-se pela CHARM stack

Disclaimer

O que é MeteorJS

Addition of `firstRunPromise`