DEV Community: Guilherme Araujo

Understanding Lighthouse: The Metrics That Actually Matter for Performance and SEO

Guilherme Araujo — Thu, 10 Jul 2025 12:52:43 +0000

🔍 What Is Lighthouse?

Lighthouse is an automated tool that audits web pages and generates a report about five main categories:

Performance;
Accessibility;
Best Practices;
SEO;
Progressive Web App (PWA).

For example, here's the Lighthouse report for dev.to's main page:

The report gives each category a score, along with helpful suggestions for improvement. Here, we’ll focus mainly on the Performance category — the one that impacts users the most, and is often the most important when it comes to SEO and UX.

Performance

The Performance score in Lighthouse is based on a set of real-world metrics, many of which are part of Google’s Core Web Vitals. These metrics measure how your site loads and responds from the user’s point of view.

Let’s break them down:

First Contentful Paint (FCP)

Measures how long it takes for the first piece of content to show up on the screen, like text or an image. It gives users feedback that something is happening.

Largest Contentful Paint (LCP)

Tells you how long it takes for the main piece of content to load, usually a large image or headline. It shows when the page becomes useful.

Speed Index

Tracks how quickly visible parts of the page appear during loading. Lower scores mean faster and smoother loading.

Time to Interactive (TTI)

Measures how long the page takes to become fully usable. In summary, when a user can click or type without delays.

Total Blocking Time (TBT)

Adds up how much time the browser is “too busy” to respond to user input, often due to heavy JavaScript tasks.

Cumulative Layout Shift (CLS)

Tracks unexpected layout changes, like when content moves while the page is still loading. This helps prevent those annoying jumps that make users click the wrong thing.

How Are Lighthouse Scores Calculated?

Not all metrics count the same toward the final performance score. Metrics like LCP and TBT have more weight because they directly affect how smooth the site feels to real users.

Lighthouse uses real-world data from tools like the HTTP Archive and Chrome UX Report to compare your site with others on the web.

Here’s the current weight breakdown:

Largest Contentful Paint (LCP): 25%
Total Blocking Time (TBT): 30%
Cumulative Layout Shift (CLS): 15%
First Contentful Paint (FCP): 10%
Speed Index: 10%
Time to Interactive (TTI): 10%

What About the Other Categories?

Performance is super important, but the other Lighthouse categories also matter:

Accessibility checks if your site works well for people with disabilities.

Best Practices makes sure you’re following web and security standards.

SEO looks at basic on-page SEO, like titles, meta tags, and headings.

PWA checks if your site can work like an app on mobile devices.

These don’t directly affect Core Web Vitals, but they’re key for overall user experience.

🚀 How to Improve Your Scores

Improving your Lighthouse performance score doesn't mean rewriting your entire site, many optimizations are small tweaks that can have a big impact. Let’s dive deeper into the most effective techniques and how they help your metrics.

Optimize Images

Images often make up the bulk of a page’s weight. If they’re not optimized, they can slow down your site dramatically.

Use modern formats like WebP or AVIF: These formats offer better compression than traditional formats like JPEG or PNG, reducing file sizes without losing quality.
Resize images to match display sizes: Don’t load a 5000px-wide image if it’s only going to show at 300px.

Metrics impacted: Largest Contentful Paint (LCP), Speed Index

Reduce and Split Your JavaScript

JavaScript is powerful, but too much of it can cause delays in loading and make the browser unresponsive.

Bundle splitting: Tools like Webpack, Vite, or Next.js allow you to split your code into smaller chunks that are loaded only when needed.
Tree shaking: Remove unused code from third-party libraries during bundling.
Avoid unnecessary frameworks or heavy dependencies: Sometimes vanilla JS or lighter libraries can do the same job.

// webpack.config.js
module.exports = {
  entry: {
    main: "./src/index.js",
  },
  optimization: {
    splitChunks: {
      chunks: "all",
    },
  },
};

// Only importing what you need
import { debounce } from 'lodash-es';

// Instead of a full UI framework, use vanilla:
document.querySelector('#btn').addEventListener('click', () => {
  alert('Clicked!');
});

Metrics impacted: Total Blocking Time (TBT), Time to Interactive (TTI)

Use Lazy Loading

Lazy loading defers the loading of non-critical content, like images below the fold, until the user is about to see them.

Add the loading="lazy" attribute to <img> and <iframe> elements.
For background images or custom components, you can implement lazy loading with JavaScript.

This helps reduce the initial load size, speeding up the time it takes for your page to become interactive.

<img src="photo.jpg" loading="lazy" alt="Lazy-loaded photo">
<iframe src="video.html" loading="lazy"></iframe>

Metrics impacted: First Contentful Paint (FCP), Speed Index, LCP

Avoid Render-Blocking Resources

Render-blocking resources delay how quickly the browser can start rendering the page. These usually include large CSS files or scripts loaded in the <head>.

Minify and inline critical CSS to reduce blocking.
Defer non-essential JS using the defer or async attributes.
Use font-display: swap for web fonts to avoid text invisibility.

Metrics impacted: FCP, TTI, TBT

Enable Caching

Caching stores files locally so they don’t need to be downloaded again on future visits.

Use HTTP cache headers like Cache-Control or ETag.
Serve assets with hashed filenames (e.g., style.abc123.css) so browsers can cache them safely.
Use a service worker (especially for PWAs) to cache offline-friendly resources.

Metrics impacted: Repeat view performance, Time to Interactive, Speed Index

By applying these strategies, you're not just improving your Lighthouse score, but you’re making your site smoother, more responsive, and more enjoyable for everyone who visits.

Even small changes can lead to meaningful gains in user experience, which ultimately means better engagement, higher retention, and stronger SEO.

Hosting web app on your old Android phone

Guilherme Araujo — Sun, 20 Apr 2025 22:47:36 +0000

Recently, I was developing a simple bot to interact with a WhatsApp group. The code was pretty straightforward: a webhook that would read messages from the app and save data to a MongoDB database. As I continued working on the bot, I realized I needed to learn more about deploying such applications in real-world environments. To do this, I decided I wanted to self-host the application on a local server, like a Raspberry Pi, and started researching different models and their prices.

However, to my surprise, the prices for these devices had significantly increased due to a global chip shortage and the rising demand for Raspberry Pis. After spending some time looking at the inflated prices, I grew frustrated and began considering alternative solutions. That's when it hit me: I have an old Android phone – a Galaxy S9 – which is still quite powerful and functional even by today’s standards. Since it’s an Android, I wondered, could I run Linux on it?

Curious to explore this possibility, I began researching how I could run a Node.js application on my phone. Spoiler alert: it worked!

In this article, I’ll walk you through how I managed to turn my Galaxy S9 into a fully functional Node.js server using Termux. Along the way, I learned how Termux transforms an Android device into a powerful Linux environment, and how you can leverage your old phone as a local server for development or even small-scale production tasks. This setup can be incredibly useful if you’re looking to experiment or deploy projects without investing in extra hardware.

Installing Termux

The first step is to install Termux, which is a powerful terminal emulator for Android that provides a Linux-like environment.

Go to the Play Store on your Android phone and install Termux.

Opening Termux

Once installed, open the Termux app, and let’s start by updating all the Termux packages:

pkg update

Setting Up SSH Access

To make things easier and avoid constantly typing on the phone’s small keyboard, I decided to set up SSH so that I could access the phone remotely from my computer.

1- Install the openssh package:

pkg install openssh

2- Start the SSH server:

sshd

3- Find the Termux IP address:

ifconfig

4- Find the Termux username:

whoami

5- Set a password for SSH access:

passwd

Now, from your computer, you can connect to your phone via SSH:

ssh <username>@<Termux_IP_address>

At this point, you have a fully functional Linux environment running on your phone, and you can access it remotely via SSH.

Optionally, you can install tmux, a terminal multiplexer, which allows you to execute multiple applications in the same terminal session. I used tmux to manage tasks like port forwarding and running the Node.js application simultaneously.

Setting Up a Cloudflare Tunnel

To expose your application to the internet, you can use Cloudflare Tunnel. This will create a secure connection between your local server and the internet, making your Node.js application accessible.

1- Install cloudflared:

pkg install cloudflared

2- Run the following command to create a tunnel for your application:

cloudflared tunnel --url http://localhost:3000

Once the tunnel is running, you’ll be provided with a public URL that you can use to access your API from anywhere.

Installing Node.js

Termux makes it incredibly easy to install Node.js and start building applications.

1- To install Node.js, simply run the following command:

pkg install nodejs

2- Once Node.js is installed, you can start your Node.js application and expose it to the internet using the Cloudflare tunnel we set up earlier.

After completing these steps, my Node.js application was successfully running and publicly accessible, all from my old Android phone! I was able to deploy my bot, which interacted with the WhatsApp group and stored data in MongoDB, directly from my phone. This setup is surprisingly powerful and proves that you don’t need expensive hardware to host applications; an old Android phone can easily do the job.

Optimizing End-to-End Testing: Strategies for Speed, Reliability, and Efficiency

Guilherme Araujo — Mon, 27 Jan 2025 18:04:55 +0000

Best Practices for Efficient E2E Testing

Quick Overview: What Are E2E Tests?

End-to-End (E2E) tests are designed to run on top of your application, simulating real user interactions such as clicking buttons, typing input, navigating between pages, and more.

These tests are extremely useful for checking that entire workflows work as expected. For example, in an eCommerce application, an E2E test could simulate a complete purchase journey: selecting a product, adding it to the cart, registering a credit card, and completing the checkout process. By testing real-world scenarios, E2E tests help ensure your application's key features work well together.

Context

Recently, in my current project, we faced the task of restoring some old, skipped E2E tests. While working through them, we observed several opportunities for improvement. Many of these tests could be merged or rewritten in a more efficient way, and we realized that our approach of restoring the database for every test was significantly increasing the execution time.

Additionally, we identified potential to parallelize some of the test scenarios, which could further optimize our testing process. These observations led us to focus on techniques to improve performance, such as merging and optimizing test cases, leveraging parallelization, and rethinking our database restoration strategy. In this article, I'll share these strategies, primarily based on my experience using Playwright as an E2E testing tool. However, these techniques are likely applicable to most E2E testing frameworks.

Test Parallelization

Parallelization Across Files

Parallelizing tests is one of the most effective ways to speed up E2E test execution, especially as your test suite grows. By running multiple tests simultaneously, you can utilize your system's resources more efficiently and significantly reduce the total runtime.

In our project, we configured Playwright to use 5 workers by default. Each worker runs a test file independently, enabling up to 5 tests to execute at the same time. Here's how we set it up:

// playwright.config.js  
import { defineConfig } from '@playwright/test';  

export default defineConfig({  
  workers: 5, 
});

This simple change led to a significant improvement in test execution speed, as multiple tests could run concurrently.

However, some tests required rewriting due to side effects. For instance, certain tests created or modified resources that other tests depended on. When these tests ran in parallel, their execution order sometimes caused failures, as the shared state was not properly managed.

Parallelizing Tests Within Files

In addition to parallelizing tests across multiple files, we found that it’s also possible to enable parallel execution within a single test file. This approach is especially useful when you have multiple independent tests grouped in the same file and want to further optimize execution time.

In Playwright, this can be achieved by wrapping your tests in test.describe.parallel. All tests inside this block will execute simultaneously:

test.describe.parallel('Group of parallel tests', () => {  
  test('Test 1', async ({ page }) => {  
    // Test logic here  
  });  

  test('Test 2', async ({ page }) => {  
    // Test logic here  
  });  
});

Based on our experience parallelizing tests across files, the key principles remain the same:

Avoid Side Effects: Ensure that tests are fully independent and do not share or modify resources in a way that could interfere with other tests;
Reuse Resources Wisely: Manage shared resources, such as browser instances or test data, efficiently to prevent contention or conflicts during parallel execution. This technique can deliver a noticeable speedup for large test files, but it also requires careful planning to maintain test reliability and avoid flaky results. By isolating tests and managing resources effectively, you can take full advantage of parallel execution within files.

Pre-Authentication

Pre-authentication is a critical step to ensure that each test begins with a consistent, valid user session. This technique eliminates the need to repeatedly perform login actions for every test, significantly improving both speed and reliability in the tests, especially when tests are executed in parallel.

The approach involves leveraging Playwright’s ability to work with storageState, which stores session information (e.g., cookies, local storage) for pre-authenticated users. By restoring this state at the beginning of each test, the user is already logged in, allowing tests to focus on verifying functionality rather than navigating login flows.

test('User View - TEST_ID#153', async ({ browser }) => {  
  const context = await browser.newContext({
    storageState: path.join(__dirname, `../.auth/${email}.json`), // Pre-authenticated session
  });  
  const page = await context.newPage();  
  await page.goto('/'); // User is already logged in at this point
});

This approach guarantees that each test operates in isolation, preventing cross-contamination of session data. The pre-authenticated storageState ensures that tests skip redundant login steps, saving valuable time while maintaining consistency across the suite.

Of course, there are challenges to consider, such as ensuring that the .auth/${email}.json files are consistently updated with valid session data. Additionally, it's important to focus on the reusability of helper functions, avoiding tightly coupled data or risky code that could compromise the maintainability and reliability of the test suite.

Best Practices for Efficient E2E Testing

To maximize the efficiency of your E2E tests:

Prioritize Test Isolation: Ensure that tests are independent and avoid shared state wherever possible;
Minimize Dependencies: Pre-authentication and reusable helpers can reduce redundancy and improve test reliability;
Monitor Pipeline Performance: Regularly review test runtimes and resource utilization to identify bottlenecks or opportunities for optimization;
Balance Coverage and Execution Time: Focus on covering critical workflows without overloading the pipeline with unnecessary tests.

By adhering to these best practices, you can build a robust, scalable, and efficient E2E testing framework that delivers reliable results while saving time and resources.

Conclusion

Optimizing E2E tests is an ongoing process that involves balancing performance, reliability, and coverage. By leveraging techniques like test parallelization, pre-authentication, and careful resource management, you can significantly improve test execution times without compromising accuracy. While challenges such as side effects and maintaining reusable code require attention, the benefits of a well-optimized E2E suite far outweigh the effort. These practices, when implemented thoughtfully, pave the way for a more efficient and reliable testing process, enabling faster delivery of high-quality software.

Handling Promises with Higher-Order Functions in JavaScript

Guilherme Araujo — Tue, 17 Dec 2024 16:45:50 +0000

When working with arrays in JavaScript, you may find yourself needing to make asynchronous calls inside methods like forEach, .map, or similar functions. But after encountering errors or unexpected outputs, you might wonder, Why isn’t this working as expected? In this article, we’ll dive into these situations and explore how to handle promises effectively within higher-order functions.

What is a higher-order function?

Starting from the beginning:

A higher order function is a function that takes one or more functions as arguments, or returns a function as its result.

A simple example would look like this:

// Higher-order function that returns a function
function createAdder(x) {
  return function(y) {
    return x + y;
  };
}

const addFive = createAdder(5);
console.log(addFive(3)); 
// Console output: 8

What is a Promise?

The Promise object represents the eventual completion (or failure) of an asynchronous operation and its resulting value.

A Promise is an object representing a value that may not be available yet but will be resolved in the future. Promises allow you to attach handlers to manage the eventual success or failure of an asynchronous operation, making it easier to handle responses as they arrive.

This pattern is especially useful in cases like:

API calls: When fetching data from external sources, such as RESTful APIs, the data may take time to arrive;
Database interactions: Querying a database can also be time-consuming, so promises allow you to handle the data only once it’s available.

Instead of returning the final data instantly, these asynchronous functions return a promise, which acts as a placeholder for the value that will be provided later.

Given these two concepts, let’s see how they interact.

Combining Promises with Higher-Order Functions: Practical Examples

Now that we understand promises, let’s look at a common use case: fetching data, such as retrieving user information from an array of user IDs:

const userIds = [1, 2, 3];

// Simulated async function to fetch user data
const fetchUser = async (id) => {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve(`User ${id} data`);
    }, 1000);
  });
};

❌ The Common Mistake: Not Handling the Array of Promises Properly
When using .map with an asynchronous function, a common mistake is forgetting that map will immediately return an array of promises instead of resolved values. Without additional handling, this leads to unexpected results:

const wrongWay = async () => {
  // This creates an array of promises, not resolved values!
  const users = userIds.map(async (id) => {
    return await fetchUser(id);
  });

  console.log(users); // Output: [Promise, Promise, Promise]
};

In this example, each call to fetchUser(id) returns a promise, so map returns an array of promises rather than the final data values. Simply awaiting inside .map doesn’t resolve the array itself; instead, it just creates a promise for each item in the array.

✅ The Correct Approach: Using Promise.all with map
To properly handle an array of promises, you need to use Promise.all. This method takes an array of promises and returns a new promise that resolves once all the promises in the array are fulfilled. Here’s how to use Promise.all to get the resolved data:

const rightWay = async () => {
  const users = await Promise.all(
    userIds.map(id => fetchUser(id))
  );

  console.log(users); // Output: ["User 1 data", "User 2 data", "User 3 data"]
};

.filter function

Like .map, the .filter function can lead to unexpected behavior when combined with asynchronous functions. Suppose we want to filter an array of user IDs to retrieve only the IDs of users that meet certain criteria, such as users with IDs that are "active."

Let’s take a look at a common mistake and how to avoid it.

❌ The Common Mistake: Using .filter with Async Functions

const isActiveUser = async (id) => {
  return new Promise((resolve) => {
    setTimeout(() => {
      // Simulates checking if a user is active
      resolve(id % 2 === 0); // Returns true for even IDs, false for odd ones
    }, 1000);
  });
};

const wrongFilterUsage = async () => {
  const activeUsers = userIds.filter(async (id) => {
    return await isActiveUser(id);
  });

  console.log(activeUsers); // Output: [1, 2, 3] — the original array, not the filtered results
};

In this example, .filter doesn’t wait for isActiveUser(id) to resolve, so it operates on the original array of IDs rather than the resolved results. The array activeUsers ends up containing all user IDs, regardless of whether they are active, because the async function inside .filter doesn’t return the expected boolean.

✅ The Correct Approach: Using Promise.all with .map and .filter
To properly filter an array with an async function, we need to use .map in combination with Promise.all to resolve all promises first, then apply .filter on the resolved values. Here’s the correct approach:

const correctFilterUsage = async () => {
  // Use Promise.all to resolve the async checks for each user ID
  const results = await Promise.all(
    userIds.map(async (id) => ({
      id,
      isActive: await isActiveUser(id),
    }))
  );

  // Filter based on the resolved isActive status
  const activeUsers = results
    .filter(user => user.isActive)
    .map(user => user.id);

  console.log(activeUsers); // Output: [2] — only active user IDs
};

💡Promise.all
Using Promise.all offers several advantages for handling asynchronous tasks, especially when working with multiple promises simultaneously:

Parallel Execution of Requests: One of the primary benefits of Promise.all is its ability to execute multiple promises in parallel. When you pass an array of promises to Promise.all, it initiates all of them at the same time, allowing each promise to start processing concurrently. This can greatly improve performance by reducing the overall wait time, as all tasks are "in progress" together.

Example: If you’re fetching data for multiple users or making multiple API requests, Promise.all allows you to start each request without waiting for others to finish. This is particularly valuable for tasks where the order of execution doesn’t matter, like retrieving data from different sources.

⚠️ Caution: Use Promise.all carefully, as parallel execution may not always be ideal. For cases where tasks depend on one another or need to run sequentially (e.g., writing to a database in a specific order), parallel execution may cause issues. We’ll explore sequential handling methods later on.

Simplified Error Handling: Another powerful feature of Promise.all is its error-handling mechanism. If any promise in the array rejects, Promise.all will immediately reject with that error, allowing you to handle failures in a single .catch block. This makes error management more streamlined and efficient.

Note: Only the first rejection triggers the error; the remaining promises will continue to execute but won’t trigger further .catch blocks. If you need to capture each promise's result regardless of failure, consider using Promise.allSettled, which returns an array of outcomes for each promise, detailing whether they resolved or rejected.

Aggregated Results: Once all promises in Promise.all resolve, it returns an array of the resolved values, matching the order of the original promises. This makes it easy to work with the final results in a predictable way, even though each promise completes independently.

Summary Table

There are a lot of higher-order functions available in JavaScript, but here is a attempt to create a cheat sheet to make it easier to remember how the most common functions deal with asynchronous operations:

Method	Common Issue	Correct Solution
.filter	Returns array of promises	Use `Promise.all` with `.map`, then filter synchronously
.forEach	Doesn’t wait for async functions to complete	Use `Promise.all` with `.map` (parallel) or `for...of` with `await` (sequential)
.find	Doesn’t wait for async condition to resolve	Use `for...of` with `await` to find the first match sequentially
.reduce	Returns promise for each iteration	Use async `reduce`, awaiting the accumulator before each iteration

for...of for Sequential Async Processing

As mentioned earlier, simultaneous processing isn’t always ideal, especially when tasks depend on each other or could overload a server or API. In such cases, handling tasks sequentially can be beneficial, as it ensures that each task completes before the next one begins.

This is where the for...of loop becomes valuable. Unlike .map or .forEach, for...of allows you to await each asynchronous operation in sequence, ensuring that each task completes before moving on to the next. This approach is particularly useful in situations like making API calls that should occur in a specific order, processing a list of database writes sequentially, or handling rate-limited operations where triggering requests all at once could lead to errors.

An example of for...of:

const userIds = [1, 2, 3];

// Async function that simulates an API call
const fetchUserData = async (id) => {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve(`User ${id} data`);
    }, 1000);
  });
};

const fetchAllUserData = async () => {
  const userData = [];

  for (const id of userIds) {
    const data = await fetchUserData(id); // Each call waits for the previous one to complete
    userData.push(data);
  }

  console.log(userData); // Output: ["User 1 data", "User 2 data", "User 3 data"]
};

fetchAllUserData();

In this example, each fetchUserData call only starts after the previous one finishes, ensuring the operations are processed sequentially.

Wrapping Everything up

Working with asynchronous operations inside higher-order functions can be tricky and often leads to misunderstandings and unexpected results. Each method—whether .map, .filter, .forEach, .find, or .reduce —behaves differently with async functions, and recognizing these nuances is key to avoiding common mistakes. By understanding how each function handles promises and when to use tools like Promise.all or the for...of loop, you can significantly improve both the readability and reliability of your asynchronous code.

Hopefully, this guide will help clarify any questions that arise about how functions and promises behave in different scenarios.

Common Mistakes of a Developer Starting with Meteor.js

Guilherme Araujo — Mon, 28 Oct 2024 20:45:42 +0000

After nearly two months of working with Meteor.js, I find it valuable to document some of the most common mistakes I've made while using the framework. In this article, I’ll delve into the typical errors and questions I've encountered from fellow beginners, aiming to provide insights that can help others avoid the same pitfalls.

Poor optimized and unsafe Publications

On my first publication I've created a code like this:

export const Events = new Mongo.Collection('events');

Meteor.publish('events.list' => Events.find({ });

In the example above, we create a collection called events and then declare a publication called events.list that returns a collection cursor to the entire collection with all its fields. Once the client subscribes to it, all this data will be sent to the client and will be monitored for any updates that occur in the collection.

Although it might seem like magic, this reactivity comes with a significant computational cost. The system has to monitor the entire collection, compare the differences between new and old data, and update the client with each change.

Optimizing your Publication

To create performatic and optimized queries we need to understand some concepts about the publications we create:

Use Filters to Retrieve Relevant Data: Applying filters in your find({ }) queries is crucial for ensuring that only relevant data is retrieved from the database. Filters allow you to precisely define the subset of data you want to fetch, based on conditions such as user ID, date range, or any other criteria. By doing so, you avoid retrieving unnecessary or irrelevant records (e.g., data belonging to other users or outdated entries), which could unnecessarily increase the amount of data sent to the client.
Well-designed filters not only enhance security by ensuring that users only receive their own data but also reduce both server load and network traffic by minimizing the data processed and transmitted;
Leverage Projections for Fine-Grained Control: Projections allow you to retrieve only the specific fields you need from your documents, instead of sending the entire document to the client. This prevents large, unnecessary objects from being transferred and reduces memory overhead on the client-side. By sending only the essential fields, you also optimize memory usage and minimize the load on the client's processing.
For example, if you only need the name and date of the event, you can write:

Meteor.publish('events.list' => 
  Events.find({ }, { fields: { name: 1, date: 1 } }
);

Paginate Large Data Sets: If you are working with large data sets, consider implementing pagination. This allows you to send data in smaller, more manageable chunks, improving performance and providing a smoother user experience;
Security - Protect Sensitive Data: Publishing entire collections without any restrictions can unintentionally expose sensitive data from your application. This is a significant security risk. By applying filters and projections, you can control exactly what data is sent to the client, ensuring that only the necessary and non-sensitive information is exposed. This practice not only optimizes performance but also safeguards your application by preventing unintended data leaks.

After passing thru all these concepts, now we can refactor our initial subscription:

import { check } from 'meteor/check';

Meteor.publish('events.list', function (page) {
  if (!this.userId) {
    return this.ready(); // Stop publication if the user is not authenticated
  }

  check(page, Number);
  if (!page || page <= 0) page = 1;

  const LIMIT = 10;

  // Calculate how many documents to skip based on the page number
  const skip = (page - 1) * LIMIT;

  return Events.find(
    { userId: this.userId }, // filter by current user's events
    {
      fields: { name: 1, date: 1 }, // only return necessary fields
      limit: LIMIT,                 // limit the number of documents returned
      skip: skip                    // skip documents based on page number
    }
  );
});

Too much reactivity - useSubscribe everywhere

As mentioned earlier, leveraging subscriptions in Meteor.js can feel like magic, providing you with reactive data on the front-end with minimal effort. However, over-relying on this feature can lead to messy, hard-to-debug, and inconsistent code.

When a document is published by the back-end and you subscribe to it on the front-end, the data is stored in a client-side in-memory database called minimongo. This allows you to easily access data using Collection.find({}) or Collection.findOne({}). But as your project scales and multiple components manage the same data, this can become complicated.

For instance, consider a details page that follows a listing. If your subscription is placed within the listing component and a user navigates directly to the details page via the URL, the required data may not be available for display.

To avoid this issue, it’s essential to understand where data is being used and to evaluate whether it truly needs to be reactive. Using Meteor methods allows you to fetch data like a standard HTTP call from your back-end, eliminating the guesswork about data availability. This approach not only simplifies data management but also enhances performance by reducing unnecessary reactivity, leading to cleaner and more maintainable code.

Data Merge Issues

One common challenge in Meteor.js arises from managing multiple subscriptions, especially when dealing with overlapping data. This can often occur due to an excessive number of subscriptions or a misunderstanding of how publications work.

Consider the following example, where two subscriptions pull different fields from the same collection:

return Events.find({}, { fields: { date: 1, host: 1 } });
return Events.find({}, { fields: { 'host.name': 1 } });

On the client side, Meteor only maintains a single copy of each document, regardless of how many subscriptions exist. The server determines which fields to send to the client using a mechanism called the 'MergeBox'. Ideally, with both of these subscriptions active, the client would have the complete host data, since one subscription provides the full host object and the other supplies only a partial view.

However, the MergeBox operates only at the top field level, as explained in Meteor's documentation:

If more than one subscription sends conflicting values for a field (same collection name, document ID, and field name), then the value on the client will be one of the published values, chosen arbitrarily.

This means documents aren’t deeply merged. Sometimes, the full host from the first publication will be displayed, while other times, the client may receive only the partial host.name from the second publication, leading to inconsistent data on the front-end.

Sorting in Publications

When a client subscribes to a publication, the data it receives is merged with existing data in the client’s minimongo store. This merging process doesn’t always respect the original sorting order from the server, which can result in records being displayed in an incorrect order.

To avoid this, it's often unnecessary to handle sorting within the publication itself unless the order of the data is dynamic (e.g., for pagination or live updates). Instead, you can delegate sorting to the front-end when retrieving data from minimongo. This ensures the data is always presented in the desired order without risking a mix-up due to how subscriptions are processed.

For example, you can apply sorting directly when querying your local collection on the client:

Events.find({}, { sort: { date: -1 } });

Conclusion

Working with Meteor.js offers a powerful and flexible way to build real-time applications, but like any framework, it comes with its own set of challenges. Through my experience, I’ve learned that understanding the inner workings of subscriptions, data reactivity, and minimongo is crucial for avoiding common pitfalls. Over-reliance on reactivity can lead to performance issues, and managing multiple subscriptions without proper planning can cause data inconsistencies.

By taking control of data flow—whether by strategically using Meteor methods for non-reactive data, managing data subscriptions at higher levels, or handling sorting on the client side—you can ensure cleaner, more maintainable code. With careful consideration of these practices, your Meteor.js projects will not only perform better but also be easier to debug and scale.

Special thanks to my teammates João Ladeira, Isaque, and Renan for helping me understand these concepts and rescuing me from these pitfalls.