A quick context note. I’m a Senior Product Manager at Confluent on the SQL and engine layer of Confluent Cloud for Apache Flink. So the part of the platform that data engineers actually touch when they’re writing streaming queries.

The problem of evolving a long-running streaming query

In a relational database, evolving a derived dataset is barely an operation. You write a new view or run an ALTER. You move on. The data isn’t going anywhere. It’s sitting on disk waiting for the engine to read it on demand.

Streaming is a whole other story. The data isn’t sitting still. It’s flowing through continuously. A streaming SQL query isn’t a one-shot computation that finishes. It’s a long-running process that consumes events forever and keeps a derived output up to date as new events arrive.

To change the query, you have to stop that long-running process. The moment you do, a stack of decisions opens up that the engine cannot make for you.

• What do you do with everything you’ve already processed?
• Where in the source event log does the new query resume from?
• Do you reprocess history with the new logic or only apply it going forward?
• Do downstream consumers see a gap, a duplicate window or neither?

Until now, none of this was fully automated in Confluent Cloud for Apache Flink. The shape of the workaround was always roughly the same. Stop the running statement. Note the Kafka offsets the old job had consumed. Submit the new statement. Configure it to start from those offsets. Coordinate the cutover with downstream consumers. Hope nothing duplicated or got dropped on the boundary.

Across the customer interviews we did, this kept coming up. Teams had built real-time pipelines that worked with good latency leading to real business value. Then someone needed to add a column to the output or fix a bug in a transformation. That one change turned into a multi-day operation.

This isn’t a Confluent-specific problem. The Apache Flink community has been working on related ideas in the open through several FLIPs.

What Materialized Tables are

A Materialized Table is a persistent catalog object in CC Flink that looks like a database table. There’s a continuously running streaming query underneath it. From the user’s side, you SELECT from it, you DESCRIBE it, you treat it as the persistent representation of a derived dataset.

Let’s see an example. Suppose you have an orders stream and you want a continuously updated view of high-value orders:

CREATE MATERIALIZED TABLE high_value_orders (   
  `order_id` STRING,
  `customer_id` INT,
  `price` DOUBLE ) AS 
SELECT order_id, customer_id, price 
FROM examples.marketplace.orders 
WHERE price > 50.00;

After it runs, high_value_orders shows up as a table in your catalog. SELECT * FROM high_value_orders works the way you’d expect. If you wire up a Kafka consumer to the underlying topic, that works the way you’d expect too. There’s no separate “statement” to babysit. The long-running job is associated with the table directly and lives on the its overview page in the UI.

Now suppose you want to add product_id to the output. In the old world, that was a small change with a big operational tail. With Materialized Tables, it’s one statement:

CREATE OR ALTER MATERIALIZED TABLE high_value_orders (
  `order_id` STRING,
  `customer_id` INT,
  `price` DOUBLE,
  `product_id` STRING ) AS 
SELECT order_id, customer_id, price, product_id 
FROM examples.marketplace.orders 
WHERE price > 50.00

When you submit this, the platform stops the old job, starts a new one with the updated logic, picks up where the previous job left off (by default) and continues writing to the same output topic. The customer_id and price records you already produced stay where they are. New records carry the new column. No offsets to capture, no manual cutover. Plus, your schema is automatically updated along the way.

You can see the change in an Evolution History tab on the table’s overview page, with a timestamped diff of every ALTER that has been applied.

Controlling reprocessing with START_MODE

The example above quietly relied on a default. The interesting question on every evolution is, where in the source should the new logic start reading from? START_MODE is the clause that gives you explicit control over where the new job starts reading from. It works on both CREATE and ALTER:

CREATE OR ALTER MATERIALIZED TABLE filtered_high_value_orders (
  `order_id`    BIGINT,
  `customer_id` STRING,
  `order_total` DOUBLE
)
START_MODE = FROM_NOW
AS
SELECT order_id, customer_id, order_total
FROM all_orders
WHERE order_total > 1000;

A few practical patterns you can implement easily with MTs:

• “I want to add a nullable column going forward.” Use the default. The new column is populated for records produced after the evolution. Older records keep their schema. Downstream consumers that handle schema evolution don’t need to know an evolution happened.
• “I shipped a bad WHERE and want to reprocess the last week.” Use FROM_INTERVAL('7' DAY) or FROM_TIMESTAMP('...'). The new job replays that window with the corrected logic and then catches up to live data.
• “I changed the GROUP BY in a stateful aggregation.” Use FROM_BEGINNING to rebuild the aggregation correctly. (P.S. Stateful evolution is currently not supported — more on the challenges in a future post?)

To make the second one concrete, suppose you shipped price > 50.00 last week and the actual product threshold should have been price > 75.00. One statement gets you a corrected output:

CREATE OR ALTER MATERIALIZED TABLE high_value_orders (
  `order_id`    STRING,
  `customer_id` INT,
  `price`       DOUBLE,
  `product_id`  STRING
)
START_MODE = FROM_INTERVAL('7' DAY)
AS
SELECT order_id, customer_id, price, product_id
FROM examples.marketplace.orders
WHERE price > 75.00;

The new job rewinds seven days, reapplies the corrected filter across that window and then catches up to live data. Same output topic, no offsets to capture manually. One thing to keep in mind: the reprocessed records flow back into the same output topic, so downstream consumers will see them again. What that looks like depends on the changelog mode of the output:

• Append-only (like the example here): duplicates across the seven-day window. Consumers need to be able to dedupe, or you recreate on a fresh topic.
• Upsert: keys still present in the new result get overwritten correctly. But if the corrected logic filters out a key the old query was producing, no DELETE is emitted for it, and that record stays in the output indefinitely.
• Retract: the new job emits INSERTs for its result, but no compensating DELETEs for records that were in the old result and aren’t in the new one. Consumers see a mix of old and new until the data ages out.

Where Materialized Tables fit

Materialized Tables are now the recommended path for long-running streaming queries that persist data to a Kafka topic. Regular Flink statements aren’t going away. They’re still the right tool for exploratory queries, batch queries and short-lived work. But for the queries you’re going to run continuously and evolve as your requirements change, Materialized Tables are the way to go.

This changes a few things in the mental model:

• You manage one object, not a graveyard of statements. Each evolution is a version on the same table. Old statement runs are an implementation detail you can ignore unless you’re debugging.
• Your downstream consumers can stay the same. The output Kafka topic stays the same across evolutions. An operational service reading the topic and an analytical engine reading its Tableflow Iceberg materialization both keep working (with some caveats as explained later).
• It plugs into the rest of the platform without seams. First-class support is shipping across the UI (a new Materialized Tables tab and overview page with metrics, schema and evolution history), the Confluent CLI (confluent flink table), Terraform (confluent_flink_materialized_table) and the REST API. Define your derived dataset once and serve it to every consumer that needs it.

What you should know before going to production

This is a first GA. To solve the most pressing problem (query evolution) sooner, we made trade-offs. There are a few things worth knowing before you put a Materialized Table behind a critical pipeline:

1. In-place migration on upsert and retract topics has a downstream side effect to be aware of.

Because state is rebuilt rather than diffed, the new job has no memory of the keys the old job emitted. In an upsert-keyed table, if your new query filters out a key the old query was producing, no DELETE is emitted and the previous record stays in the output topic. The same issue, in different shapes, applies to retract and append-only modes (missing retractions, or duplicates over the reprocessed window). For most additive evolutions you won’t hit this. If your evolution removes keys from an upsert-keyed result, the cleanest workaround today is to recreate on a fresh output topic. We’re explicit about this trade-off in the docs and the state-carrying migration that removes it is something we’ll work on as a future addition.

2. CREATE OR ALTER is not idempotent yet.

Each invocation triggers an evolution, even if your SQL hasn’t changed. This is the part to be careful with in CI/CD. A terraform apply on every commit will trigger a real migration each time. The recommended pattern today is to gate the call behind a change check (a SHA, a git diff, a hash of the rendered DDL) and only run it when something has actually changed. True idempotency, where the system detects that nothing has changed and skips the evolution, is the next big unlock for safe GitOps and is high on our list.

3. Flink state is rebuilt on every ALTER, not migrated.

If your query is stateless (filters, projections, simple maps), this is invisible. If your query is stateful like aggregations, joins, or windows, the new job starts with empty state and rebuilds based on the START_MODE you choose. FROM_BEGINNING recomputes correctly but pays the reprocessing cost. FROM_NOW is cheap but produces aggregates that started counting at zero. There’s no third option in this release. In-place state migration is something we plan to add in a future release.

We’re actively working on the next round of improvements and there’s a lot more to come!

Give it a try

Materialized Tables are available now in Confluent Cloud for Apache Flink. To get started:

• Open the Flink workspace in Confluent Cloud, run a CREATE MATERIALIZED TABLE against the built-in examples.marketplace.orders source and watch it appear in the new Materialized Tables tab.
• Read the Materialized Tables conceptual docs and the Materialized Tables SQL reference.
• Manage them from the CLI with confluent flink table or from Terraform with the confluent_flink_materialized_table resource.

We’d love to hear what you build and what you want next. Drop me a message if you have any thoughts.

Request a beta invite now to give it a try!

We’ve had the privilege of working with a wide range of customers including global retailers, CRM vendors, sports franchises, creators, entertainers, and broadcasters — from HubSpot and SportsBet, to 17Live and InvitePeople — providing them with reliable, scalable and low-latency chat. Ably Pub/Sub is already a fantastic fit for a variety of chat use cases. But we’ve been doing a lot of thinking about how we can better help developers to overcome the many challenges of delivering chat features to market quickly, at scale and in an economically viable way.

That’s why we’re excited to kick off the private beta for our new chat product.

What is Ably Chat

Ably chat is designed to meet a wide range of chat use cases, such as livestreams, in-game communication, customer support, or social interactions in SaaS products. Built on Ably’s core service, it abstracts complex details to enable efficient chat architectures.

Ably Chat comes with purpose-built APIs for a host of chat features enabling you to create 1:1, 1:many, many:1 and many:many chat rooms for any scale; have users send and receive messages; and see the online status of the users in the room or the occupancy i.e. how many people are there in total. You can also build typing indicators, and room level reactions. We are actively working on other features like moderation and the ability to update and interact with chat messages.

Check out the documentation for a sneak peek of the functionality offered at this stage. If there are other chat features you’d like us to prioritize, please let us know.

What Ably Chat looks like

//Connect to a chat room with any number of participants
const room = chatClient.rooms.get('basketball-stream', { reactions: reactionsConfig });
await room.attach();

//Subscribe to chat messages
const {unsubscribe} = room.messages.subscribe(message) => {
  displayChatMessage(message);
}

//Subscribe to room reactions
const {unsubscribe} = room.reactions.subscribe((reaction) => {
  displayReactionAnimation(reaction);
});

//Send a chat message
await room.messages.send('That was such a cool shot!');
//Send a room reaction
await room.reactions.send({ type: 'like', metadata: { effect: 'fireworks' } });

Check out the live demo to play with it yourself!

Why Ably Chat

When Ably started in 2016, our goal was to make realtime interactions a key part of digital experiences. Now, we have a mature, battle tested WebSockets platform that gives us the freedom to focus on creating user-centric features that meet your needs in the best way possible. This approach unlocks many benefits for users of Ably Chat, and other products:

Composable realtime

A truly great realtime experience often involves combining multiple features together — chat, live updates, collaboration, notifications and more! Unlike chat-specific products or building your own solution from scratch, Ably offers the best of both worlds — full flexibility to build what you want, rapidly.

Whilst we will keep adding new features into our SDKs we know we’ll never be able to satisfy every unique use-case possible. That’s why we are also evolving our product suite to give you the flexibility to mix and match APIs and create what you need, exactly the way you want to, quickly and efficiently.

Dependable by design

We’ve built a realtime experience platform that ensures predictability of latencies. It is designed to preserve continuity of service at a regional and global level, ensuring capacity and availability. This allows you to maintain varying levels of scale seamlessly. Finally, data integrity comes baked in with message guarantees for ordering and exactly once delivery. This enables you to focus on your application and the user experience, with no infrastructure to build or manage.

Cost optimizations

A realtime platform needs to be able to support reliable chat at extreme scale, but must do so cost effectively. Typically, as chat usage (especially concurrent usage) increases, so does the cost per user. Cost optimizations and affordability of technology have been top of mind for us when designing the roadmap. With the upcoming batching and aggregation features you can maintain a low and stable cost per user. Additionally, Ably’s pricing model has been built for operations at scale with customisations such as hourly billing, usage based pricing and volume discounts.

All these abstractions and optimizations ultimately mean one thing — you spend less time figuring out the design patterns for good efficiency and a great user experience.

Get started with Ably Chat

Stay tuned for more updates and features as we roll out this new initiative. Sign up for the chat private beta to access new features early and collaborate on upcoming functionality to shape our roadmap. We’re just getting started, and there’s plenty more to come!

Say hello to Ably Chat: A new product optimized for large-scale chat interactions was originally published in Ably: Serious, serverless realtime infrastructure on Medium, where people are continuing the conversation by highlighting and responding to this story.

Spaces comes with a purpose-built SDK to enable developers to add a collaborative environment around existing applications.

We are very excited to announce a new product — Spaces!

The Spaces SDK comes with an intuitive set of APIs that allow you to build realtime collaboration features such as avatar stacks, live cursors, member location and component locking, in days. Each API is optimized for their specific use-case, reducing integration effort.

Spaces at a glance

• Feature specific APIs: The only product that comes with purpose-built, realtime collaboration APIs for adding avatar stacks, member location, live cursors, and component locking. All APIs are optimized for top performance. For example, the live cursors API automatically batches pointer position events to avoid unnecessary streaming of messages whilst ensuring negligible latency.
• Easy to use: Spaces is a simple and intuitive SDK that can be used with any web application.
• High performing: Powered by our market-proven, realtime infrastructure that’s built for reliability at scale, backed by five nines SLAs and messaging guarantees.
• Realtime experiences unlocked: Spaces is built to work with Ably’s other complementary products like Pub/Sub Channels to unlock end-to-end realtime messaging throughout your app. While Spaces powers the features you need to enable synchronous collaboration for teams and manage their participant state, Pub/Sub channels allows you to flexibly broadcast and sync app state changes between members, your backend and any other pieces in your system design.

Enhancing your product with in-app collaboration and Spaces

With the Spaces SDK you can set up a collaborative environment on any part of your application (or your entire application) so that collaborators have contextual awareness of what everyone is up to. Members of a space can see which other members are online, what they are looking at, their location within the app (this could be a cell, a page, a slide or a folder) and any specific component they’ve locked for editing. All of this and more in just a few lines of code. No need to change your existing system design or app architecture. No realtime infrastructure to build and maintain to scale the collaboration to millions of virtual spaces and users.

SDK feature highlights

Here’s the full set of APIs available in the beta release with many more planned:

• Space: A virtual collaborative space set up on your application where members can collaborate with each other in realtime.
• Members: Online users connected to the virtual collaborative space. This powers an avatar stack for end users which is a visual representation of a member’s presence — showing them as online and connected.
• Member location: The live location of a user within the app — page, cell, slide, block or anything else that makes sense for your application.
• Live cursor: The pointer location of members in a virtual space showing what they are looking at. The live cursor API automatically batches messages and provides the message rate required for smooth performance of 100s of simultaneous cursors (though we don’t recommend going beyond 15 for a good user experience).
• Component locking: Enables end-users to lock specific UI components while making their edits, so there’s no confusion with other collaborators or disruption to overall collaboration in the space.

Get started today

Spaces is currently available in beta. To get started simply

• Sign-up for a free developer account
• Take a closer look at Spaces
• Dive into the Spaces docs
• Watch our Spaces webinar and see the key takeaways

Introducing Spaces: Build collaborative environments in a few lines of code was originally published in Ably: Serious, serverless realtime infrastructure on Medium, where people are continuing the conversation by highlighting and responding to this story.

Check the full source code of the group chat app written in VueJS on GitHub and the live demo of the application at https://realtime-chat-storage.ably.dev/

What is Airtable?

Airtable describes itself as ‘Part spreadsheet, part database, and entirely flexible’ and that’s exactly what it is to the word. It caters to the engineering and commercial departments in an organization alike with its robust REST API and very nice visual UI with custom fields to manage and represent the data. It combines a bunch of different tools like task managers, databases, CRMs, spreadsheets, etc, into a single product.

Airtable REST API

Airtable comes with a simple REST API to perform the basic CRUD operations on the data stored. You’ll need to have a base i.e. a table/ sheet set up before you can check out the documentation. This is for a good reason — their whole documentation is dynamically displayed with real keys, ids, column names etc, along with sample responses, based on your data, making it super easy for you to just copy out the code and use it as is. They provide this documentation in cURL and JavaScript. The JS code snippets require using the Airtable JavaScript Client SDK. Here’s a look at the documentation for the chat app base.

How to use Airtable as a database

In this example, we’ll look at two operations — to store and retrieve data from Airtable. We’ll make use of WebHooks to send ‘Create records’ REST requests to the Airtable API each time a new chat message is published. We’ll then make use of ‘List records’ to retrieve previously stored messages upon user request. Here’s a subset of the database so you have an idea of the schema, or to simply put it, the column names in our database table/spreadsheet:

Each new message will have a unique (randomly created) msgId. This will be our primary key. The data is pre-ordered in ascending order by the ID column, which is an incremental number assigned to every new record automatically by Airtable.

Realtime updates with Ably and WebHooks

If you already use Ably, you can skip this section, if not, you can get started by creating an account. Ably provides a reliable realtime messaging infrastructure with high scalability. It primarily operates over WebSockets and provides Pub/Sub messaging infrastructure out of the box. It is protocol and platform agnostic in the sense that you can use it with WebSockets, MQTT or SSE, and with any language and platform that you are working with. You don’t have to spend time understanding the hard distributed systems problems it solves but simply start publishing and subscribing to realtime data with a mere couple of lines of code.

We’ll make use of Ably’s JavaScript Realtime SDK to power the chat app and the WebHook Integration feature to integrate Airtable directly with an Ably app.

In terms of flexibility, Airtable and Ably are a perfect match as you can use both these platforms in exactly the way that suits your custom use-case.

Ably’s Pub/Sub messaging is implemented using the concept of ‘channels’. Each Ably app can have any number of channels where each channel carries a group of information. For example, in a logistics app, you would have one channel for location updates of the fleet and another for job updates to inform any changes to delivery conditions etc. Depending on the data, you can set permissions as to who can publish or subscribe to the data on that channel by attaching to it. You can learn more about channels in the official documentation.

What are WebHooks?

In simple terms, webhooks are user-defined HTTP callbacks (or small code snippets linked to a web application) that get triggered when specific events take place on an external website or service. They’re especially useful when you’re building notification functions and event-driven responses in applications. You can learn more about WebHooks in the conceptual deep-dive article.

WebHooks are a great fit for our use case — sending a message to an Airtable base as a result of an event i.e. a new chat message published on a specific channel. If you go to the Reactor tab on the Ably app dashboard after logging in/ signing up, you should be able to create a ‘New Reactor Rule’ and select the Reactor Event > WebHook option. In a reactor rule, you essentially configure an HTTP endpoint along with the relevant headers, format, etc. You then select the source of the event trigger. There are a few options here — ‘Presence’, ‘Message’ and ‘Channel Lifecycle. All we need is a regular ‘Message’ in this case.

You’ll also see options to batch the requests or envelop them with Ably metadata. You can choose the batch option if you expect the request to be triggered at a high frequency. That’ll prevent you from hitting the rate limit on Airtable, which at the time of this writing is 30 requests/ sec. We won’t be enveloping the message with Ably metadata as Airtable expects the requests to be in a certain format exactly.

Bringing it all together in a group chat app built with VueJS

The group chat demo is written in VueJS. Here’s an illustration to better understand how all the components fit together:

In terms of the folder structure you see in the GitHub project, the following are the main files of interest to us in this article.

ably-airtable-storage
| __ src
| __ | __ App.vue
| ______ | __ components
| __________ | __ infobox
| __________ | __ chatbox
| ______________ | __ ChatCard.vue
| ______________ | __ UsernameInput.vue
| ______________ | __ ChatMessage.vue
| ______________ | __ ChatInput.vue
server.js

The ably-airtable-storage folder holds the VueJS app whereas the server.js file in the root serves the VueJS app and issues auth tokens to the front-end app to authenticate with Ably. (More on this later)

As you saw in the live demo, we also have an information box on the side that shows the play-by-play of behind the scenes as you use the app. You can make use of that to understand what exactly is happening in each step and use the code snippets to try it out yourself. The code for this is in the infobox folder under the components folder. We won't be discussing much the information box in this article.

Let’s take a look at what’s going on in the rest of the files.

1. server.js

This is a super simple Express server that serves the index.html page from the dist folder of the Vue app. The dist folder is generated when you run the build command after you are done working on the Vue app. You can learn more about this in VueJS docs.

You’ll notice that we also have an /auth endpoint. As mentioned before, this is to issue tokens so the Vue app can authenticate securely with Ably's realtime service. Ably offers two ways of authenticating - Basic Auth and Token Auth. Basic auth uses the API Key directly whereas token auth expects auth tokens or JWT, making it a more secure way of authenticating the front-end applications. You can learn more about each of these types and trade-offs in Ably's documentation and best practice guide.

The VueJS chat app

1.App.vue

This is the main parent component for the entire app. So, a good place to instantiate and manage the connection with Ably.

We instantiate Ably in the created() lifecycle hook of this component and disconnect in the destroyed() lifecycle hook:

created() {
    this.ablyRealtimeInstance = new Ably.Realtime({
      authUrl: "/auth",
    });
    this.ablyRealtimeInstance.connection.once("connected", () => {
      this.myClientId = this.ablyRealtimeInstance.auth.clientId;
      this.isAblyConnected = true;
      this.chatChannelInstance = this.ablyRealtimeInstance.channels.get(
        this.chatChannelId
      );
    });
  },
  destroyed() {
    this.ablyRealtimeInstance.connection.close();
  },

The authUrl object sent to the Ably.Realtime instance prompts Ably that we are looking to authenticate via token auth via the given URL to automatically renew tokens just before they expire.

After the connection status becomes connected, we get an instance of the channel to subscribe to later. If you remember from the previous step, we’d need to use the chat-airtable channel name for publishing and subscribing to the chat messages as that is the channel we are using to trigger messages sent to the Airtable database. If you notice, the full name we specify, however, is [?rewind=2m]chat-airtable. The channel name is preceded by some meta-information enclosed in the square brackets. The channel param used there is Rewind with a value set to 2 minutes. This allows you to get any previously published messages in the last 2 minutes before successfully establishing a connection to Ably and attaching them to the channel. You can learn more about all the available channel params from Ably's docs.

2. ChatCard.vue

This is the parent component for the Group chat app, so we subscribe to updates on the chat channel here:

created() {
    this.isReadyToChat = false;
    this.chatChannelInstance.subscribe((msg) => {
      this.handleNewMessage(msg);
    });
},

We subscribe to the chat channel and call a new method to handle the new message every time the callback is invoked. More on this shortly.

This component has three child components:

• UsernameInput.vue — accepts user’s name before they join the chat
• ChatInput.vue — accepts users’ chat message if they’d like to send one
• ChatMessage.vue — shows all chat messages in the group chat

The parent component has quite a few regular methods as well, here’s a break down of each:

i) The saveUsernameAndJoin() method

saveUsernameAndJoin(username) {
  this.clientUsername = username;
  this.isReadyToChat = true;
  this.chatChannelInstance.presence.enter(username);
  backgroundEventBus.$emit("updateBackgroundEventStatus", "join-chat");
}

This method is invoked from the UsernameInput.vue component and saves the username entered by the user. Ably's Presence feature allows you to see the realtime connection status of any client. This is useful to see which users are currently online. We make this user enter the presence set with their username in this method. The backgroundEventBus is a VueJS state management mechanism to emit various events to the infobox component.

ii) The handleNewMessage() method:

async handleNewMessage(msg) {
  let messageContent = msg.data.records[0].fields;
  let msgTimestamp = msg.timestamp;
  await this.chatMsgsArray.push({
    messageContent,
    msgTimestamp,
    msgType: "live",
  });
  if (this.$refs.chatMsgsBox) {
    let divScrollHeight = this.$refs.chatMsgsBox.scrollHeight;
    this.$refs.chatMsgsBox.scrollTop = divScrollHeight;
  }
  if (messageContent.clientId != this.myClientId && this.isReadyToChat) {
    backgroundEventBus.$emit(
      "updateBackgroundEventStatus",
      "live-msgs-loaded"
    );
  }
}

Continuing from the channel subscription, this method is called for every new message pushed on chat the channel. We extract the required fields from the message and push them into the chatMsgsArray which is used to display messages in the chat screen. This is a live msg (vs one that is retrieved from a database).

iii) The loadPreviousMsgs() method:

loadPreviousMsgs() {
  if (this.chatMsgsArray[0]) {
    this.getMsgsFromDBWithMsgID();
  } else {
    this.getLatestMsgsFromDB();
  }
}

This method is called when the ‘load previous messages’ popup is clicked. It checks if there is a previous message present in the chat array or not. Accordingly, calls other methods to retrieve messages from the database.

iv) The getMsgsFromDBWithMsgID method:

getMsgsFromDBWithMsgID() {
  this.latestMsgId = this.chatMsgsArray[0].messageContent.msgId;
  this.showLoadMoreBtn = false;
  setTimeout(() => {
    this.showLoadMoreBtn = true;
  }, 500);
  this.base = new Airtable({
    apiKey: configVars.AIRTABLE_API_KEY,
  }).base(configVars.AIRTABLE_BASE_ID);
  let vueContext = this;

  this.base("Table 1")
    .select({
      view: "Grid view",
      filterByFormula: "SEARCH('" + vueContext.latestMsgId + "',{msgId})",
    })
    .eachPage(function page(records, fetchNextPage) {
      const latestRecordID = records[0].fields.ID;
      vueContext.dbAutoNumber = latestRecordID;
      if (latestRecordID) {
        vueContext.getMsgsFromDBWithAutoID();
      } else {
        fetchNextPage();
      }
    });
}

This method is invoked when there’s a previous message present in the array. Note that all the records in the database are pre-ordered chronologically with an auto-incrementing ID field. We use msgId of the earliest message to find that record's ID in the Airtable database, then send another request to retrieve three records with an ID less than the previously retrieved record's ID. This is done in the getMsgsFromDbWithAutoID() method added next:

getMsgsFromDBWithAutoID() {
  let vueContext = this;
  this.base("Table 1")
    .select({
      maxRecords: 3,
      view: "Grid view",
      filterByFormula: "({ID}<" + vueContext.dbAutoNumber + ")",
      sort: [{ field: "ID", direction: "desc" }],
    })
    .eachPage(
      function page(records, fetchNextPage) {
        records.forEach(async function(record) {
          await vueContext.chatMsgsArray.unshift({
            messageContent: record.fields,
            msgTimestamp: 123,
            msgType: "db",
          });
          backgroundEventBus.$emit(
            "updateBackgroundEventStatus",
            "db-msgs-loaded"
          );
          if (vueContext.$refs.chatMsgsBox) {
            vueContext.$refs.chatMsgsBox.scrollTop = 0;
          }
        });
        fetchNextPage();
      },
      function done(err) {
        if (err) {
          console.error(err);
          return;
        }
      }
    );
}

We add each of the retrieved records at the front of the chatsMsgsArray so they appear at the top of the chat list in the UI as the messages are ordered chronologically.

v) The getLatestMsgsFromDB() method:

getLatestMsgsFromDB() {
  this.base = new Airtable({
    apiKey: configVars.AIRTABLE_API_KEY,
  }).base(configVars.AIRTABLE_BASE_ID);
  let vueContext = this;
  this.base("Table 1")
    .select({
      maxRecords: 3,
      view: "Grid view",
      sort: [{ field: "ID", direction: "desc" }],
    })
    .eachPage(
      function page(records, fetchNextPage) {
        records.forEach(async function(record) {
          await vueContext.chatMsgsArray.unshift({
            messageContent: record.fields,
            msgTimestamp: 123,
            msgType: "db",
          });
          backgroundEventBus.$emit(
            "updateBackgroundEventStatus",
            "db-msgs-loaded"
          );
          if (vueContext.$refs.chatMsgsBox) {
            vueContext.$refs.chatMsgsBox.scrollTop = 0;
          }
        });
        fetchNextPage();
      },
      function done(err) {
        if (err) {
          console.error(err);
          return;
        }
      }
    );
}

This method is invoked if there were no messages in the chatMsgsArray, meaning there was no earliest record to reference. We simply need the last three messages available in the database. The previous option can be combined with this as the filterByFormula field is the only differentiator, but it's added in two separate methods to make the two cases evidently clear.

3. ChatInput.vue

As mentioned before, this method manages the input box to add a new chat message. It has a single method that is invoked when the send button is clicked:

publishMessage() {
  if (this.myMessageContent != "") {
    const uniqueMsgId =
      "id-" +
      Math.random()
        .toString(36)
        .substr(2, 16);

    this.msgPayload = [
      {
        fields: {
          clientId: this.myClientId,
          msgId: uniqueMsgId,
          username: this.clientUsername,
          "chat-message": this.myMessageContent,
        },
      },
    ];

    this.chatChannelInstance.publish("chat-msg", {
      records: this.msgPayload,
    });
    backgroundEventBus.$emit("updateBackgroundEventStatus", "publish-msg");
    this.myMessageContent = "";
  }
}

In this method, we compute a random (unique) id to assign to the message and publish it on the chat channel with the message copy and other information like the clientId and username. As the echoMessages Ably client option is turned off by default, the same client also receives this message as a subscription update on the channel, leading to that message being added to the array and ultimately appearing in the UI.

As the UsernameInput.vueand ChatMessage.vue components are pretty much self-explanatory with minor data transformation and display, we'll skip explanations on those.

With that, we’ve closed the full loop of data transfer from publisher to subscriber to the database and back to the subscriber. Here’s the link again to the live demo so you can check it out again and piece the above information together: https://realtime-chat-storage.ably.dev/

Exploring other ways to get data from Airtable into Ably

You might say it’s all working fine, why explore other ways? While we can publish messages directly into Airtable and retrieve those message again from the front-end app, we have a few gaps in this project stopping it from being production-ready.

What if for whatever reason, someone adds a message in Airtable? We won’t be able to show those new messages in the chat app until the whole thing is refreshed and refreshing is not fun and a no-go when dealing with realtime data. While Airtable is not a realtime database i.e. it doesn’t push any changes out, we have a work-around to this problem. Enter, Zapier!

Using Zapier and Ably to convert Airtable into a realtime database (well, kind of)

Zapier is a workflow management application that connects two or more SaaS platforms to share event-driven data. We can connect Airtable and Ably on Zapier and have it publish a message to a given Ably channel when a new record is added in the Airtable database. It would like something like this:

You can decide if you want these updates published on the same chat channel or a different one and manage those updates accordingly. A quick note here is that you can publish different events on the same Ably channel to differentiate different types of updates. You can learn more about event name object in the publish method in Ably docs.

Replacing REST requests with GraphQL

If you followed through with the explanation for the chat app, you know that if we want to retrieve messages from a given point in the database, we’ll need to send two subsequent requests to get the actual required data. Don’t worry if you skipped through that entire section, I understand it was long :) You can just look for the phrase getMsgsFromDBWithMsgID and you'll land in the right section that I'm referring to here.

We can optimize that process by replacing the REST requests with the popular kid on the block — GraphQL! While it’s not supported officially by Airtable, Thomas Cullen built a GraphQL plugin for Airtable as a community contributed project and it’s perfect for this scenario. You can check it out on NPM.

Summing it up…

Airtable and Ably are great services with just the right level of flexibility in terms of usage. We saw how to publish and subscribe to realtime messages using Ably and automatically have those messages stored in Airtable in realtime using the WebHooks Integrations feature.

We also saw how to retrieve just the required messages from Airtable and display them for the user. We further explored other options of retrieving and publishing data to Airtable.

Live demo: https://realtime-chat-storage.ably.dev/

GitHub project: https://github.com/ably-labs/ably-airtable-starter-kit

Hope this post was useful. If you are building something with Airtable and Ably, I’d love to see your project and give it a shoutout. And of course happy to help you with any questions or concerns. You can raise them at devrel@ably.com or DM me on Twitter.

Hello developers!

TL;DR

I built a realtime quiz framework so developers building EdTech apps can quickly get started with scalable realtime messaging and focus on their app logic. It is a fully customizable framework built with NodeJS, VueJS, and powered by Ably’s realtime infrastructure which primarily operates on WebSockets.

It also implements Node JS worker threads to simulate multiple ‘quiz rooms’ (aka dedicated servers spooled up on-demand) so different groups of people can simultaneously participate in different live quizzes organized by their dedicated hosts. You can check out framework on GitHub at https://github.com/Srushtika/realtime-quiz-framework or try out the live demo at https://quiz.ably.dev/

What is EdTech?

One of the positive outcomes of this new world we are living in is the rise of EdTech. Educational technology (EdTech) is the combined use of computer hardware, software, and educational theory and practice to facilitate learning. The origins of EdTech can be traced back to the late ’90s and it has grown slowly but steady year after year, but it all changed in 2020 as 1.57 billion learners in 190 countries moved from classrooms to interactive, digital environments during Covid-19. This has accelerated EdTech existing growth, driving transformation that’s here to stay.

This incredible growth didn’t come without new demands and requirements of innovation, and, a stepping stone to innovation is realtime communication: between students and teachers for synchronous learning, and between devices and the cloud for safety, security, and cheating prevention.

How a realtime quiz framework can help EdTech apps

Most of the EdTech tools and platforms have live collaboration features. If you think about it, most of the collaborative realtime apps follow a common pattern and feature set, with customizations for their specific scenario.

For a live quiz, which can double up as a test-taking app for a class of high schoolers, or simply a movie trivia for a fun virtual Pub Quiz Friday with your workmates, there are a lot of common patterns without even needing much customization.

For example, they need to be able to create their own private quiz room and invite other people to that room. In most cases, one of the participants needs to have special admin controls (mostly the host). They need to be able to easily control the progression of the quiz. And so on…

Keeping in mind these commonalities and to avoid the need for developers working on EdTech platforms to build everything from scratch, I built an open-sourced realtime quiz framework to quickly get a working quiz/ test-taking platform up and running in no time. Developers can easily customize this extensible framework as per their specific use-cases and scenarios.

If you want to skip the details and take a look at the live demo, check it out at https://quiz.ably.dev/

Some background before I jump into the details

In the last few months, I worked on a few browser games and realized there were common patterns in all these realtime games that needed continuous high-speed streaming of data between the players and the game server.

The architecture was similar but the type of input from the players, and the game logic on the server changed according to the game in question. So I put all these observations together and built an arbitrarily scaling networking framework to build realtime multiplayer games. This proved to be useful to a bunch of people to set up realtime networking in no time and focus on customizing it per the game logic.

As I moved on from games, I did some research to see ‘what’s hot’ currently and, as depressing are a lot of events around the world this year, a super positive and refreshing trend has been an increase in virtual live collaboration. This led me to think about e-learning in terms of various institutions conducting their classes and tests online. So I played around with a bunch of such EdTech platforms, and again, observed a lot of common patterns everywhere. I put these observations together to build this extensible realtime quiz framework. I hope this is a useful starting point if you are wanting to build an EdTech tool of any kind.

So, what’s this framework all about?

The realtime quiz framework is a fully open-sourced full-stack project built with Node JS and Vue JS and the architecture consists of the Websockets protocol and the Publish/Subscribe messaging pattern. It’s a working app with the basic functionality required to build a realtime quiz app.

To be honest, calling it a quiz app is a bit generic as the architecture would be the same for a test-taking app for an institution, an HQ style live trivia app, or a more one to one quiz like Quiz Up. As the framework is using Ably’s Realtime infrastructure for realtime messaging between various components, it is readily scalable to an enterprise level.

The framework shows two ways of conducting a quiz.

You can have the questions stored in your server or have the end-users easily upload their own questions by sharing a link to their Google Sheet. You can easily extend this to attach a database for a more persisted data storage and allow a greater range of already available quizzes to select from.

The idea is that the host of the quiz and other players are already on a video call (on another platform). The host shares their screen invites other players to their quiz using a shareable link, and manages the progression of the quiz throughout. They’ll be able to see the players with dummy avatars but real nicknames show up in a list as they join.

When the host feels that the expected players have joined, they can start the quiz. After a short timeout, the questions start showing up. The players can see the question, an image if available, and four options. The four options are buttons and the players can choose one of them to register their answer for that question. The interface is a bit different for the host in that they’ll also see the question, optional image and four options but these are not clickable as the host is essentially not participating in the quiz themselves.

In addition to this, the host also sees a live stats panel that shows the number of players online and out of those the number of players who’ve already answered that question. You can easily extend this to show the names and avatars of those players or any other live stats like the high score etc.

Each question shows up for 30 seconds but if all the players have answered the question, the rest of the timer is skipped. One interesting thing to note about the timer is that every second update in the timer is a result of the data coming in from the server-side. This not only ensures that end-users have no way to tweak the timers and such in the client-side app, but also that all the participants in the quiz along with the host are fully in-sync. After a question’s time has elapsed, the leaderboard info so far can be seen on the host app. The host then has an option to show the next question or end the quiz midway through. If you think of a pub quiz scenario where after each question, you have a random banter about how people thought their answers were correct, this gives the proper control to the host to allow time for that banter and show the next question only when everyone is ready.

In terms of the answer after each question, the host can see on their screen the correct answer to the previously displayed question. The players, in addition to being able to see the correct answer, will be prompted if the answer they chose was correct or wrong.

After all the questions in the chosen quiz have finished playing, a final leaderboard containing the scores of all the participants will be displayed on the host app.

As this is a base framework, each component can be easily customized! The framework is available on GitHub along with a detailed README.md on getting it working and customizing it. It also has a TUTORIAL.md if you’d like to understand in much more detail what’s happening in every method of the app.

The live demo is also available at https://quiz.ably.dev/

I hope this framework is useful for your realtime EdTech adventures or anything else and I can’t wait to see what you build with it! Please feel free to share it with me and Ably on Twitter and we’ll be happy to give it a shoutout.

If you have any questions, feel free to DM me on Twitter or reach out to the support team at Ably.

Stay home, stay safe, and have fun virtually!

—

Header image illustration credits: School vector created by pch.vector — www.freepik.com

A Scalable, Realtime Quiz Framework to Build EdTech Apps was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello game developers!

TL;DR — I built a realtime communication framework so game developers can build multiplayer games without needing to worry about the networking side of it and instead focus on their game logic. It is powered by Ably’s realtime infrastructure which primarily operates on WebSockets and is built in Node JS and Vanilla JS (use it with any JS framework you like 😉). It also implements Node JS worker threads to simulate multiple ‘game rooms’ so different groups of players can simultaneously play the game. You should check it out: https://github.com/Srushtika/multiplayer-games-scalable-networking-framework

A few months back I got into the world of building high-frequency (realtime) multiplayer games to get my boss’s attention as he’s extremely passionate about game development (Challenge: Try to have a tech conversation with Ben Gamble, without game dev coming up!🌚🕹).

When I started, I had so many misconceptions about game dev. I underestimated certain aspects and had misconceptions about scalable game architectures. But I’ve learned so much about game dev since then and have built multiplayer versions of a few classics such as Multiplayer Space Invaders and Multiplayer Flappy birds. I’ve also written and spoken about game dev quite extensively on various platforms.

For each such presentation, I made improvements to the games by not only making them more efficient but also having them use the best and latest features of the underlying programming language. For example, I used Node JS worker threads (which was released as a stable version in January 2020) to simulate the idea of having multiple game rooms so different groups of people can play the game simultaneously. Ably’s namepace feature made this strategy possible by ensuring none of the rooms had any access to the data from the other.

More games = repeating boilerplate? 🤯🥵

While I was continuing to think of more multiplayer game ideas that were cool enough to convince my team to let me work on them during Ably working hours 🌚, I realized some commonalities in all these projects:

All of my multiplayer games so far follow the Client/Server game strategy. Hence, basic networking architecture is exactly the same and has the following aspects:

• The server maintains the game state and publishes it at high frequency to a channel that all the players are subscribed to. This ensures all players are in-sync.
• Each player sends their current state (based on user input, etc) on a unique channel meant for that client. The server is subscribed to this and uses this info to maintain the up to date game state mentioned above.
• The game has multiple game rooms.
• The host player has options to start and end the game.
• In general, there’s awareness of every player’s score, position, alive/dead status, join/ leave updates for the game, etc.

Come to think about it, it seems that this is pretty much what most realtime multiplayer games would need. So, I thought building a networking framework would benefit game developers to quickly add multiplayer functionality to any game. All the more useful when it’s built with Ably, as it means you can easily scale it and have access to so many other realtime communication features (like message ordering, availability, guaranteed message delivery, etc) So, here it is!

Multiplayer games scalable networking framework

This framework server as a starter kit that allows you to add multiplayer functionality (that follows the Client/Server strategy) to your game. It provides a communication framework so that your players can communicate with a central server, in realtime, for the entire duration of the gameplay.

It also allows you to implement a ‘game rooms’ feature using Node JS worker threads, allowing you to spin up multiple instances of the game, each with a separate group of players. It comes with a skeleton demo app where this game functionality can be simulated. The idea is for game developers to take this framework and add their game logic to make it their own!

You can find the full project with a detailed guide on how to use it on GitHub: https://github.com/Srushtika/multiplayer-games-scalable-networking-framework

If you have any questions/ suggestions, etc. Feel free to shoot an email to devrel@ably.com or reach out to me directly on Twitter, I’ll be so glad to talk about this 😃 Don’t forget to share any multiplayer games you build with this, I’d love to check them out and give a shoutout! 🥇🚀🔥

Hello, and welcome to the final part of this article series where we are looking at the step-by-step implementation of a realtime multiplayer game of space invaders with Phaser3 and Ably Realtime. 🚀

Here’s the full index of all the articles in this series for context:

• Part 1: Introduction to gaming concepts and the Phaser library
• Part 2: Evaluating networking protocols for realtime apps
• Part 3: Implementing the server-side code to keep all players in sync
• Part 4: Finishing up the client-side code to render the game

In this article, we’ll finish up the client-side code to render the game and also add the home and leaderboard screens for our game.

If you recall, in the first article we added the GameScene class and defined the preload() method in it. We also added the create() and update() methods but didn't define them fully.

Let’s start by adding some variables that we’ll use later. Add these at the top of script.js (which should be inside the public folder:

Make sure to update the BASE_SERVER_URL with your server's URL. If you have hosted the game locally, this URL would be your localhost with the port number.

Next, we’ll have the client connect to Ably and subscribe to the channels. Add the following code, right below the variable declarations in script.js

One of the key things to note here is the gameRoom.presence.enter(myNickname); method. Ably uses a concept called Presence to determine connected clients in an app. It fires an event whenever a new client joins, or when an existing client leaves or updates their data.

Notice that this is where we instantiate a new game object with the GameScene that we started defining in the first part. So, let's resume that. The create() method of the class should now look as follows:

We had already defined the this.anims.create()method in the first article. Just above that, we add and initialize a few variables. We then subscribe to the game-state and game-over events on the gameRoom channels.

When we get a game-state update, we update the client-side variables as per the latest info from the server.

When we get a game-over update, we store the leaderboard info in local storage. We then unsubscribe the client from all channels and simply switch to a new webpage because either someone won or all players became dead.

Let’s look at the update() method next:

In the update method, we move the existing game objects in accordance with the latest info. We also create new avatars for the newly joined players and kill avatars of any player that has died by calling the explodeAndKill() method. We also update the score, and flash the join and leave updates in the <p> elements outside the game canvas.

If the server says a player just died, we call the explodeAndKill() method that will perform the explode animation and destroy that player's avatar.

A bullet gets fired once for every five-game ticks. So the server either sends a blank or a bullet object, with a unique ID and a position that matches the ship’s y-axis level. If it hasn’t already been shot, its toLaunch flag will be true. So we check that and create a new bullet by calling the createBullet() method. Otherwise, we'll move to an existing one.

We also check if the player has pressed the left or right keys via the publishMyInput() method.

Let’s define these methods next. Please note that these methods are part of the GameScene class.

In the createBullet() method, we add a new bullet object according to the latest position of the ship and add this bullet to the visibleBullets associative array that's part of the GameScene class. We also add an overlap method for the current player's avatar and every bullet we add. This method will keep track of the overlap of the two-game objects overlapping. When that occurs, Phaser will invoke a callback method, which in this case is publishMyDeathNews(). We'll define that later.

In the publishMyInput() method, we check if the left or right key was pressed and if yes, publish that info to Ably. It's worth noting here that we never move the avatars directly as a result of user input. We publish this info to the server, which in turn fans it out to all the players, including the current player, resulting in a perfect state synchronisation. This communication happens so fast that it doesn't really feel any different to the user playing the game.

In the explodeAndKill() method, we create a new instance of the Explosion class. We haven't defined that yet, so let's take a brief detour from the script.js file that we've been working on, to add it. Create a new file in the public folder, call it explosion.js and paste the following code in it.

This class extends Phaser.GameObjects.Sprite and plays the explode animation that we defined in the create() method of our GameScene class in the script.js file.

Now let’s get back to script.js and define one last method within the GameScene class, the publishMyDeathNews():

This method is invoked when a bullet object overlaps with the current player’s avatar, meaning the player has been shot. When that happens, we simply publish this information to the server so it can update the game state accordingly and fan this information out to all the clients, including the current player, so they can update their respective game states accordingly.

We are all done with the game implementation. We just have to add the home and leaderboard pages to make the game more complete.

Adding the home and leaderboard pages

In the views folder, add four files:

• gameRoomFull.html

• intro.html

• winner.html

• gameover.html

In the public folder, add three files:

• nickname.js

• winner.js

• gameover.js

The gameRoomFull.html is displayed when anyone tries to join the game after the preset maximum number of players have already joined.

The intro.html file gives the user a simple text box to enter their nickname. This info is used to flash join/leave updates and also show the info in the leaderboard.

The winner.html page is shown if the game ends due to a player winning the game. This page will then display their nickname as the winner and also show the first and second runners up.

The gameover.html page is shown if all the players in the game die. This page just shows the nicknames of the top two scorers.

The related JavaScript files simply retrieve the info from the local storage and set it in the relevant HTML elements.

That’s it, we’ve now full implemented the game 🙌🏽🙌🏽🙌🏽

Let’s go ahead and run it. We first need to run the server, so from your command line, navigate to the folder where the server file is and run node server.js. This will start the server. Now, open three browser windows and keep them side-by-side. Hit the base URL of your server from all three windows. You should see the intro.html page being served to ask for a nickname. Give each player a nickname and enter. After the third player enters, the ship starts with the bullets going off. Make sure to control each player to avoid getting killed.

If it’s running as expected, you can host this game using a free hosting service such as Heroku or Glitch. This will allow you to access the game via a public URL letting you play the game for real with your friends on other computers.

A separate release relevant to this tutorial is available on GitHub if you’d like to check it out.

You can also follow the Github project for latest developments on this project.

As always, if you have any questions, please feel free to reach out to me on Twitter @Srushtika. My DMs are open :)

Building a realtime multiplayer browser game in less than a day — Part 4/4 was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello, it’s me again 👋🏽

Welcome to Part 3 of this article series where we are looking at the step by step implementation of a realtime multiplayer game of Space Invaders with Phaser3 and Ably Realtime.

In the previous article, we learned all about networking for realtime multiplayer games and also the Pub/Sub messaging pattern. We then saw the design and channel layout for our game.

Here’s the full index of all the articles in this series for context:

• Part 1: Introduction to gaming concepts and the Phaser library
• Part 2: Evaluating networking protocols for realtime apps
• Part 3: Implementing the server-side code to keep all players in sync
• Part 4: Finishing up the client-side code to render the game

In this article, we’ll start writing the server-side code to implement Pub/Sub in our application by following the client-server strategy to maintain synchronization between all the players.

Before we get started, you will need an Ably API key to authenticate with Ably. If you are not already signed up, you should sign up now for a free Ably account. Once you have an Ably account:

1. Log into your app dashboard
2. Under “Your apps”, click on the app you wish to use for this tutorial or create a new one with the “Create New App” button
3. Click on the “API Keys” tab
4. Copy the secret “API Key” value from your root key and store it so that you can use it later in this tutorial

Until now, we worked on the index.html and script.js files. Let's go ahead and create a new file and call it server.js. This is where we'll write our server-side code in NodeJS.

Our game server is responsible for three main things:

• Authenticate clients and assign to them a random and unique client ID so they can use the Ably Realtime service via the Token Auth strategy.
• Serve as a single source of game-state truth and constantly publish the latest state to all the players
• Manage and update the velocity and thus determine the position of the ship using a separate server-side Physics engine.

Let’s get into each of these.

Using the p2 Physics library via NPM

If you remember, we discussed in the first article that Phaser comes with its own physics engine, which is why we didn’t have to use another third-party library to implement physics on the client-side. However, if the server needs to be able to update the velocity of the ship and compute it’s position at any given time accordingly, then we’d need a physics engine on the server-side as well. As Phaser is a graphics rendering library and not a standalone physics engine, it’s not ideal to be used on the server-side. We’ll instead use another server-side physics engine called p2.js.

Let’s start writing some server-side code by requiring a few NPM libraries and declaring some variables that we’ll use later:

Which libraries did we require and why?

• The Express NPM library lets our server listen and respond to requests from clients.
• The Ably NPM library allows the server to use Ably’s Realtime messaging architecture to communicate in realtime with all the players using the Pub/Sub messaging architecture, over WebSockets in this case.
• The p2 NPM library allows us to compute physics for ship velocity and position

Next, we need to authenticate the server with Ably and also instantiate the Express server so it can start listening to various endpoints:

As you can see, we’ve used Ably’s Realtime library, passed an API Key to it, and set the echoMessages client option to false. This stops the server from being able to receive its own messages. You can explore the full list of Ably client options on the docs page. Please note that the ABLY_API_KEY variable is coming from the secret .env file, so make sure to create a free account with Ably to get your own API key to use here.

In the auth endpoint, we’ve assigned the client a randomly created unique ID and sent back an Ably signed token in the response. Any client(player) can then use that token to authenticate with Ably.

As a side note, Ably offers two auth strategies: Basic and Token auth. In short, Basic auth requires using the API key directly, whereas Token auth requires using a token provided by an auth server (like we implemented above).

The token expires after a certain period, and thus it needs to be updated at a regular interval. The token auth strategy offers the highest level of security, whereas the basic auth strategy exposes the API Key directly in the client-side code, making it prone to compromise. This is why we recommend token auth for any production level app.

In our code above, we also keep a track of the number of players trying to access the game using the peopleAccessingTheWebsite variable. Anyone who goes over the limit gets shown a separate page instead of adding them to the game. Ideally, we'd implement game rooms where multiple games could be played simultaneously, but that's something for the future commits to the project.

Other than handling client requests and sending different HTML pages in the responses, the server also needs to handle the game state and listen to user input and update all the context accordingly. Once the connection with Ably is established, we’ll attach to the channels and subscribe to some events:

If you remember from the last chapter, we have two main channels in our game, the gameRoom channel for updates related to the game context and players entering/leaving, and the deadPlayerCh channel for updates related to any player's death.

On the gameRoom channel, we'll listen to the enter and leave events as these will be triggered when any client joins or leaves the game via a feature called presence. We'll learn more about this when we look at the client-side code.

Let’s flesh each of these functions out next to understand what’s happening:

• gameRoom.presence.subscribe("enter", (msg) => {});

Let’s figure out what’s happening in the above method. When a new player joins, we update the alivePlayers and totalPlayers variables. If it's the first person to join, we start the game ticker, which publishes an update on the gameRoom channel every 100ms (we'll add this game tick implementation later).

Subsequently, we create a unique channel for each client using their clientId, so they can publish their button click inputs.

Next, we create an object for this new player, with all requisite attributes:

• ID
• x and y positions
• avatar type and colour
• score
• nickname
• a flag to see if the player is alive or not

We then add this object to the global associative array called players with a key that's the same as the clientId of this player.

We also need to check if the max number of players has filled. If yes, we call a method to start the ship and the bullet and move the players downwards. We’ll implement these methods later.

Finally, we call a method to subscribe to the unique channel we just created for this player. This allows the server to listen to keypresses from the client and update the game state accordingly.

• gameRoom.presence.subscribe("leave", (msg) => {});

Before we get into the explanation, a quick thing to note is that the leave event is invoked when a player gets disconnected from the internet or closes the game window. If that happens, we update the alivePlayers and totalPlayers variables and then delete that player's entry from the global associative array players. If it's the last player that has left, we call a method to reset the server context allowing a new round of the game to be played.

• deadPlayerCh.subscribe("dead-notif", (msg) => {});

In the client-side code, the event dead-notif would be published on this channel when a bullet hits a player's avatar, declaring the player dead.

When the server receives this event, we set the player’s isAlive to false. We won't delete the player's entry from the players global associative array because even though they're dead, this player is still part of the game and we'll need their info for the leaderboard at the end of the game.

The server needs to share this information with all the players in the next game tick, so we save the ID of the bullet that killed this player. In the client-side code, this information is relevant to be able to destroy the killer bullet and the avatar of the player that was killed.

Those are pretty much the subscriptions we have inside the realtime.connection.once("connected", () => {}); callback. Let's next declare all the other functions we need inserver.js to get a nice overview. We'll define each of these and understand their part in the game.

Let’s define these one by one.

• startGameDataTicker():

This is the most critical method in the whole game as it is responsible to publish updates at a preset frequency (in this case 100ms set by GAME_TICKER_MS). All the clients will then use these updates to update their respective game state as per these updates.

In every tick, we publish, among other things, the latest info from the players associative array that holds all the players' info and the ship's position and velocity as per the physics world (which we'll implement shortly).

• subscribeToPlayerInput():

Using this method we subscribe to the pos event on the particular client's unique channel. Note that this method is called for every client with their unique channel name). When the callback is invoked, we check to see if it was a left or right arrow click from the client and change their avatar's position info accordingly. We also add a check to make sure they are not going out of bounds of the canvas.

• startDownwardMovement()

This will be called when the game starts, i.e. when all the expected number of players have joined

As seen in the gameplay gif in the first article, all the players automatically move downward at a regular interval. The above function in the server does that update in the y position for each avatar. We loop through each player in the players array and update their avatar's y position if they are still alive. We also check each time whether they've reached the x-axis along which the ship is moving. If yes, it means they've won, so we'll call another function to finish the game for all players and show the leaderboard page.

Let’s define that method next.

• finishGame(playerId):

The above method will be called either when a player has won the game or when all the players in the game have died.

We basically put all the leftover players in a new array with their score and nickname, sort them in descending order by score and declare a winner, runner up and second runner up (if the game has three players or more). We then publish this info on the gameRoom channel so all the clients can switch to the leaderboard screen and display this info.

In the end, we call the resetServerState() method which would reset all the counters on the server making it ready to host a new round.

• resetServerState():

We reset all the counters and flags to their initial state. We also detach from all the player channels since we no longer need them.

• startShipAndBullets():

This method is called when the required number of players have joined the game, meaning we are ready to start the game.

We start by setting the gameOn flag to true. As mentioned before, we'll use the p2 Physics engine on the server-side to manage the movement of the ship. p2 needs a World instance to be created. We can set the frequency at which this world moves forward, moving its constituent objects along with it at that speed.

We then create a new Body instance for the ship, assign it the initial x/y positions and horizontal/vertical velocities. We add this ship body to the previously created world and call a method to start moving this world. This is when we'd like to start moving the players downwards, so we call that method here.

• startMovingPhysicsWorld():

We start an interval and move the world with the speed of our choice. We basically update the shipBody variable's x/y positions and velocity according to what it is in the physics world at that time. Think of it as the engine moving the ship body with a certain speed towards the right. So if you'd like to know where the ship will be after, say, 2 seconds, the p2 world will tell you exactly that. We can use this info to update the variables that are sent as part of the next game tick update.

• calcRandomVelocity():

• randomAvatarSelector():

The calcRandomVelocity() calculates a random velocity that could be either negative (left) or positive (right). The randomAvatarSelector() simply returns a random number between 1 and 3, so each player can get assigned a random avatar type and colour out of the three we have available.

That’s it on the server-side. In the next chapter, we’ll get back to the script.js file and finish up the game logic.

All articles in this series are:

• Part 1: Introduction to gaming concepts and the Phaser library
• Part 2: Evaluating networking protocols for realtime apps
• Part 3: Implementing the server-side code to keep all players in sync
• Part 4: Finishing up the client-side code to render the game

A separate release relevant to this tutorial is available on GitHub if you’d like to check it out.

You can also follow the Github project for latest developments on this project.

As usual, if you have any questions, please feel free to reach out to me on Twitter @Srushtika. My DMs are open :)

Building a realtime multiplayer browser game in less than a day — Part 3/4 was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hey again 👋🏽

Welcome to Part 2 of this article series where we are looking at the step by step implementation of a realtime multiplayer game of space invaders with Phaser3 and Ably Realtime.

Here’s the full index of all the articles in this series for context:

• Part 1: Introduction to gaming concepts and the Phaser library
• Part 2: Evaluating networking protocols for realtime apps
• Part 3: Implementing the server-side code to keep all players in sync
• Part 4: Finishing up the client-side code to render the game

In the first part of this series, we learned about the basics of gaming and the Phaser 3 library. In this article, we’ll gain an understanding of various networking protocols, architectures and system design to build multiplayer games.

Architecture and system design

Networking can be tricky for multiplayer games if not done right. All the players need to have the ability to communicate at all times and they all need to have a state that’s always synchronized.

There are a couple of strategies to go about this:

1) Peer-to-peer (P2P): As the name suggests, each player(client) in this strategy directly communicates with every other player. For games with a small number of players, this might be a good strategy to get up and running quickly.

However, this approach has two immediate downsides:

1a) If a client is responsible for deciding what happens to them in the game, they can end up cheating by hacking something on the client-side. Even if they are not exactly cheating, they could be claiming something that may not be true for someone else just because of network lag

1b) In the P2P strategy, every player is connected to every other player and communicates in that way too, leading to an n-squared complexity. This means, our game wouldn’t scale linearly for when hundreds of players start playing the game online.

2) Client-Server: As for most of the web, the client-server strategy applies pretty nicely for multiplayer games too, with scope for high scalability. This strategy allows us to have a game server that can be authoritative i.e. to be a single source of truth about the game state at any given point.

The game server holds the game logic and controls what happens on the client-side. This enables a fully synchronized game environment for all the players involved. All communication between the players happens only via this game server and never directly.

We’ll use the client-server strategy in our Space Invaders game. But before we continue, a note on network lag and linear interpolation:

In a live networked game, there’s a high possibility that a minor network lag might cause a bad experience for the person playing it. A common workaround is a technique called Linear Interpolation which allows predictively moving the game objects while the client is waiting for the next update to arrive, making sure the overall experience is as smooth as possible.

According to Unity, “When making games it can sometimes be useful to linearly interpolate between two values. This is done with a function called Lerp. Linearly interpolating is finding a value that is some percentage between two given values. For example, we could linearly interpolate between the numbers 3 and 5 by 50% to get the number 4.”

Linear interpolation is a very useful technique to keep in mind. It is out of scope for this tutorial, but I might add this as a feature in some future commits to the project.

Choosing the right networking protocol

HTTP/ Long Polling/ WebSockets/ MQTT — What, which and why?

HTTP’s stateless request-response mechanism worked perfectly well for the use-cases we had when the web originally evolved, letting any two nodes communicate over the internet. Since it was all stateless, even if the connection dropped, you could easily restore the communication from that very point.

However, with applications moving to realtime implementations, and trying to ensuring a minimal-latency sharing of data just as it is created in the real world, the traditional request-response cycles turned out to cause a huge overhead. Why? Well, in general, the high-frequency request-response cycles lead to more latency since each of these cycles requires setting up a new connection every time.

Logically, the next step would be a way to minimize these cycles for the same amount of data flow. Solution? Long polling!

With long polling, the underlying TCP socket connection could be persisted (kept open) for a little longer than usual. This gave the server an opportunity to collate more than one piece of data to send back in a single response rather than doing so in individual responses. Also, it almost completely eliminated the case of empty responses being returned due to lack of data. Now the server could just return a response whenever it has some data to actually give back.

However, even the long polling technique involved a connection setup and high-frequency request-response cycles, similar to the traditional HTTP based communications, with our original problem of increased latency still causing issues.

For most multiplayer games, including the one we are building, the speed of data is absolutely critical, down to the nearest millisecond. Neither of the above options proves 100% useful. 😐

Hello WebSockets! 💡🔄⏱

The WebSockets protocol, unlike HTTP, is a stateful communications protocol that works over TCP. The communication initially starts off as an HTTP handshake but if both the communicating parties agree to continue over WebSockets, the connection is simply elevated giving rise to a full-duplex, persistent connection.

This means the connection remains open for the complete duration of the application being used. This gives the server a way to initiate any communication and send off data to pre-subscribed clients, so they don’t have to keep sending requests inquiring about the availability of new data. And, that’s exactly what we need in our game!

Just a quick side note, if you plan to add any IoT based controllers to the game, later on, WebSockets might seem a bit heavy as IoT devices are very constrained in terms of bandwidth and battery — In those cases, you can use the MQTT protocol which is very similar to WebSockets but fits well within the IoT constraints. It also comes with an in-built implementation of the Pub/Sub messaging pattern (discussed shortly), you can read more about it in a separate MQTT conceptual deep dive article. I won’t be discussing it here as our game in its current state doesn’t require it.

Going back to Websockets, how do we get this protocol working? We could always write a WebSockets server from scratch. In fact, I even wrote an article a while back about how you can implement a WebSocket server in Node.js.

However, building this game is enough of a task in itself, so we don’t really want to get bogged down by side projects/ yak-shaving. Lucky for us, there are loads of WebSocket libraries that we can use to spin up a server in no time. The most popular open-sourced library for this purpose is Socket.io, and it has its share of good tutorials and implementations in the Phaser community.

As mentioned in a deep-dive article for WebSockets, the number of concurrent connections a server can handle is rarely the bottleneck when it comes to server load. Most decent WebSocket servers can support thousands of concurrent connections, but what’s the workload required to process and respond to messages once the WebSocket server process has handled receipt of the actual data?

Typically, there will be all kinds of potential concerns, such as reading and writing to and from a database, integration with a game server, allocation and management of resources for each client, and so forth. As soon as one machine is unable to cope with the workload, you’ll need to start adding additional servers, which means now you’ll need to start thinking about load-balancing, synchronization of messages among clients connected to different servers, generalized access to client state irrespective of connection lifespan or the specific server that the client is connected to -– the list goes on and on.

There’s a lot involved when implementing the WebSocket protocol, not just in terms of client and server implementation details, but also with respect to support for other transports (like MQTT) to ensure robust support for different client environments.

We’d also have to think of broader concerns, such as authentication and authorization, guaranteed message delivery, reliable message ordering, historical message retention, and so forth, depending on the specific use-case and game logic. A reliably ordered message stream is especially important in most cases as it makes all the client-side interpolation extremely straight forward. Otherwise, we’d need to use packet reconstruction and other techniques to implement this ourselves.

We can get out of this complexity nightmare by just using a serverless realtime messaging architecture that can support these by default. As you read in the first part of this article series, for our multiplayer space invaders game we’ll make use of Ably’s realtime messaging service which comes with a distributed network and serves as a one-stop solution to all the complexities we discussed above.

Understanding the Publish/Subscribe (Pub/Sub) messaging pattern

With always-on connections in WebSockets, comes the concept of subscriptions. To put it very simply, in a Pub/Sub messaging pattern, you can have clients that publish some data and clients that subscribe to that data, or both. “Subscription” is asynchronous: like a subscription to a magazine, you let the provider/publisher know only once that you are interested in a particular magazine, and every time they have a new issue, they send it over.

Similarly, with message subscriptions, you let the publisher know only once and then wait for the callback method to be invoked when they have relevant information to share. Remember, what makes pub/sub possible is that the connection is still open, and communication is bi-directional. That’s all we need to know about Pub/Sub to build our game, but if you are interested in learning more, I’d recommend reading through “Everything You Need To Know About Publish/Subscribe”.

The last thing we need to understand before we start writing some code is the concept of Channels. In any realtime app with a bunch of clients, there’s a lot of moving data involved. Channels help us group this data logically and let us implement subscriptions per channel, allowing us to write the correct callback logic for different scenarios.

Channels in our game

For a scenario with two players, our channels will look something like this:

The diagram might seem super complicated, so let’s try to break it down and understand what’s happening.

Since we’re implementing the client-server strategy, the players and the server will communicate via Ably’s realtime platform. The server will be authoritative, i.e. be the single source of truth with regards to the game state, and it’ll make sure all the players are in sync.

To do this, we’ll start off with two main channels:

• The game-room channel: We'll use this to fan out the game state and player join/leave updates
• The dead-player channel: We'll use this to listen to updates about a player's death due to a bullet hit

As shown in the diagram above, we also have a unique channel for every player. This will be used by individual players to publish their input to the game server(left and right arrow key presses), so it can then fan it out to all the players as part of the game state updates on the game-room channel.

Now that we have a good overall sense of how the game is designed, we can jump into the implementation details of keeping all players in sync in Part 3 — Implementing the server-side code to keep all players in sync

All articles in this series:

• Part 1: Introduction to gaming concepts and the Phaser library
• Part 2: Evaluating networking protocols for realtime apps
• Part 3: Implementing the server-side code to keep all players in sync
• Part 4: Finishing up the client-side code to render the game

A separate release relevant to this tutorial is available on GitHub if you’d like to check it out.

You can also follow the Github project for latest developments on this project.

As usual, if you have any questions, please feel free to reach out to me on Twitter @Srushtika. My DMs are open :)

Building a realtime multiplayer browser game in less than a day — Part 2/4 was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Do you play games?…. Duh! Ever thought of building one yourself?… Hmm..

Games innately seem difficult to build. With lots of moving pieces involved (quite literally), game development seems like it’s restricted to devs who’ve immersed their feet deep into the holy waters of networking, mathematics, graphics, and the like.

However, with the web evolving ever so rapidly and with all the new protocols and libraries that have spanned in recent years, it’s now super simple to get started with building browser-based multiplayer games.

In this article, we’ll look at the step by step implementation of a realtime multiplayer game of space invaders (ah, the nostalgia!) with Phaser3 and Ably Realtime.

Along the way, we’ll understand the architecture, system design, networking protocols behind this, and also look at the caveats to keep in mind when building multiplayer browser-based games.

This tutorial series is broken down into four parts:

• Part 1: Introduction to gaming concepts and the Phaser library
• Part 2: Evaluating networking protocols for realtime apps
• Part 3: Implementing the server-side code to keep all players in sync
• Part 4: Finishing up the client-side code to render the game

One last thing before we get started. This article assumes a basic understanding of JavaScript and Express/NodeJS. I’ll try and explain everything else as much as possible 👩🏻‍🏫💡

Let’s get gaming!

Part 1 — Introduction to gaming concepts and Phaser

Let’s begin by looking at the rules for the game as it’s not exactly going to be the same as the original retro classic.

Game rules for multiplayer space invaders

• When a new player joins, they’ll be randomly assigned a monster avatar out of the three available varieties.
• Each player can move their avatar left or right using the arrow keys on their keyboard
• Each player will see their own avatar in white but see everyone else will in a random colour that’s pre-assigned to them
• When a preset number of players join the game, a ship is launched. This ship moves along the horizontal axis in a randomly chosen direction that changes randomly every 5 seconds. Along with this, the ship’s velocity will also change. This ship also shoots bullets at regular intervals that we can preset as well
• All the avatars automatically move downwards with a preset increment throughout the game.
• The objective to win the game is to make it to the bottom border of the game screen without getting killed by one or more bullets being shot by the ship.

Components of a realtime multiplayer game

While it may seem like there are a bunch of things going on behind a networked realtime game, they really come down to three core components:

• Assets
• Physics
• Networking

Let’s look at each of these further.

1. Assets

Assets are the critical elements that make up the game. If you’d like an object to appear in your game, you can either draw one on the game canvas or better yet use an image or a sprite sheet and animate along. Similarly, any audio you’d like to introduce and play in the game would fall under its assets.

If you are interested in making your game’s theme super arcade, you can follow this pixel art tutorial by Glauber Kotaki to learn how.

2. Physics

Physics is what lets us move the assets around and decides how different objects in our game interact with each other. For example, in a simple game of pong, the ball is bounced back in a certain direction, with a certain velocity depending on which part of the paddle it collided with. Similarly, in our game, this could include computing where the ship needs to go, with what velocity, the shooting of bullets, the collision of these bullet objects with players’ avatars, etc.

All these things are basically mathematical calculations in line with concepts of physics, under the hood. But so much mathematics can be overwhelming to write from scratch even for a simple game. So instead of writing every from scratch, we can use a physics engine that can do most of the math magic for us.

3. Networking

The final core component which is especially important for a multiplayer live online game is networking. It can be super tricky to maintain the synchronization between all the players, figure out which player died and if everyone else agrees with that claim.

Don’t worry if all this starts to sound complex, it doesn’t have to be. There are many pre-existing design patterns that can help us get started in the correct way. We can choose how we want the game architecture to be, with respect to the mechanics of the particular game in question. Throughout this article series, we’ll talk about the patterns and architectural choices I went with to build this game and why.

Now that we have a better understanding of the core components, let’s explore how we can get these working in our game.

Using Phaser 3 to add assets and enable physics

Phaser is an open-sourced canvas and WebGL rendering JavaScript framework for HTML5. We’ll use Phaser 3 to build the game. The reason I specifically mention the version is that there are many breaking changes between Phaser 2 and 3 including the syntax. Also, in case you are looking to add some cool new features to the game yourself in the future, you should know what/where to look.

Not only does Phaser allow us to display the assets on a canvas, play the animations and sounds, etc on a web page, but it also comes with an in-built physics engine (multiple actually). This means that we can just tell it things like what needs to be done when two objects collide and it’ll automatically keep an eye for collision and execute a piece of code if it happens.

There’s a really good video tutorial series for Phaser that I’d recommend if it’s your first time working with Phaser 3.

In the TL;DR version of it, with Phaser3, we can specify a config object which would have the information about the canvas and the game itself, including the size of the canvas, its style attributes, various scenes that are included in our gameplay (discussed shortly), type of physics engine (as Phaser has many), etc.

We then pass the configuration object to start a new game.

This might sound a bit confusing as you haven’t seen any code yet. Let’s do that next.

Getting started with the game

Let’s get straight to the game screen for now. We’ll worry about the launch and leaderboard pages, later. Our game would be an HTML page with a canvas rendered on it. This canvas will hold and run the actual game. So, let’s create a file, call it index.html. To keep things organized, we'll store all our HTML files in a folder called views and all the client-side JavaScript files in a folder called public. Let's start the views/index.html file with a basic skeleton:

As you can see, all that we are doing here is link to the CSS and JS files which we’ll add shortly, but also more importantly the link to the Phaser JS CDN. You can copy the CSS directly from the GitHub project

Other than that, within the HTML body, we have a div with an id of game-container. This is where we'll add our game canvas through JavaScript.

Let’s create a file in the public folder, call it script.js and start by defining the game configuration object that we talked about earlier.

As you can see, apart from specifying the size of the canvas and its background colour, we’ve also specified where this canvas needs to go (identified by parent) and an array of the scenes that we'd like to be part of this game.

Phaser uses the concept of ‘scenes’ to organize the content of the game. You can think of a scene as what you are visually able to see at any point in time. While playing a game, if the game switches to a different background with different interactions among the game objects, then it’s probably a separate scene from what you were viewing before.

For our game, we’ll have a single scene (identified by GameScene). A scene in Phaser is a class that extends the Phaser.Scene class. Let's define this for our game. Add the following code above the config object as it is referencing the GameScene class.

As you can see, this class has three empty methods. These come with the Phaser.Scene class. Each of these methods has a different function as explained below

1. The preload() method gets all the resources that we might need, from wherever they are, loads them in and keeps them ready for when we’d like to add them to our game.
2. The create() method is executed once when the game first runs. We can add all the variable initializations, animation definitions, etc, in this method.
3. The update() method is executed continuously in a loop for as long as the game is on and hence is able to constantly update the game objects as per the game logic. We'll update the avatars, shoot bullets, move the ship, all in this method.

Loading assets and creating animations

Let’s go ahead and load some assets now. Define the preload() method as follows

I originally hosted this game on Glitch which stores all the assets in its bucket, retrievable by a CDN link. You can use the same, otherwise, Amazon S3 is another popular option.

We added three types of avatars, all in white and three other colours. Apart from those, we also added assets for the ship, bullet, and of course the explosion to play when a player dies.

As you can see, we loaded a sprite sheet asset in Phaser using this.load.spritesheet() and sent it three parameters:

• the identifier
• path to the actual file
• the dimensions of the file (in pixels).

We can also just call it an image but then we won’t be able to do the cool animations with it as you’ll see shortly.

P.S. there’s a better way to implement the avatar colours. We could simply add a colour tint to an existing sprite instead of loading the same object in multiple colours as separate assets. I don’t know how yet, but I’ll update this when I’ve figured it out :)

If you inspect the “explosion” sprite sheet, you’ll see that it’s a bunch of different images placed next to each other. The way we cause an “animation” is by going through these different images at a particular speed which makes it seem like it’s actually a transparent video of an explosion happening.

In the create() method, we'll define the animation for this explosion:

We’ve used Phaser’s this.anims.create() method to create the animation. This method takes in:

• the key which we'll use later to play this animation
• frames which generates frames using the identifier of the asset to which we'd like to apply this animation
• frameRate that specifies the speed at which we'd like to play this animation
• repeat that specifies how many times the animation will run
• hideOnComplete specifies whether or not the asset which was being animated should go away after the animation is done

We won’t add anything in the update() method for now. If you notice, we haven't actually instantiated the game either, we'll do that in a later part of this article series.

That’s it for now. We’ll learn about networking for realtime apps in Part 2 — Evaluating networking protocols for realtime apps

Other articles in this series are:

• Part 3 — Implementing the server-side code to keep all players in sync
• Part 4 — Finishing up the client-side code to render the game

A separate release relevant to this tutorial is available on GitHub if you’d like to check it out.

You can also follow the Github project for latest developments on this project.

If you have any questions, please feel free to reach out to me on Twitter @Srushtika. My DMs are open :)

Building a realtime multiplayer browser game in less than a day — Part 1/4 was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.