Technology is evolving at an unbelievably fast rate. As technology evolves, we modify architectural patterns and designs accordingly to stay relevant. However, there is one pattern that we have no chance of saving. It can’t keep up with the times. While it was a great pattern in its heyday, the Provider model has failed to keep up with SaaS vendors. The way these providers serve up their APIs, we don’t need to be wasting our time wrapping service calls anymore.

If you are not familiar with the Provider model, it is a pattern designed by Microsoft to be used when calling into an API or third-party service. Developers wrap the service with their own code so applications call into their managed code instead of directly into the provider. This allows the company to swap providers without making changes to the calling applications, but rather the provider wrapper.

Let’s explore some of the prior reasons to use the Provider model and discover why they are not relevant anymore.

Reason 1: Your application code will only ever call your code

Theory: By wrapping a third-party service with your own code, you can ensure that the interface between your application and the service will never break. If the provider changes a service call you use, you only have to change your wrapper and not all the applications that take advantage of that feature.

Reality: Trying to mitigate the risk of a breaking change in a third-party service by wrapping it is a wasted effort. These days, if a SaaS vendor is going to make an update to an existing service, they will maintain backward compatibility. If the vendor does introduce a breaking change, they will either release it as an optional major release or add it as a new service. The chances of a service you currently utilize breaking with an update is slim to none.

Wrapping services will also limit you in development. Some SaaS vendors have rich functionality only provided through their site instead of with their API. Take Twilio Studio for example.

Twilio is a Platform as a Service (PaaS) company designed to send notifications to users. They have a robust set of APIs for your application to call that will send texts, emails, or make phone calls. But if you only interface with their API, you do not get the rich set of features provided with Twilio Studio to build a flowchart with logical branches, lookups, and updates. You effectively limit yourself to sending cookie cutter messages and put all the logic and routing responsibility on your application.

If you only wrap the calls you expect to use in your application, you will lose your API discovery. If you are unfamiliar with the term, this is what we do as developers when trying to figure out what actions a library can take. We open our IDE and use intellisense to scroll through available functions and properties on an object. If we have only wrapped a select few API calls to the third-party service, we have effectively removed our ability to take full advantage of it because we will not know what other functionality is available.

If you wrap all the calls available in the service, then chances are you either have summer interns at your disposal, or you have underutilized one of your staff by implementing some APIs you never intend to use. The benefit of doing this is that you get full API discovery. The downside is that you will have wasted some time building calls you will never use.

Reason 2: You are not locked in with a specific vendor

Theory: The provider model allows you to swap vendors easily without making changes to your application code. The only changes that need to be made are to your service wrapper layer so that it can reference the new provider. The application will continue to operate normally even though you have changed the vendor on the back end.

Reality: 99 times out of 100, you are not going to switch the vendor. Unless they are drastically changing the price for the service on you, there is no reason to change. You have built up rapport with the vendor. You know their reps and they know yours. Even if they do change the contract price, it is not going to be without notice. You will have time to research alternatives by the time your contract runs out with the current vendor.

Switching to a new vendor brings the risk of not maintaining feature parity. The new vendor could have new APIs for different functionality, but if they do not offer what your applications already use, you will cause disruptions to your user base, leaving them frustrated and unhappy. Even if the new vendor does offer the same features, it is possible it needs different information than the old vendor. This means your contracts would have to change in your service wrapper layer, causing you to make additional changes in your application code as well.

Reason 3: It is simpler to manage your own code

Image by Magic Creative from Pixabay

Theory: Writing a wrapper will allow you to control the input and outputs for service calls from your application. It is simpler because you define the method signatures and can enrich the calls in a controlled manner without having to rely on a slew of developers to know what needs to be passed in. You provide a safety net by way of a black box. The wrapper takes the complexity out of the calls to the vendor API. If a value needs to be changed that is passed into the API, you can change your wrapper accordingly.

Reality: Companies that provide modern SaaS or PaaS software have taken a service-first approach, meaning they have put a strong emphasis on providing simple, intuitive APIs with robust examples to kick start development. It is not nearly as difficult to integrate with vendors as it used to be. With the rise of the RESTful API, calling into a provider is as simple as making an HTTP request. Utilizing these APIs is easier than ever.

Building wrappers around service calls now means you must manage that code as well. You are creating additional code to maintain that provides limited additional value. Depending on your language of choice, calling an API from a SaaS provider could be as little as one line of code. But if you had wrapped that service call, you now are required to maintain the entire class, method signatures, and bloat your code base.

Final Thoughts

Making API calls to service providers is easier than ever. Don’t be afraid to call them directly. Wrapping the APIs with your own code just adds bulk to your code base and doesn’t provide much additional value. With the rate of change we are seeing in the software development world, time-to-market needs to be at an all-time low.

Building small and specialized applications is a great way to reduce time to market. Making genericized wrappers for contingency ten years down the road is not going to keep you relevant. The app you’re building right now might be out of production in ten years and replaced by a newer application. To keep your application small, toss out the wrappers and call your APIs directly. If you need to swap out a provider, it should be as easy as changing a URL. Get used to the idea of being agile and adaptable.

We all want to build modern, relevant apps. So let’s stop using out of date practices like the Provider model, and put our focus on building applications, not wrappers. Your end users, stakeholders, and developers will all thank you.

Have you found a modern use for the Provider model? Are there other patterns you think we need to kick to the curb?