White-Labeled EngagementHow We Built A Blazingly Fast & Secure Knowledge Management System Using JAMstack
To address knowledge management challenges at Axelerant, we built a system that classifies and aggregates data from Slack, while remaining scalable as the amount of data and the number of users grows.
Business Challenge
While our team at Axelerant uses multiple mechanisms to share information between stakeholders, Slack is perhaps the only application that every Axelerant team member uses across domains.
When it comes to solving problems and sharing knowledge internally between peers, we like to use a Q&A format within Slack. Asking a question is as easy as going to the designated channel (#internal-support in our case) and posting it there. Gradually, people with related experience contribute in the thread with their suggestions and solutions.
As of today, we have around 13,000 posts in this Slack channel, and each post has several replies as a part of the thread. This number will keep growing exponentially as our team size increases, and with this, we have started to run into a too-much-data problem.
Some of the challenges we were facing:
01. Searching 02. Tagging 03. Data Ownership
Even though Slack provides an intuitive search functionality, it isn't always easy to find relevant information. Unlike search solutions like Apache Solr or Elasticsearch which have lots of room for customization, with Slack we are limited to what’s provided out of the box.
Questions posted in a Slack channel do not have any form of classification. These are usually plain text or media (images, videos), and there is no metadata related to them. Because of this, we weren’t able to group questions based on the type of technology or domain.
Even though Slack does support exporting workspace data, it isn't immediately usable by the administrator or accessible to other Slack team members who have limited permissions.
Solution
When considering building a knowledge management system, we had some strong preferences, especially around security and user experience.
With JAMstack, we were able to build a collection of microservices that helped reduce the surface area of vulnerabilities and attacks. And since the application is primarily static content served over a CDN, we paired it with client-side enhancements to build a fast yet pleasing user experience.
JAMstack helped us reach our goal while keeping the application blazingly fast, secure from vulnerabilities, and cheaper in terms of development effort and infrastructure expenses.
Results
Gatsby
Even though there’s a plethora of options when it comes to static site generators, we specifically chose Gatsby because of its massive ecosystem of plugins and the community around it.
Gatsby generates static markup for the initial page loads. However, for subsequent interactions React.js kicks in and takes control, which makes for a delightful user experience. Since Gatsby is built on top of React.js and uses JavaScript tooling, it uses various libraries and tooling available in the ecosystem to improve the developer experience significantly in comparison to other solutions. Features like hot reloading of code, CSS extraction, declarative rendering, asset pipelines and a lot more come inbuilt with Gatsby, while in other solutions these are either difficult or impossible to implement.
Netlify
Netlify is one of the leaders in the JAMstack infrastructure ecosystem. Besides their static site hosting, we also leveraged several other features they offer, including Functions (serverless), Identity (authentication), Preview deploys, and a few more.
To configure the project to use Netlify we just had to connect our Git repository—and that was pretty much it. We stuck to the default structure and we didn't have to make any additional changes—unlike other systems where one has to maintain many lines of YAML configuration. Since all the services on Netlify follow serverless principles, we won't need to make any changes to our application even if the amount of content or the number of users changes drastically.
Slack Apps
Chat applications have become ubiquitous in the workplace, and Slack has been leading the race for a while now.
To help us consolidate, process and classify this information, we built a Slack app that allows users to capture and tag the message before it is passed to the JAMstack application.
Since everyone on the team uses Slack, there is no additional onboarding, infrastructure, or development required. We just built a serverless function which listens to events from Slack and uses Slack Web APIs to fetch the data and add it to our JAMstack.
Ask anything about how we ran White-Labeled Engagement - or what it would look like for you.
Foyer is grounded in our own playbooks and the named work behind this record. Go deep on the methodology, the decisions, the team shape - or bring your own problem statement, use case, or intent and we'll talk it through against your industry engagements.
Have a similar shape on your plate? We'll come back with how we'd run yours.
The White-Labeled Engagement engagement moved operational metric moved. If your situation rhymes, send us the brief and a named delivery lead will respond inside one business day.
A short brief. A named partner replies within one business day.
Six quick fields. Nothing you would not tell a colleague in a hallway.
Replied to by a named partner within one business day.