chat-service project announcement and overview
This article is a short overview about design and goals of
chat-service project. It is written in ES6 as a Node.js module and is
available via npm. This software is essentially an additional semantic
layer for an arbitrary publish/subscribe system via an integration
plugin. As the name suggests, it uses familiar concepts from room
based chats. The main goal of chat-service project is to make realtime
APIs creation on a par with REST ones. So just like any REST server it
is designed to be run inside you own environment first, and be just as
customisable and extensible. Modern web-technologies like SPA
frameworks with a lazy loading and/or a server side rendering allows
to easily use and integrate background connection based APIs for any
web project.
The main reason to use such systems is that they are able to provide
various realtime interactivity information across an
application. (when REST architecture is focused to provide an access
or modifications over just a single resource). A common usage example
is an implementation of various social interactions, like who is
online on a friendlist, who is viewing a particular page,
notifications about when the new content is available, etc. And from a
business point of view a better socialisation means a better retention
in the end.
Overview
Most messaging systems can be split into two logical parts, namely a
frontend client to server channel implementation and a backend
broker. chat-service is designed to be in between of this parts and do
something like `wiring`. It implements an application level messaging
protocol, on top of which an application data can be exchanged as
messages. It is the same approach that is used in many other
application and low level networking protocols, and it allows to
create well defined public and private APIs. Socket.io transport
support is included, but again due to a pluginable integration
architecture support of other messaging solutions can be added.
The first and the most important thing that chat-service provides is a
reliable room messaging. This is done via an ordered history, so even
a client that was not previously subscribed (joined) is able to get
messages history. The second one is a realtime presence and permission
layer. Also chat-service provides a distinct user concept that is not
related to a connection, so independent multiple connections from a
single user are fully supported. This all essentially provides
introspection and manageability properties.
Most messaging solutions are designed for massive horizontal scaling
in mind, so the main challenge is not to introduce a bottleneck when
implementing additional semantics. chat-service is implemented as a
stateless microservice, so horizontal scaling is also supported. The
store layer is using Redis (or optionally a memory store for testing)
and is also designed to be scalable via Redis cluster. All data is
arranged in buckets and Redis transactions or fine granular locking is
used (just on a part of a single user state). This approach ensures a
data consistency without introducing bottlenecks on the store
side. Moreover an additional operations and events are provided to
report and fix cases when a store can’t be updated due to various
backend infrastructure failures.
Another important thing is the ability to extend and/or customise, as
a chat rooms pattern is a good starting point, but definitely not the
ending one. Customisation can be done via hooks for chat-service
protocol event handlers or via invoking server side APIs. So other
patterns like listen only rooms with server as a messages emitter can
be used. For example, a POST/PATCH handler can emit room messages via
a server-side API when a new content is added or an old one is
modified. Hooks are just JavaScript functions that return promises, so
arbitrary complex asynchronous logic can be implemented. Generally
every action that can be made from the client side can be made from a
server via an API. And every action has before and after hooks for
running a custom logic inside.
Current state
This is an open source MIT licenced project. As for version 0.10 the
project has a good test coverage of 99.5% lines, well-defined public
APIs documentation and a reasonable internal architecture. So many
breaking changes are not so likely to happen before 1.x release. But
as the semver defines it is still in a beta stage. Also any feedback
is welcomed.
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!
