DEV Community: Ninjobu

You have unread messages

Ninjobu — Fri, 16 Apr 2021 16:30:34 +0000

Imagine creating a profile on this job searching site that promises to connect you to industry insiders. A recruiter sees it and messages you with a dream opportunity. But, you never see the message because you signed up to this site for fun and haven't logged back in to check your messages for weeks. That was Ninjobu, at least up until a few days ago.

In the last post, I wrote a bit about how I set up the chat system so recruiters could communicate with candidates. One significant omission was new message notifications. Since we have a web app here, it's unlikely people stay active on the platform for long, the way you might do on social media or IM. And, arguably, user communication is a crucial part of asynchronous job searching. It made sense for the next feature to be a way to let users know when someone contacts them.

My goal was to write a simple solution that would notify users when they have new unread messages while not being too naggy. The resulting structure ended up straightforward, implemented with just two Firebase functions.

As mentioned in the previous post, our database consists of chat documents that store the last message timestamp and when each chat participant last viewed that message. With this information, we can easily decide which users we should notify.

First, I added a new Firebase function that triggers on writes for each chat document. The onWrite trigger executes for the creation, updates, and deletions of documents. I ignore the deletion case, but I know the last message timestamp will have updated during the creation and update events.

When a chat is updated, it will have a lastMessageTime timestamp and an array lastSeenTime with two entries: one timestamp for each of the two chat participants, representing when they last saw the chat. If any of the lastSeenTime timestamps are older than the message, we record the chat id in a document misc/chats_to_notify for later. Firebase's FieldValue.arrayUnion utility lets us atomically add unique entries to an array.

With the above function running every time a chat document is updated, we will end up with a list of chat ids in our misc/chats_to_notify document. The next step is to go through these chats and send emails to the participants, as required. We do this with a second function that we schedule at a set interval.

Being tightly integrated with GCP, Firebase offers many features from Google Cloud wrapped in simple-to-use interfaces. One example is scheduling functions that run at predefined intervals, using Google Cloud Pub/Sub and Scheduler behind the scenes. The function that handles our email notifications is a bit chunkier, so let's split it into smaller parts.

I set up the function to run once every two hours, quickly done with the App Engine cron.yaml syntax.

Start by retrieving the misc/chats_to_notify document where we have the ids for our updated chats, and early out if the document is invalid or the list of chats is empty.

Once we have our chats, I chose to process only up to 100 of them on each invocation. Firebase functions have a running time limit of 60 seconds, and I don't want the function to time out and not send any emails if the list of updated chats is too long. However, my choice is a bit premature and speculative. The 100 chats limit was chosen arbitrarily, and Firebase allows the function timeout to be configured to up to 9 minutes. I'm also unsure how the function itself will scale with a significantly larger array of chat ids. I will likely have to tweak this once I have more data. But for now, processing 100 chats every 2 hours seems reasonable based on the website's current activity.

While looping over each chat, we add its id to the processed array and later use it to remove the entry from the misc/chats_to_notify document. Next, we retrieve the chat document data and validate the required fields. We need lastMessageTime to exist and the members array to contain the two chat participants' UIDs. We then save each member's UID if their lastSeenTime is older than the lastMessageTime. This check is important because, between the time the chat id was recorded in the misc/chats_to_notify document and the time this function runs, each member of the chat may have already seen the last message. We don't want to send an email notification for a read message. Our onWrite function for the chat document only adds chat ids to the notification list and doesn't remove them.

A thing to keep in mind here is, if we have 100 chats where the participants have both seen the messages, this function will process those chat entries and not send any emails until the following invocation 2 hours later. I'm not entirely happy with this, but I consider this part of the code temporary until I have more data on how many emails one run of the function can process.

We now have a list of UIDs for users that need to receive a notification email. For each UID, we get the user's email from the Firebase Auth module and create a personalization entry. Personalizations are a Sendgrid feature that lets us send the same email to multiple recipients with a single API call. It also ensures that each recipient will only see their email address in the to field and avoids catastrophic invasion of privacy.

Finally, we remove all the chat ids we have processed from the misc/chats_to_notify document to avoid sending multiple emails to the same folks. The FieldValue.arrayRemove feature allows us to do this quickly with a single call.

Speaking of the array with chat ids, it may be worth noting that at some point, this may become a bottleneck. Firestore document sizes have a limit of 1 MiB. If we assume the auto-generated chat ids continue to be 20 bytes each like they are at the moment, we have room for a bit over 50,000 entries in the array before we blow the size limit. Additionally, Firebase has a soft limit of one write per second to the same document that they don't recommend you go over to avoid contention errors. It's a soft limit in the sense that it shouldn't cause issues in short bursts, but something to keep in mind. If there's loads of chat activity on the site, the misc/chats_to_notify document will be hammered and potentially go over the one write per second limit. Once we hit these problems, however, congratulations are in order, most likely.

Thank you for reading this far. If you are a software engineer open to new opportunities but not actively looking for work, try out Ninjobu! Create a profile, let recruiters know what job and salary you'd like, and who knows what might happen.

Until next time.

Building a chat with Firebase

Ninjobu — Thu, 15 Apr 2021 01:25:26 +0000

How can users chat in my web app?

I recently launched Ninjobu, an anonymous job search platform for software engineers. The premise is, as a programmer, you create a profile with your previous experience, programming languages used, domain knowledge, etc., as well as what role you are looking for, preferred location (or remote), and desired salary. Next, you sit back and wait while recruiters search the list of profiles to find matching candidates for their open roles. Once a recruiter has found a potentially suitable candidate, they make contact and start the hiring process, which brings us to the chat system.

Ninjobu only needs a way for recruiters to initiate a 1-on-1 chat with candidates. There's no need for groups, file sharing, emojis, gifs, or similar features. Although you can send emojis just fine, there's no UI for selecting them, and it's more of a happy accident due to how Firestore supports Unicode rather than something I specifically implemented. The lack of these additional features simplifies the chat system's requirements somewhat, but we code what we need to code and nothing else, right?

Data design

I went with a design loosely inspired by the Firebase pricing example. The primary data consists of a collection of chats, where each chat has a subcollection of messages.

There are two members in every chat because Ninjobu only needs 1-on-1 communication. It's trivial to extend this to groups with additional members. Still, since I don't anticipate the need for multi-member discussions in this project, parts of the code occasionally assume only two chat members exist.

The members array then contains two entries: a unique user id for each chat participant. With these UIDs, we can find the chats for a specific user and block everyone else from accessing the data. Ninjobu uses Firebase Auth to authenticate users, and I use the UID from the Auth module to identify each user in the chat data.

The names array holds the name of the chat members, and the desc array holds a secondary string for each user. For the recruiter, this is the company name, and for the candidate, it's their preferred job title. Storing these strings in the chat document allows us to give each chat a bit of context in the user's inbox without querying any additional data.

Ninjobu aims to keep its candidate users anonymous. Candidates aren't even asked for their names when they sign up. When communicating with a candidate, their name shows up as candidate#xyz while the recruiter's name and company are visible as expected.

Lastly, we have a string with the last message sent to this chat and the timestamp when this happened. With this data in the document, we can query a list of chats and display them similar to how an email application might show the user a list of emails. When a user selects a chat, we pull the subcollection of messages as needed.

The message data is straightforward. Each document stores the author UID, the timestamp for the message, and the string itself. The UID is used to check the author's index in the parent chat's members array, and that index maps to the author name and secondary string in the names and desc arrays, respectively. You could store the member's index instead of the UID here, but using the UID simplified some of the front-end code in my case.

Firebase calculates the cost based on the number of documents read, deleted, and updated, in addition to network bandwidth usage and storage. With this setup, we duplicate some data, such as the last message sent, but it allows us to request fewer documents overall. The flipside to this is that when we post a new chat message, we need to create a new document in the message subcollection and update the parent chat document with the last message string and timestamp. I still think this is acceptable. Presumably, there will be much more document reads from users logging in and viewing their inbox than document writes from users sending new messages.

Keeping data private

Firestore data is encrypted when saved to the hard drives, and Ninjobu redirects any unencrypted requests to go over HTTPS, which means our data should stay safe in transit and at rest. But we still need to make sure chats are only visible to their participants. We do this with Firebase's excellent security rule system.

Firestore integrates with Firebase Auth to make our life easy. Since the chat documents have a members array with each chat participant's UID, we can write a security rule that gives access only to chat participants.

For unauthenticated requests, accessing the request.auth.uid variable will be invalid, and the rule will fail. Otherwise, we allow access to chat documents containing the requester's UID in the members array.

Unfortunately, there's a tiny glitch with this setup. When we first create a document, the resource doesn't exist, and we have no members array to check, so the rule fails. We need to treat the creation of the document as a special case, which we can do.

With the updated rule, we allow reads and updates to a chat document when the requester's UID exists in the members array already recorded in the database. However, when the document gets created, we expect the request to contain a two-entry array with the requester's UID present.

For nested documents, we need independent rules because each rule applies only to the specified path. The chat rule will have no effect on the subcollection for messages. However, we can still use the members array in the parent chat document when securing message documents.

The get() function allows us to read any document in the database. In the above rule, we access the parent chat and verify that the user is a participant - keeping in mind that document access in a security rule counts towards billing as a regular document read made manually.

Real-time chat

You can fetch data from the database at any time you like, but since we're trying to build a chat system, we want to see updates happen as soon as possible. If you hang out on your Inbox page, and someone sends you a message, you want to see it right away without having to do a page reload.

Firestore provides a way to register a listener on a particular query and then calls it with snapshots every time the data affected by that query is modified. It's incredibly convenient as data updates happen in real-time without any additional work to synchronize state between users. This way, the chat behaves more like a chat and less like a laggy email.

There's one caveat I'd like to mention so that you don't have to spend the time debugging as I did if you were to use a similar implementation as mine. If you build your UI around snapshot listeners, one drawback tends to be the high latency caused by the roundtrip to the database server. When you send a message, it gets sent to the server, the database gets updated, and only then does the snapshot callback trigger with the update. This update time is adequate for a chat experience, but it will be way too sluggish as far as UI responsiveness goes. Luckily, the folks at Firebase provide an excellent latency compensation solution.

With Firestore, a database change will first be applied locally, then sent to the server. The snapshot listener will trigger before the server has recorded the change, allowing the UI to update quickly. You can check for this in your callback, if you'd like, by looking at the snapshot metadata for the hasPendingWrites flag. The critical thing to realize is that the local change doesn't communicate with the server and has no way of running the security rules. This isn't a problem if you design the code well, but I didn't, so I had a problem.

When a recruiter on Ninjobu first sent a message to a candidate, it would create a new chat document and a subcollection with that first message. Then, in a snapshot listener for chat documents, it detected the new chat and immediately read its subcollection of messages to display on the page. If you remember our security rules earlier, we first look at the parent chat document and verify that the user is a member of that chat. In this case, the rule would fail because we queried the collection of messages for a chat document that had only been created locally and wasn't yet recorded in the database server. The solution was simple: display the message locally immediately, but don't query the subcollection from the database until the chat document write finished successfully.

But wait, there's more

I wanted to add a visual cue for when the user has new messages. I decided to go with a tiny blip next to the Inbox header to indicate unread messages and mark each chat the user hasn't yet read. For this to work, I needed to add some additional data to the chat document.

I added a new two-entry array, lastSeenTime, with a timestamp for each chat participant that indicates when they last read the chat. To detect a new message now is simple: we compare the last message timestamp with the new last seen timestamp for a member. When a user opens a chat and retrieves all messages, or a new message is received while the chat is open, we update the last seen timestamp. We can also use these fields to show when the recipient has seen a message, but I'm not too fond of that aspect of chat software, so I didn't add it to Ninjobu.

In conclusion

Firebase makes it incredibly easy to build a chat component for your web app. The design in this post may not be the best way to implement such a system, and perhaps it's not even very efficient. Nevertheless, it has worked well for Ninjobu, and I believe it will scale well enough for this platform's needs. If I'm wrong, there will probably be another post with the improvements made.

There is one thing missing from this chat system that I'd like to build next. When a user receives a message, they have to log in to find out about it. Ideally, we send an email notification to let them know there's a new message waiting for them. Once I build this, perhaps that will be the subject of the next blog post.