Engineering
Why ‘Utility API as a Service’ Is a Critical Component of the Developer Toolset
Exploring the pros and cons of building software utility API services, integrating with utility libraries vs using utility APIs like ApyHub
NI
Niels van Rikxoort
Last updated on October 06, 2022
The life of a developer usually involves designing and building applications that create value to different audiences. As a developer, at some point at least in the development lifecycle, while building your application you will face the need to use one or more common components or software utilities in order to deliver the value and functionality that your application promises.
Such utilities could be core to your app's business domain (e.g VAT calculation in an e-commerce platform) or essential to the smooth functioning of your application (like country lists, file conversions or image processing).
Say for instance that you’re building an app/website where users need to select the country code before entering their phone number when registering or checking out. And you also want to send an invoice (in PDF) to the user after they check out, and would like to watermark this invoice and send it to the user by email. You can probably think of many similar examples of utilities that you have used in your applications.
In order to do so, as a developer you basically have three options: you could decide to build these utilities in-house, you could go with finding and making use of external utility libraries that can be directly embedded in your code/application, or finally you could opt to use external utility services.
There are, of course, pros and cons to all sides:
-
Building your own software utilities will most likely mean more control over the code, the utility itself, and the data. From a compliance perspective, this approach also seems to be the most simple and straightforward. The downside? Bloated applications, high maintenance costs, and of course more resource needs (memory and compute).
-
Using external libraries has similar benefits when it comes to control over the data being processed and stored. On top of that, these libraries are relatively easy to integrate into the code and the performance is optimal as the library runs natively within the application. The downside? Bloated applications seem to be the main problem here as well. Moreover, there is some lack of flexibility as the libraries are tied to specific tech stacks; libraries can also be untrustworthy, and are resource intensive Finally, introducing a new library can be challenging for organizations with strong policies for compliance.
-
Using external utility services is the option that usually leads to leaner applications that only contain the core business logic, letting the rest be handled, managed and maintained by external parties (the service providers). Since these service providers are entities and not communities, the trust factor here is very high and developers can be certain that their applications can scale, upgrade and fit their growing needs. The downside? Applications usually need multiple services and have to rely on different service providers which results in managing multiple subscriptions and integration requirements- costs quickly add up.
Here’s a quick recap of the pros and cons of each:
| Pros | Cons | |
|---|---|---|
| Build yourself | • Complete control over the implementation of the utility • Control over the data being processed and stored • Ease of compliance | * Bloats the application • Requires more resources - compute and memory • Time consuming to build these utilities from scratch • Difficult to maintain • Cost time, money and resources • Takes attention away from the core application you’re building |
| Utility library | • Easy to incorporate into existing code base • Control over the data being processed and stored • Better performance since it runs natively along with the application | • Bloats the application • Libraries are tied to a specific technology stack • Depending on the utility, additional memory and compute resources need to be allocated • Upgrading utility libraries requires redeployment of the application • In some cases, untrusted sources for these libraries • Developers could also be building their internal libraries but then they have to maintain them • No guarantee for maintenance and support of these libraries • Compliance issues for larger organizations to vet every library being used |
| Utility API as a service | • Lean applications containing only the core business logic • Scaling of utilities handled by the service provider • Maintenance by the service provider • Updates to utilities require no redeployments of the application • Utility services are typically managed by an entity rather than maintained by a community, thus addressing the concerns over unknown sources • Choose plans that meet their requirements and upgrade seamlessly as the usage grows | • Multiple service providers for utilities • Managing multiple vendors • Subscriptions with each provider for a small set of utilities - costs can quickly add up • Integrations not uniform across these utility services • Enterprise or consumers data spread across multiple providers, potentially in different jurisdictions • Different terms & policies across these service providers • Difficult to monitor the usage across all these different services • Developers, could choose to build and launch their internal utility services, but then they have to maintain and manage them |
The need for agility and flexibility is leading many organizations (as well as developers, engineering managers etc.) to opt for the last (utility) service route.
‘Utility API as a service’ is slowly but steadily claiming its unique place in the developer toolset, as a model for organizing, connecting and consuming external services within an application.
This model, as shown above, comes with its own limitations, and ultimately slows down or takes attention away from core development.
So what’s the solution? A central point, a hub or platform where you could discover software utilities in different categories which coexist under a single subscription, as a service.
That’s where we come in.
ApyHub aims to be the single software utility API catalogue providing the necessary APIs that will help boost developer productivity.
Instead of going through multiple sites, service providers, libraries or marketplaces, you can access a pre-built catalog of frequently needed and used software utility APIs and tools for your app or website. No messy formats or requirements or fragmentation, uniform integration options and standardized reporting that make it easy to build, manage and monitor.
Also, no worrying about hosting and compliance, or unnecessarily bloating of your application. Our services are serverless and super light weight; no spring boot or heavy frameworks.
| ApyHub | Single Subscription for the entire catalog Unified catalog with optimized API subscription utilization (subscription applies to all services within the catalog) Utilities Operated, maintained and monitored by ApyHub Data managed by a single provider Standard and easy integration format Developer friendly platform All the controls needed for small to complex engineering teams |
|---|
When you start using ApyHub, you’ll need to spend a lot less time in R&D, testing, and worrying about maintenance. That frees you up to: build what matters most, focus on business critical functionalities, and ensure faster time to market (and take a hike, walk your dog etc. ;) )
Intrigued?
Photo by Fotis Fotopoulos on Unsplash