Testing uptime, response time, and other performance metrics in applications can take a few different shapes. One common technique is an approach known as synthetic monitoring. This form of performance monitoring doesn't rely on real users interacting with a service, and instead uses automated tools to mimic interactions. Then, the results are recorded and parsed just like other solutions.
Some APIs provide data we benefit from. Others are hooks into an ecosystem that our users find valuable, and others provide features that are difficult to build. What happens when we need access to data that users expect, but an API doesn’t exist? Maybe you’re building an automotive application that would benefit from pulling driving statistics from the user’s car, but the manufacturer’s API is private.
FinTech isn't new, but the reach of its usefulness continues to spread into unexpected areas. One such area is card issuing. Card issuing is the ability of financial institutions to issue debit or credit cards—either physical or virtual. This might not seem like much, but when combined with new business needs and consumer trends we start to see interesting use cases crop up.
Measuring performance in Node.js applications can sometimes be a challenge. Do to the nature of the event loop and asynchronous code, determining the actual time a piece of code takes to execute requires tools built into the platform. First added in Node.js v8.5, as stableas of v12, the Performance Measurement APIs are stable and allow much more accurate monitoring than earlier implementations.
Cutting-edge applications in the travel industry heavily rely on third-party APIs and web services. Take TripActions: the corporate travel management software connects to the United Airlines API, the Southwest Airlines API, and the Lufthansa Group API to import their content like flight schedules and fares. Likewise, it connects to human resources APIs (Namely, BambooHR), finance APIs (Expensify, Spendesk), travel services APIs (VisaHQ, Stasher), and more.
If you work in the ecommerce industry, you know that every part of its value chain has been eaten by software: from product sourcing, inventory management, warehousing, online shopping, marketing operations, order management, payment processing, shipping, up to tax management. Today’s state-of-the-art ecommerce software is connected to countless other services. How? Through APIs. Take a random online store using Shopify, which empowers over 1,000,000 merchants in 175 countries.
How many third-party APIs is your application consuming? All modern FinTech companies rely on external APIs to run their business. Take Robinhood for instance: the famous investment application is using the Plaid API to connect to its users’ bank accounts, the Xignite API to get financial data, and the Galileo API to process payments. That is only the beginning. The essential parts of their service could not run without consuming third-party APIs.
Networks are unreliable. Third-party dependencies, like APIs, are unreliable. This is why we build resiliency into our applications and services. Most prep work is focused around HTTP requests, but an aspect of them that is often overlooked is timeouts.
When you rely on a third party API for your application's features, it is important that you can reliably expect them work. Knowing that their uptime will be consistent, or greater than your own, and knowing that their support will be available if you identify a problem, can go a long way in making your choice of APIs easier. In this article we'll look at the Service Level Agreement, or SLA, and how it protects both you and the provider in the event of an outage or problem.
Integrating with APIs can be challenging. Each with its own documentation format, SDK patterns, and authentication quirks. Once you get the integration up and running, the harder step is testing and debugging any problems. This part can be exploratory—before you finish building—or as part of problem resolution.
