“Work smarter not harder.” “Don’t reinvent the wheel.” There are many similar adages and they all lend themselves to the same principle of software engineering: making code that is extendable and reusable while still being clean and robust. With this principle, code only needs to be written once, decreasing the amount of time required for subsequent projects that are able to leverage the existing code. While it would be possible to just write the initial code yourself, it is also possible that the service you need has already been programmed and is available for you to use through a library which you are able to copy and store locally, or an API which you can access remotely. The benefits of utilizing such existing code are nearly instantaneous; most of the time your developers would have spent developing and testing the necessary features can instead be spent handling the implementation and extending the feature set to meet your client’s specific needs. Aside from the time saved with development, many of these third party resources have been extensively tested by actual users and can typically be assumed to be ready for full-scale production use.
There are, of course, also some downsides to using third party code, either through a library or an API. Chief among these downsides is the fact that you are limited by the design decisions made by another company and the risk that the code you are leveraging will change, thus breaking your own product. This latter concern is more evident with an API since you can maintain any version of a library that you want, but as libraries are updated with security fixes or enhancements that you want to leverage, you have to decide between upgrading and potentially breaking your implementation or continuing to use an outdated product. Over time, the challenges of updating your implementation grow as more and more code is deprecated. With APIs specifically you also have to consider the possibility that the remote server will go down, resulting in all of your calls failing, so you will need a method to gracefully handle these failures.
Recently, DialogTech designed the LeadFlow® call routing system and ultimately decided to leverage Google Drive and its associated Sheets API to handle our data input. This provided us with support for multiple users to edit their routing rules simultaneously with a full history trail for auditing purposes, and also gave our users access to all the technical features of Google Drive, including copy and paste, macros, formulas, and sorting.
These benefits had to be weighed against the various risks, specifically the fact that in order to utilize all of the sharing and history features, the end user had to have a Google account. Google also has some specific nuances that must be taken into consideration, such as the fact that the first row in the document is stripped of any special characters as well as capitalization and that the spreadsheet is terminated immediately upon the first empty row reached. That is to say, if a user has five rows of data, followed by a blank row, followed by another fifty rows of data, the Google API will only return the first five rows and tell you that that is all the data in the file. We also had to consider how best to store the data from the sheet locally in our own database and how to keep that local copy in sync with the remote copy stored in Google Drive.
The answer to the question, “Should I utilize a library, an API, or write my own proprietary solution?” is unique to every project within every company. The principal of polyglot programming is crucial: you should always use the best tool for the job. Consider:
- How many features of the third party solution do you absolutely need?
- Which features are not required but would add significant value to your application?
- How difficult and time consuming would it be for your own developers to recreate these features?
- Are there any limitations inherent in the third party solution that your project cannot feasibly overcome?
- How much control do you need to have over the data? As one example, if you are need to maintain HIPAA compliance, passing any data over the internet with a third party API might not be a feasible solution, no matter how useful the existing functionality would be.
Leveraging libraries and APIs effectively can be a bit of a tightrope walk, but by taking the time to fully evaluate the pros and cons of each individual project you can ensure that your company is making the best decision possible, and your products can only benefit.