Skip to content
8 min read

One Afternoon, One Chat App, One Framework That Changed How I Think

#Portfolio #Tech
JavaScriptWeb Development
One Afternoon, One Chat App, One Framework That Changed How I Think

There is a specific feeling you get when a framework just clicks. Not when you finally get it to work after hours of fighting the docs — but when it clicks on the first try. When it does exactly what you hoped it would, and then a little more. That was my first experience with Meteor.js.

I remember the exact moment. I ran meteor create, opened the browser, and there it was: a reactive counter updating in real time, zero server setup, zero database configuration, zero WebSocket boilerplate. I opened a second tab. Changed something. Watched both tabs react simultaneously. I was sold before I even understood how it worked.

That feeling has been sitting with me for a while. And now I finally have a reason to put it to the test.

The Setup: A Talk at PereiraJS

I’m going to give a talk at PereiraJS — a local tech community event at Universidad Tecnológica de Pereira. The topic is Meteor.js. And I’ve been thinking about what makes a great technical talk, and I keep coming back to the same answer: the demo.

You can explain a framework all day. Slides, diagrams, feature lists — none of it hits the same way as watching something real get built in front of you. So I’m not just going to talk about Meteor. I’m going to build a full, working, multi-user real-time chat application on stage. From scratch.

But first, I have to actually build it. To know it inside out. To hit the walls before I stand in front of a room and pretend there are no walls.

So this afternoon I sit down with a blank terminal and a very specific challenge: build the whole thing properly. Not a toy. Not a proof of concept with three files. A real app — authentication, multiple chat rooms, message history, clean architecture. All in one afternoon.

Let’s see how long it actually takes.

Why Meteor? Why Now?

To understand why I’m so excited about this, you need to feel what building a real-time app looked like before Meteor.

If you want a chat application today, you’re looking at something like this: Node.js with Express on the backend, Socket.io for WebSocket management, MongoDB for persistence, Mongoose for data modeling, Passport for auth — and then your choice of React, Angular, or Backbone on the frontend, each with its own build pipeline. Webpack. Babel. Maybe Gulp. A package.json with thirty dependencies before you’ve written a single line of product code.

By the time everything is wired and talking to each other, half the afternoon is gone. That’s JavaScript fatigue in its most concentrated form.

Meteor is the counter-argument to all of that. One command, and you have a full-stack app running: backend, frontend, database, build system, hot reload, all synchronized and talking to each other from minute one. The pitch is: you get from zero to a working prototype in the time it normally takes to configure webpack.

I’ve used it enough to know the pitch is real. Today I’m going to prove it.

The Build: Three Hours in Real Time

I start with the obvious move:

meteor create rocka-chat-tutorial
cd rocka-chat-tutorial
meteor

I open localhost:3000. There’s a running app. Not a hello-world static file — an actual full-stack application with a MongoDB instance, a Node server, a compiled client bundle, and hot reload, all active. That alone would have taken me an hour in any other stack.

The first thing I do before writing any feature code is plan the architecture. This is the part most tutorials skip, and I think it’s important. I’m building something I’ll present on stage, so it has to be clean.

imports/
  api/
    chats/
      chats.collection.js
      chats.methods.js
      chats.publications.js
    messages/
      messages.collection.js
      messages.methods.js
      messages.publications.js
    users/
      users.methods.js
      users.publications.js
  client/
    layouts/
    routes/
    templates/

The imports/api/ layer separates data modeling (collections), server-to-client data flow (publications), and client-to-server operations (methods). Clean separation before any business feature exists. I want to be able to point at this structure on stage and explain it without apologizing for any part of it.

With that in place, I install packages. Meteor’s package system is one of its genuinely good ideas — a few meteor add commands and I have user authentication, routing, reactive layouts, and state management. In another stack, this is where the afternoon starts slipping away. Here, it takes minutes.

Routing and Templates

The router I go with is kadira:flow-router paired with Blaze Layout. Three routes: / for the home/chat list, /login and /register for auth, and /chat/:chatId for individual rooms.

FlowRouter.route('/', {
  name: 'home',
  action() {
    BlazeLayout.render('mainLayout', { content: 'home' });
  },
});

FlowRouter.route('/chat/:chatId', {
  name: 'chat',
  action() {
    BlazeLayout.render('mainLayout', { content: 'chat' });
  },
});

The mainLayout template holds the persistent sidebar and navigation. Individual content templates swap in and out reactively as routes change. Clean, and I don’t have to think about it again.

Now I bring in the chat UI. Meteor’s Blaze templating system uses a Handlebars-like syntax that compiles to reactive DOM updates. This is the template that shows messages:

<template name="chat">
  <div class="chat-messages">
    {{#each messages}}
      {{> chatMessage}}
    {{/each}}
  </div>
  <form class="chat-input">
    <input type="text" name="message" placeholder="Type a message..." />
    <button type="submit">Send</button>
  </form>
</template>

That {{#each messages}} is not decorative. It is reactive. The moment the messages cursor updates anywhere — server push, new insert, anything — the DOM updates. No manual refresh, no explicit state management, no event listeners on data. Blaze handles all of it. I write the template once and forget about rendering.

Authentication in Twenty Minutes

Here’s one of those moments where Meteor’s magic really shows. Authentication is next. I add accounts-password to the project and I immediately have: user creation, password hashing, session management, token-based login state, the full stack. Everything.

I just need to connect the UI to it:

Template.register.events({
  'submit .register-form'(event) {
    event.preventDefault();
    const { email, password, username } = event.target;

    Accounts.createUser({ email: email.value, password: password.value, username: username.value }, (error) => {
      if (error) return; // show error
      FlowRouter.go('home');
    });
  },
});

No JWT setup. No bcrypt configuration. No session storage decisions. Accounts.createUser handles all of it. And login is equally simple — Meteor.loginWithPassword, a callback, done.

The last piece is route guards. Unauthenticated users shouldn’t see the chat. Already-authenticated users shouldn’t see the login page:

FlowRouter.triggers.enter([checkLoggedIn]);

function checkLoggedIn(context, redirect) {
  const publicRoutes = ['login', 'register'];
  if (!Meteor.userId() && !publicRoutes.includes(context.route.name)) {
    redirect('login');
  }
}

Auth is done. I’ve been at this less than an hour.

The Part That Made Me Fall in Love

Now we get to the heart of it. Collections, Publications, and Methods. This is what Meteor actually is underneath everything else.

A Meteor Collection is a MongoDB collection that exists in two places simultaneously: on the server (the real database) and on the client (Minimongo, an in-memory replica). They stay in sync automatically via DDP — Meteor’s real-time protocol, built on top of WebSockets.

I define Chats and Messages, and immediately lock down client-side writes:

export const Chats = new Mongo.Collection('chats');

Chats.deny({
  insert() { return true; },
  update() { return true; },
  remove() { return true; },
});

Nothing gets written directly from the client. Everything goes through the server. That’s the discipline. Now I need to control what data each client actually sees:

Meteor.publish('chats', function() {
  if (!this.userId) return this.ready();
  return Chats.find({ usersIds: this.userId });
});

That’s it. “Publish the chats where this user is a member.” The server decides what data to send, filtered per user, scoped to exactly what’s relevant. The client subscribes and automatically receives updates when that data changes. No polling. No manual fetch. No cache invalidation.

And for mutations — sending a message, creating a chat — everything goes through Meteor Methods:

Meteor.methods({
  'messages.insert'(chatId, text) {
    if (!this.userId) throw new Meteor.Error('not-authorized');

    const chat = Chats.findOne({ _id: chatId, usersIds: this.userId });
    if (!chat) throw new Meteor.Error('not-authorized', 'You are not part of this chat.');

    Messages.insert({
      chatId,
      ownerId: this.userId,
      text: text.trim(),
      createdAt: new Date(),
    });
  },
});

And on the client, calling it:

Meteor.call('messages.insert', chatId, messageText);

One line. What happens behind that one line is the beautiful part: Meteor executes the Method on the server. The server inserts the document. MongoDB notifies the oplog observer. DDP pushes the change to all subscribed clients. Minimongo updates. Blaze re-renders the message list.

Two users. Two browser windows. One message typed. It appears on both screens in under a hundred milliseconds.

No polling. No manual socket management. No explicit state sync.

I open two tabs. I type. I stare at the screen for a second. Then I laugh, because it works exactly like that.

End of the Afternoon

Three hours later, I have a fully working real-time chat application:

  • User registration and login with hashed passwords
  • A friend list showing all other registered users
  • Creating a new chat with any friend
  • Sending and receiving messages in real time across multiple browser windows
  • Full message history when you return to a room
  • Removing a chat, with message cleanup
  • Route guards that keep unauthenticated users out
  • All writes validated on the server through Methods

Nine commits of real work. Architecture planning, collection schemas, routing, auth, complete chat functionality with history and deletion. The heavy lifting — real-time sync, authentication, reactivity, rendering — all handled by Meteor, all coordinated automatically.

I close my laptop. The demo is ready. Not because I cut corners, but because Meteor didn’t make me fight for the basic things. I spent my three hours thinking about the product, not the plumbing.

Final Reflection

Real-time doesn’t have to be complicated. That’s the lesson from this afternoon. It wasn’t a hack or a shortcut — it was simply using a tool that let me think about what I wanted to build instead of fighting the infrastructure to get there.

There’s something powerful about sitting down with an idea and having it working before your coffee gets cold. Not because you’re fast, but because nothing got in the way. That’s the feeling I want to chase in every project I start from here on out.

Resources