A group of friends and I maintain a telegram group to talk about investing. A few years ago, we developed a chatbot to search for some stock prices once we post the stock’s name. The bot is quite simple and makes it fun since you don’t need to google or any other platform to see the price of the stock you want to check (Check out the image one of me getting the price of bitcoin).

Suddenly one of the group’s contributors posts a message saying he had just released a feature to save stock portfolios to show all prices at once. It would be storing the data to FIREBASE. My next message could not be different, “firebase. WTF is that? Why have you not used Nun-db? Much better! I will fix this!”, everyone was supportive, even the guy who had just written the firebase version. It was a great opportunity also to compare the final code for each version.

The model

The chatbot needs are relatively simple, the user will type the name and the stocks list they want, the bot saves the value, and when the user asks for its portfolio, the bot will then pick it from the DB, take the latest stock value and return the chat where the user asked for it.

The bot’s load will be 10.000 times less than my SAS product already sends to Nun-db, so the load is negligible (as far as our bot doesn’t get too popular). I leverage the already running cluster in Linode k8s to create a new DB only for the bot (The same way I plan to do with future users if they don’t want to host the own instances of Nun-db). The next image shows how simple is this step.

When I start thinking about the use case, Nun-db(realtime key-value database) models fit better the need than firebase (realtime document database). Therefore the final code looked much simpler. Next, I will present the final code for both implementations.

Now check the nun-DB implementation done in 9 lines of code. It is much easier for anyone to understand what is happening, even not knowing Nun-db API or going over the documentation.

Now see the code in action on the bot when I ask for my portfolio and is post it back to me.

Conclusion

This is a relatively simple use case, where Nun-db was an excellent fit for, and now with Nun-db’s realtime capabilities, we are fully prepared to deliver new features like comparing your portfolio with your friend’s portfolios, watching a friend’s portfolios, and get notifications every time their portfolios changes.

The use case was an excellent opportunity to onboard a new Nun-db user to my shared cluster and start to see how it behaves over time. Now, I have two applications running sharing resources on a single k8s deploy. It’s been so far so good, I am still running it on a single pod because my data replication implementation was performing bad under high load, but that may be a subject to the next blog post.