Let’s start at the beginning - What’s an API? Simply put, an API is a way that two software programs can talk to each other and share data. Just as humans share data through a common language so do computers.
In life there’s often a right way and a wrong way to do things. Software development is no different. When done wrong, one common issue we see with Rock integrations is how they use the Rock API (data sharing language). For example, say you wanted to get a large number of files from a filing cabinet. Would you:
- Walk to the filing cabinet.
- Open the top drawer.
- Retrieve one file.
- Close the cabinet.
- Walk back to your desk.
- Place the file on your desk.
- Then repeat steps 1-6 for every file you needed?
Of course not! But that’s just what many integrations do to Rock. Instead, it would be much wiser to make a single trip to the filing cabinet, grab all the files you want and return to your desk at once. We call this “batching your requests” to the API. To do otherwise can be considered API abuse.
Sounds simple, right? Well, you’d be surprised how many integrations abuse the API in this way. When asked about it, service providers respond with something like “I’m using the API that Rock provides.” True, we do provide those single lookup calls, but they were specifically made for just that - getting information on one ‘file’. When you need lots of data you need to use calls that bring back multiple records at a time. Rock has many of those, but on occasion you may need to build a custom ‘purpose built’ endpoint if you need something very specific (which Rock also allows).
Let’s look at a real-world example. In our consulting we ran across a medium-sized church who was working with a system that wanted to integrate to Rock. This service provider was using Rock’s API to pull the data out of Rock every two hours.
Below is a chart of all traffic to their Rock server. Each bar represents a single day, and the colors represent a single address on the internet. Your first question would probably be: What’s the blue bar? It must be the church’s internet connection, right? Heavy traffic because of all the staff? Well - no. That’s a poorly written third-party integration which is accounting for 86% of all their traffic to Rock. Note that the first bar is a Sunday. How is this traffic impacting Sunday check-in? In this specific case the integration forced the church to upgrade their server infrastructure to support the integration, which is a cost they were not expecting.
This is not to say that all integrations are bad. In fact, there are a lot of organizations doing it right. So how do you know the difference? Here’s some advice:
- If the integration is a popular one like the My Well Gateway or Pushpay Plugin, then you’re probably OK (in both examples they are doing an excellent job of using the Rock API). Popular integrations have been vetted by many organizations, and most potential issues would have been discovered by Spark or other Rock Partners.
- Integrations done by smaller studios or niche partners should be evaluated by third-party technical specialists with a deep knowledge of Rock like Triumph or other Rock partners.
When you step into the world of technology, you take on a lot of responsibilities in order to be successful. At Triumph we’re here to help you navigate those waters to ensure your success. Reach out to us if we can be of help.