Building Middleware for Quickbooks and Jira using React

Solspace has a brilliant human being in charge of accounting and finance. But every month, she loses a week of creative productivity due to our arcane billing practices.

It’s 2023. Computers should be in charge of moving data around and processing it. Humans should be in charge of making computers do stuff.

So I built a headless, composable web application that ties into the Atlassian, Stripe, and Intuit APIs to grab data, process it, and move into the right place at the right time.

The result is that we have unlocked the valuable creative potential of one of our most important team members. What used to take days per month now takes minutes per month.

In our client work, we are always looking for ways to reduce resistance and friction. If you reduce resistance on a boat moving through the water, it goes faster with less energy. If you reduce friction on a website, you make more money with less effort. This project to build a connector between our project management and accounting software is a perfect example of using web development to streamline business processes by reducing friction.

When we reduce friction, we make systems more reliable. We also make systems more reliable when we reduce human error. If a lot of data is moving from one place to another, try to get the humans out of the middle. Humans are great at human stuff. Let computers be great at computer stuff. A good web developer can help you find the balance.

This new system I built for handling our bookkeeping data touches all of our most sensitive financial information. It had to be secure from beginning to end. The tech stack I chose supported this. The whole thing is gated behind OAuth 2. You can’t access the tool or its data without first logging in through a valid Jira account that has been flagged as authorized for this particular web app. That’s basically a whitelist of three Solspace Jira members from the leadership team. It’s tightly controlled.

The universe of Javascript has exploded in recent years. I could tell early on that several of the newest Javascript-based tools would be perfect for this effort. I quickly realized as well that headless and composable concepts would suit this project very well.

A headless website is disconnected from any monolithic platform or framework. A headless website or web app merely needs an API from which to retrieve its data. The presentation layer can be made up of one framework like React or Vue or several such frameworks, depending on the needs at hand. This headless architecture was perfect for my needs since I had multiple data sources and variations in the presentation layer across functions.

The new tool is also considered composable because it is highly componentized. It is made up of several open-source Javascript packages as well as several web services. With modest effort, any of these components could be swapped out in the future as needed. This greatly reduces the pressure on the initial tech choices. If I end up not liking part of my system, I can change it out for something else without compromising the whole. I am not restricted by any single purchase or platform. I am free to make my best guess and change my mind later.

There’s a lot of buzz about serverless web applications. It often makes little sense compared to a traditional web hosting environment. But in this case, it was perfect because the tool I built will be used in bursts of activity, not necessarily every day or every week. Until my web app is needed, it doesn’t really exist. When my head of finance needs to process some data, she hits the URL of the tool, and it comes to life. Otherwise, it’s dormant and not costing me much money. Not to mention, no one has to monitor it to make sure it's always running.

As well, with serverless web apps, you are poised to enjoy exponential scalability. The tool I built does not require this, but many other websites and web applications Solspace works on do.

Vercel is basically a serverless hosting provider, but it is much more. Vercel maintains the open-source product mentioned above, Next.js. Vercel packages up the complexities of serverless and edge computing and makes them readily available to web developers as a cohesive whole. They take the static out of these new technologies and deliver a developer experience that is frictionless and reliable. We simply commit our code to a Git repository connected to Vercel, and they do the rest. They handle the CDN layer, the serverless provisioning, and the edge computing as needed.

The presentation layer of my little time-saving tool is built in Next.js. This means it’s fast in a browser. Next.js is an open-source Javascript tool offered by Vercel as part of their commercial serverless hosting offering. Next.js handles the creation of static web pages as well as the serving and consuming of web APIs to handle dynamic parts of web applications.

Next.js is built for speed and performance. It relies on React to help deliver on this promise. React performs exceptionally well in the browser, creating dynamic, delightful interfaces that don’t weigh down the browser or the CPU of the computer it’s running on. And since Next.js uses the Typescript variant of Javascript, it is strongly typed. It is hence more maintainable and scalable at the web developer and coding level. If I come back a year from now and change some function behavior, such as omitting a variable or converting an output by accident, Typescript will let me know clearly where my problem is.

In my experience as a web developer, there is no faster way to develop a web app than with a Javascript-based architecture. Some of the brightest spots in open-source web development are taking place in Javascript-land. In a matter of seconds, I found multiple Javascript packages supporting each of the primary functional areas of my web app, from authentication to OAuth 2 to the Atlassian and Intuit APIs to the database layer as well as the nuances of the presentation layer. In everything I touched, another smarter web developer had already been there and published a useful package for me to use.

Not only was I able to quickly assemble an initial proof of concept, but the resulting launched web application is quick and easy to modify and maintain. For example, at one point, we decided to make all of the primary user interactions based on date ranges. We wanted to constrain how much data we processed and verified for sanity’s sake. In an hour, I had converted over the UI and the API, as well as the database layer, to support the new requirement.

Over the years, we have built a lot of middleware at Solspace. Anytime we are integrating two or more systems together, we build something in the middle to make sense of the data as it moves from one place to another. This is really where we tend to add the most value to our client projects. This middle data processing layer is where a client’s specific business rules and requirements receive attention.

In our case, the middle layer was the place where data customization lived. Here’s an example: Jira has a concept of project but it does not natively have a concept of client. At Solspace, we use Jira projects, epics, parent issues, and issues in very particular ways. I needed to translate all of this into Quickbooks online, a system that had very different language and concepts. This middle layer of my application was the place where that logic could live and be maintained over the years.

I’ve been hearing that one of our clients gets a kick out of knowing that the owner of the company built a core part of their new website. That’s unusual for an agency the size of Solspace, but I’ve learned over the years that I cannot effectively help new clients find the solutions to their web reliability problems without me knowing intimately how current technologies might be able to help. So I seized on the chance to solve several Solspace problems at once: streamline our back office flow, unlock team potential, and demonstrate the potential of current web tech to current and future clients.