It was a long time coming: improvements to Obie’s dashboard. I wrote the dashboard very early on in the company, and have since learned and grown so much in my development skills, as most coders do over a period of years. My team and I worked diligently in Q1 to redesign and speed up the dashboard. We’re extremely happy with the release and wanted to share some of the more technical aspects.
Redesigned UI and UX
If you’re a long-time Obie user, and visit the dashboard, it will be very obvious that there have been changes. The UI is completely redesigned and much more beautiful now. There are also UX tweaks everywhere, based on feedback from users, about completing actions such as user management, permission management, and navigation through the dashboard in general.
The dashboard used to be on the tasytt.com domain, but this caused a bit of confusion when we launched Obie 2 years ago. We’ve moved everything over to the obie.ai domain now and the consistency across the product is already providing a much cleaner experience. Dashboards can be viewed at https://<subdomain>.obie.ai
We rewrote many functions to work asynchronously. Instead of loading data on the server before the page is served, we now display the page as quickly as possible and then call our internal APIs to get any of the meaty data needed on the page.
Because the dashboard was the first thing we built at Obie.ai, it’s gone through the growing pains alongside the rest of the company. Dead code, failed features, and massive blocks of commented code were lingering everywhere. To be clear, this existed due to sheer laziness, recklessly fast product iterations, and not really knowing where the product was headed. While the unused code didn’t really matter much to end-users, we got rid of all of it to tighten up the codebase. There were places where some of these unused features were still being initialized and this did have an impact on the speed of the dashboard, so we were happy to remove them.
All of the data retrieval server-side was audited to ensure database calls were optimal, targeted, and running simultaneously where possible. Many poorly written actions were fixed, and we hope to find more in the future, because that means we’re learning.
We started storing some of the more static data in Redis. Sometimes manipulation is needed server-side, so if the data doesn’t change much, we can cache the final data model after the first load for speedier subsequent loads. While our databases and servers are fast, Redis is faster, and we focused on cutting down 500ms to 250ms, 250ms to 100ms. Any little wins we could achieve, we took. Those 250ms operations start to add up quick!
In case you haven’t heard, HTTP2 is the shit. The main feature is called request multiplexing, and what this means is that multiple requests for data can be sent over a single connection to a web server, instead of multiple requests requiring multiple connections. The overhead is drastically reduced and this means faster load times all around. You can read more about HTTP/2 here: https://medium.com/@factoryhr/http-2-the-difference-between-http-1-1-benefits-and-how-to-use-it-38094fa0e95b
Standalone Fast Servers
We migrated the entire dashboard and APIs to dedicated servers. This means we can scale pretty much infinitely if we need to now. Obie also communicates with the dashboard servers often, so the dedicated and faster servers let Obie respond to you more quickly with knowledge or a snappy remark.
There’s likely a few technical enhancements we made that I’ve missed. Between launching our robust Jira Service Desk integration and deleting all that nostalgic code, it was a whirlwind Q1 2019.
We haven’t slowed down in Q2 2019 either. Improved Obie search results and natural language understanding is in Beta for users who opt in, and the frequently-requested slash command is now live. Read more about all the latest and greatest here: https://blog.obie.ai/a-brand-new-way-to-search-for-knowledge-at-work-e4e0519f5cc0