Donut Driven Development — delivering a messaging service with the DDD you haven’t heard of
Fat Thursday, Bolludagur, Mardi Gras or Shrove Tuesday — regardless of where you live you have probably heard at least one of these names. It is a very long standing tradition that is part of the celebration of the carnival. The exact definition of this day or period may vary depending on where you are but the general gist is pretty much the same — have a good time, eat good food, feel good.
In Polish tradition we have the Tłusty Czwartek day which literally translates into Fat Thursday. It is the last Thursday before the Christian Ash Wednesday that starts lent. For one day many people stop counting calories and treat traditional Polish pastries as their main dish of the day. On Wednesday night bakeries and grocery shops arm themselves in huge amounts of sweets and starting on Thursday morning people come running to wait in line to get their portion, even though the lines are similar to the ones that some people remember from the communist times.
Of the typical pastries we eat there are faworki (pren. Favorki — the Polish word for angel wings) and pączki (pren. ponchki). Pączki are sort of the Polish equivalent of donuts but they are quite different and they serve as a score count for the Fat Thursday tradition. Together with vodka, kielbasa and pierogies they are probably some of the most known Polish dishes. You can even see Raymond Reddington — the main character of NBC series “The Blacklist” — enjoying some pączki when he comes to Warsaw.
This was supposed to be about software
Okay then, enough with the culture lecture — what does all this have to do with software engineering? Well, here in Jit Team we proudly uphold the Fat Thursday tradition and every year Jit treats its employees with a big portion of pączki. But for such a distributed company as ours (our employees are located in multiple clients’ locations and our own offices across the Polish Tricity area and Warsaw) coordinating the delivery of all of the presents in real time was quite the challenge. Every time a delivery came to one of the locations we needed to make sure all Jiters knew about it and email seemed not a live enough way of doing it.
Fortunately, we have WeJit — an inhouse system I already once wrote about. Since then it has expanded in features that serve the employees of our company and adding a messaging service that could serve as a way of distributing announcements felt like the natural way to go.
So there it was, we were to implement a messaging service into the web and both mobile platforms and had about 2 weeks to do it. The team was Paweł Puzio as frontend developer Olekwardyn as mobile developer and me as backend developer and mobile support. The first question was: what would be the base of the new feature?
Given that we had some experience with Firebase and that we do not like to reinvent the wheel just for the sake of it we went with the Firebase Cloud Messaging service. It’s a free of cost solution and Google delivers a proper API, so it is easy to configure and exchange messages, and most importantly it provides a very simple solution to send push notifications to Android and iOS phones.
Our use case was as follows: we have a web platform with a Java Spring backend and a React.JS frontend. Additionally we have two mobile platforms: Android written in Kotlin and iOS written in Swift. We needed to be able to send announcements (although only people with certain roles should have that option) and receive them on all platforms. The mobile apps should also issue push notifications to notify all the receivers of the announcements that they have a new message to read.
The way we designed our process was that when someone sends out a message, its content and recipients would be saved to the backend database and simultaneously a push notification would be sent out through the FCM service. So this way, when the message was sent, all mobile devices would get a notification and when someone opens the app either mobile or web, they could read all new and past messages that would be fetched from the database though our REST API.
Another thing that is good to know when using the Firebase Messaging Service is that although you can send a message out to all the devices that are using a certain app through the Firebase Console, you can’t do that using the API.
You have two options:
1. Send the device token from each client to the server. Each device that uses a Firebase app has its own device token assigned. If you store these tokens later on you can define who should be the recipient of the message by assigning their tokens. You can get this token through the FirebaseInstanceId API, but you should also implement the onNewToken method of the FirebaseMessagingService which is trigged every time the token of the device changes (which should not happen often but still might happen).
2. Use topics. You can create and subscribe to topics (for example topic “ALL”, topic “IMPORTANT”, topic “LOCATION_GDYNIA”). Everyone who subscribes to a topic will get notifications that are sent in them.
We went with the first option. It seemed more flexible because assigning a set of device tokens to each employee meant we could create our own filters or topics on the fly that regarded other information we had in the database like location, client or even send individual messages.
Having our strategy ready it was actually quite easy to implement, especially having an API ready for the notification part. About a week before the deadline we had most of the features ready and a couple days before Fat Thursday all the apps were deployed with all the requirements needed to coordinate the pączki fest. The announcement service was also quite helpful in future company events and given the way it was built some day we might even make it into a inhouse chat.
