This is the first post of a three-part series
At Jobber we strive to help thousands of Home Service Pros worldwide in managing their business, and part of the mission is to rethink how they can do that more efficiently. In service of this mission, we built the Jobber’s Developer Center to empower developers to integrate and create applications to do just that.
The Jobber’s Developer Center offers a modern technology stack that facilitates the creation of applications. Companies such as CompanyCam and Thumbtack have already developed applications that enhance the Service Provider experience with Jobber. Our most recent integration was with Intuit QuickBooks Online. An internal team at Jobber was tasked with envisioning and building a seamless data synchronization between Jobber and QuickBooks Online.
Although the synchronization between the systems existed in Jobber since its inception, it was not user-friendly, causing friction for Service Providers who required cohesive data in both systems. Built entirely on the Jobber’s platform, using the GraphQL API and the Jobber Design System, the new solution expanded the capabilities of the platform and established a foundation for future applications to be built upon.
In this three-part series, we will dive into the pain points of the previous QuickBooks Online (QBO) integration, the principles we followed to develop the new application, the main architectural decisions, as well as provide details and best practices to help developers successfully build and launch their applications.
Rebuilding the QBO Integration
Nearly every small business begins by using an accounting solution before incorporating a workflow solution like Jobber. Effective accounting and finance practices are essential for running a small business successfully. We want our service providers (SPs) to be able to manage their businesses in Jobber while seamlessly integrating with QuickBooks Online, knowing that their accountants won't be pulling hairs at the end of each month.
However, the previous integration between Jobber and QBO had some drawbacks that hindered users' overall experience. The initial synchronization process was challenging and posed risks, often requiring extensive support from the Jobber Success team. It was difficult to determine which platform, Jobber or QBO, was the source of certain issues. The manual synchronization process did not meet consumer-grade expectations, such as simplicity and intuitiveness, and allowed unclear errors to accumulate. Moreover, maintaining and enhancing the integration had become increasingly difficult, resulting in long wait times for new features and bug fixes.
Early on in the project, the team decided to rebuild the integration from scratch, aiming to make it simpler, more capable, and fully self-serve. Throughout this endeavor, we established guiding principles to aid our decision-making process:
Focus on simplicity, predictability, and reliability: We can easily explain to SPs what will happen or has happened when they use the integration.
Establish Jobber as the source of truth: Optimize the integration for SPs who rely on Jobber as their primary source of information for quoting, scheduling, invoicing, and receiving payments.
Develop as a first-party application: Function as a first-party service independent of Jobber, leveraging our platform infrastructure and expanding its capabilities to support similar integrations, enabling others to build comparable solutions.
Automated and near real-time synchronization: Eliminate the need for manual syncing; every change made in Jobber will be instantly captured and pushed to QBO.
The core of the integration is an ongoing, automatic sync of data from Jobber to QBO. This process is supported by a simple, self-serve user interface that simplifies configuration settings and error handling.
Below we have some highlights of this solution. For more detailed information on how the integration works, please refer to our Jobber Help Center.
Once you connect the app and have your ongoing sync enabled, every change in Jobber will be sent to QBO and you can keep track in the Sync Activity dashboard.
A detailed view of an item that has been successfully synced shows the date and time it has been synced and also links to the respective item in Jobber and QBO.
Once an item is synced with a warning or error, the detailed view shows a clear message and provides you with actionable options to fix the problem.
In Jobber, if there is any sync activity that requires your attention you'll see an alert in your top navigation. Click the alert to view the sync activity dashboard.
During the import, if client duplicates are detected you will have the option of selecting the client in Jobber that the client in QuickBooks will be mapped to.
And if you want to change any default settings, the intuitive Settings page is where you can customize when each item syncs with Jobber.
Architectural decisions
First-party application
One of the initial architectural decisions the team had to make was how to rebuild this integration. Several tentative plans were considered for rebuilding the integration within our monolith. However, there were always constraints when it came to maintaining the existing integration while simultaneously incorporating the new one into the same codebase.
Developing an application outside of our monolith would provide the project with a greenfield opportunity to address all existing issues with minimal worry about backward compatibility. Additionally, it would allow us to take advantage of the nascent Jobber platform, expanding its capabilities to support similar accounting integrations or any other features that would benefit from the platform improvements.
Tech Stack
After deciding that it would be an external application, we had the option to select a technology stack that was better suited to its needs. Certain characteristics were prioritized in making this decision:
Performance: it should be able to perform an object sync instantaneously, i.e. in milliseconds
Scalability: it should support our current users already integrating with QBO and also support Jobber’s growth
Operability: it should be easy and efficient to operate, easy to maintain and troubleshoot, with high availability and reliability due to near real-time live sync.
Maintainability: it should be easy for the development team to include new features and resolve any issues without the need for major refactors in the future.
With those characteristics in mind, we chose Ruby and Rails for the backend, powered by a GraphQL API, React library for the front end, and Sidekiq for background job processing responsible for all the syncs. This tech stack mimics the core of our Jobber application, which allowed us to quickly begin development, and minimized the learning curve for the development team. We also took the opportunity to use the most recent version of Ruby and Rails at the time (3.1 and 7 respectively), opening opportunities to explore new features such as Native Encryption and incorporating a type checking Sorbet, built by Stripe.
Data Change Capture
To establish an automatic and real-time sync between Jobber and QBO, it was necessary to capture any changes made to objects in the Jobber application and initiate the synchronization process.
Within Jobber, we already have a mechanism for capturing data changes and notifying subscribers who can react to those changes. One of these subscribers is powered by our platform, which sends webhooks to external applications that have registered for events.
As an external application, it was crucial to not miss any of these webhooks; otherwise, the synchronization process would not be triggered, and both systems would be out of sync. To ensure the processing of all webhook requests, an AWS Lambda function was configured with a function URL— an HTTPS endpoint used for subscribing to webhook events. Upon receiving an event, the Lambda function validates the authenticity of the webhook request, ensuring it originated from Jobber, and then sends the event to an AWS SQS queue, which is eventually consumed by the QBO App.
Using AWS Lambda ensures high availability for receiving webhook requests, and utilizing AWS SQS allows for the necessary throughput to process all the updates without creating a bottleneck in the application, especially during periods of high activity.
Localstack to mimic AWS environment
We decided early on that we wanted our local development environments to match the production infrastructure as closely as possible. To do this, we used LocalStack to emulate the cloud services (AWS Lambda and AWS SQS) that our application required. This allowed us to build and test the code which interacted with these services without having to provision AWS resources for each developer, saving us both time and money.
Sorbet usage
Sorbet is a type checking gem built by Stripe, which adds static typing to Ruby. We decided to adopt it for this project to improve code readability, but also as a proof of concept before potentially adopting it into the larger Jobber codebase. In practice, we found both benefits and drawbacks to using Sorbet, as is often the case with any tool. The improved code readability and method introspection were noticeably beneficial during development, however, the new system made bringing additional developers onto the project difficult as they were unfamiliar with the new type system.
Summary
As we can see in this first post of the three-part series, there are several factors and decisions involved while building an integration application. Jobber created the Developer Center with that in mind, making it straightforward for any developer to develop their applications and integrate with Jobber. In the second post we will get into the technical details of how you also could build an application and everything you need to do from the app creation to the launch.
About Jobber
Our awesome Jobber technology teams span across Payments, Infrastructure, AI/ML, Business Workflows & Communications. We work on cutting edge & modern tech stacks using React, React Native, Ruby on Rails, & GraphQL.
If you want to be a part of a collaborative work culture, help small home service businesses scale and create a positive impact on our communities, then visit our careers site to learn more!
A post by Christian Ellinger, Christian do Prado Silva and Diogo Gallo
Top comments (0)