Creating Newton: Secure Collaborative editing behind firewall

What is Newton

Excellentable is the only spreadsheet solution in Confluence that provides collaborative editing.  To achieve this, Addteq runs and manages a collaborative editing service (CES), called Einstein, hosted in Google Firebase. This service allows connection from your Confluence instance and provides a seamless collaborative editing experience for Excellentable users. 

However, a lot of customers informed us that they had an organization-wide policy that did not allow external connections from Confluence. And since our current CES was managed and run by Addteq, these customers were stuck in single-user mode.

And that’s where Newton CES comes in. Newton, in very simple terms, is a packaged version of Addteq’s collaborative editing service hosted by the customer.

The Challenges

First and foremost, since our customers have varied setups, we wanted to support Newton across various Confluence environments and databases.

Next, Newton needed a system that can queue and process network requests in real-time. This service also needed to be scalable to support collaborative editing for limited users.

Finally, since a lot of customers are already using Einstein without any issues, we needed a shared implementation of collaborative editing JS for both Einstein and Newton, so that a customer can easily choose between Einstein or Newton.

The Solutions

Initially, we wanted to provide the ability to create the service using Docker containers, since Docker containers are easy to create and deploy. However, since some customers may not be comfortable using Docker containers, we created additional options to host the service using Debian or RPM packages. In all three cases, we created a simple and efficient installation, which allow users to create the service at their end within minutes. 

Newton also supports all major databases like Oracle, MySQL, MSSQL, PostgresSQL, since you may be using any one of these databases. This is achieved by using dynamic data-source configuration based on environment variables. Environment variables can be defined during the installation. 

Queuing and Scaling was one of the architectural decisions we took during the initial system design phase. For efficient queuing, we used Spring Boot in-memory Simple Message Broker to manage subscription channels for synchronization across users and communication to the client in real-time via STOMP (Simple Text Orientated Messaging Protocol) and WebSockets.

While we received a lot of requests for collaborative editing behind a firewall, even more users were comfortable using Addteq’s Einstein service. We wanted to keep only one version of Excellentable on the marketplace and give users the option to choose the collaborative editing deployment option between Einstein and Newton. To achieve this we created a standard template design pattern to share most components amongst either services and subclasses implementing independent initialization and communication methods. 

What’s Next

Newton CES service is now available on the Atlassian marketplace. Even with this exciting announcement, we are continuously adding more features to Excellentable. We are also always looking for feature requests, ideas, or suggestions. If you have any suggestions or a feature request, let us know. 

Related Content
work from anywhere
Embracing the Freedom: Work from anywhere
If our products can be used from anywhere, we should also be able to work from anywhere. This blog shows...
Be_Unstoppable
Jira Accessibility: Best Practices for enhancing collaboration
Jira is a powerful tool to streamline workflows and enhance productivity. This blog explores four best...
addteq_fb_collab4b
The Perfect Match: Confluence & Excellentable
Discover the perfect match for your team's collaboration needs this Valentine's Day. Learn how to seamlessly...

Leave a Reply

Your email address will not be published. Required fields are marked *