chat-service project announcement and overview

This article is a short overview about design and goals ofchat-service project. It is written in ES6 as a Node.js module and isavailable via npm. This software is essentially an additional semanticlayer for an arbitrary publish/subscribe system via an integrationplugin. As the name suggests, it uses familiar concepts from roombased chats. The main goal of chat-service project is to make realtimeAPIs creation on a par with REST ones. So just like any REST server itis designed to be run inside you own environment first, and be just ascustomisable and extensible. Modern web-technologies like SPAframeworks with a lazy loading and/or a server side rendering allowsto easily use and integrate background connection based APIs for anyweb project.

The main reason to use such systems is that they are able to providevarious realtime interactivity information across anapplication. (when REST architecture is focused to provide an accessor modifications over just a single resource). A common usage exampleis an implementation of various social interactions, like who isonline on a friendlist, who is viewing a particular page,notifications about when the new content is available, etc. And from abusiness point of view a better socialisation means a better retentionin the end.

Overview

Most messaging systems can be split into two logical parts, namely afrontend client to server channel implementation and a backendbroker. chat-service is designed to be in between of this parts and dosomething like `wiring`. It implements an application level messagingprotocol, on top of which an application data can be exchanged asmessages. It is the same approach that is used in many otherapplication and low level networking protocols, and it allows tocreate well defined public and private APIs. Socket.io transportsupport is included, but again due to a pluginable integrationarchitecture support of other messaging solutions can be added.

The first and the most important thing that chat-service provides is areliable room messaging. This is done via an ordered history, so evena client that was not previously subscribed (joined) is able to getmessages history. The second one is a realtime presence and permissionlayer. Also chat-service provides a distinct user concept that is notrelated to a connection, so independent multiple connections from asingle user are fully supported. This all essentially providesintrospection and manageability properties.

Most messaging solutions are designed for massive horizontal scalingin mind, so the main challenge is not to introduce a bottleneck whenimplementing additional semantics. chat-service is implemented as astateless microservice, so horizontal scaling is also supported. Thestore layer is using Redis (or optionally a memory store for testing)and is also designed to be scalable via Redis cluster. All data isarranged in buckets and Redis transactions or fine granular locking isused (just on a part of a single user state). This approach ensures adata consistency without introducing bottlenecks on the storeside. Moreover an additional operations and events are provided toreport and fix cases when a store can’t be updated due to variousbackend infrastructure failures.

Another important thing is the ability to extend and/or customise, asa chat rooms pattern is a good starting point, but definitely not theending one. Customisation can be done via hooks for chat-serviceprotocol event handlers or via invoking server side APIs. So otherpatterns like listen only rooms with server as a messages emitter canbe used. For example, a POST/PATCH handler can emit room messages viaa server-side API when a new content is added or an old one ismodified. Hooks are just JavaScript functions that return promises, soarbitrary complex asynchronous logic can be implemented. Generallyevery action that can be made from the client side can be made from aserver via an API. And every action has before and after hooks forrunning a custom logic inside.

Current state

This is an open source MIT licenced project. As for version 0.10 theproject has a good test coverage of 99.5% lines, well-defined publicAPIs documentation and a reasonable internal architecture. So manybreaking changes are not so likely to happen before 1.x release. Butas the semver defines it is still in a beta stage. Also any feedbackis welcomed.

Guthub repository

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!