Choose Your Friends Carefully, Choose Your APIs and Libraries More Carefully

As your software projects increase in complexity, chances are you’re going to have to integrate with external APIs and code libraries. A lot of the best libraries and APIs have large teams of experienced engineers working on them for years, and you can utilize all that work on your applications. Choosing the right ones can give you access to verbose data sets needed for your application, and build out a lot of the functionality and styling for you, allowing you to build much more professional, advanced projects in the same amount of time.

However, many APIs and libraries can be out of date, have many open issues, have unnavigable documentation, etc. So choosing the wrong technologies can, instead of saving you time, increase the complexity, time, and frustration you invest in your project while negatively impacting the number of deliverables you finish. This blog will go over some of the strategies and pitfalls of working with APIs and libraries that I’ve learned the hard way.

APIs

I highly recommend using RapidApi.com to search for APIs. There are other places to find APIs, for example I’ve used GitHub to find lists of free/public APIs, but I’ve had both success and a lot of aggravation testing out random free APIs with little insight into their viability. RapidApi lets you search for APIs, provides lists of top APIs for various categories, and gives you a bunch of information for any API you click on. For example, this API was found by searching for weather APIs and selecting one of the top results:

RapidApi shows you the popularity, speed, and service level for Foreca Weather API and gives a link to the product website. Another important tab is the pricing one:

APIs may have different subscription levels. If they have a free option, it might restrict which endpoints you can access, limit the requests you can make in a month or day, or limit your requests per second. This one has a pretty high request limit of 1000/day but if you need to make requests for the weather in multiple cities at once, the rate limit of 5 requests/second could be prohibitive.

If the API seems well supported and isn’t cost-prohibitive, next you should look at the APIs documentation, see what endpoints it provides and send test requests to the ones you’ll be utilizing. RapidAPi also lets you see and test requests to the different endpoints:

However, going to the product’s website to read about the endpoints and testing with postman or trying to navigate to send get requests from the browser (if there aren’t API keys or other headers required) are also valid approaches.

To sum up the API vetting process:

1. Search for the APIs you need on RapidAPI
2. Check their pricing and any request or endpoint limitations
3. Read their documentation to make sure you understand what endpoints are offered and how to send requests to them (either on RapidAPI or the product’s website)
4. Send test requests to the relevant endpoints.

Libraries

Code libraries have a similar set of concerns as APIs on a larger scale. A lot more effort goes into building a codebase than an API, so there should be comparably more documentation to read through and more to consider/learn before choosing to work with one on your application. There are various methods of finding code libraries to work with. Search Google, StackOverflow, DeveloperSDK (this tool is meant to be a more verbose tool than RapidApi where you can search for APIs, code libraries, etc. but it doesn’t seem completely built out/useful yet), etc. My preferred method is to search GitHub for libraries. GitHub gives you an idea of the popularity, support, and modernity of a library by how many stars and forks it has, how many open issues it has/how quickly past issues were resolved, and the date of the last update. For a simplistic view of how useful/workable a library is, I tend to search a keyword and a language or framework, for example, “ecommerce react” and sort by the number of stars:

Before even clicking on the top library, I can already tell it’s probably a great library since 15.7k people starred it, it was updated 6 hours ago, and only 2 issues need help. When I clicked on saleor, I also saw that it has great documentation, with detailed demos and installation instructions. However, it incorporates a lot of different technologies and has some hefty prerequisite installation steps. This is the time to think about your project requirements and timeline. A verbose and sophisticated library like this could save you a phenomenal amount of time if you’re building a secure production e-commerce platform for a medium-sized business and have a few months to get through the installation and usage learning curve with a sophisticated codebase that incorporates some technologies you might not be familiar with. If you only have a few days or weeks to prototype a proof-of-concept application, this library might be too much to delve into.

For this specific search for an e-commerce React library for a project we only had a few days to work on, we found that the libraries were either too complex to navigate in our timeframe, not well supported/used/documented, or didn’t fit our project constraints. Then we looked for simple react component libraries so we could at least save time on styling buttons, images, etc. We had more luck there, but ended up using the mui/material-ui library we had seen as a dependency for another library we used. This one has 77.8k stars, easy installation, is built only in react, and has incredible documentation where you can copy and paste code snippets for their various components. The takeaway there is that your knowledge of libraries, and tools/sense for searching for new libraries, will grow as you work in a language.

To sum up the external library vetting process:

1. Decide how much time you have to vet external libraries within the timeline of your project.
2. Search for libraries by keyword and potentially by language in GitHub. Sort by most stars and review when it was last updated and the number of open issues.
3. Check if the library meets your project deliverable requirements, the documentation seems to be good, and the complexity of the library doesn’t exceed your project timeline. Additionally, if there is a paid version of the library, make sure the level you’re willing to pay has the functionality you need.
4. If the above requirements are met, take a deeper dive into the documentation. Documentation can be verbose and well-formatted and still be unhelpful. If you think the documentation makes sense, go through the installation steps for the library and try to start getting pieces working.
5. The goal in this process is to find a library that suits your project needs, or abandon the library search and build it yourself if there isn’t one that meets your needs, as quickly as possible. As such, don’t be afraid to abandon libraries quickly. A few hours spent reading and installing a library and then deciding it’ll take too much time to get it up and running, or that you can’t customize/utilize the library in the way you need, is far better than spending weeks trying to use a bad library/navigate nonsensical documentation. Be realistic about your time constraints and how much time you want to devote to learning a new library, and which technologies within that library and its dependencies you know/will have to learn.

Happy coding, dweebs.