When it comes to monitoring third-party APIs and web services, what you monitor is as important as how you monitor. Data is useful, but actionable data is where the true value is. Below we've listed the most common and valuable metrics to monitor when relying on third-party API integrations and web services.
When you interact with a REST API, are you making calls directly or are you using a client from the API provider? Many APIs now provide clients, wrappers, or SDKs. These terms all mean the same thing in this context. What happens if the API you are using doesn't offer a client? Do you even need one? Is there any benefit? In this article, we will explore some of the reasons you may want to build one.
GraphQL is a query language for APIs and a set of tools that enable sending and processing queries. While originally developed at Facebook, it has since grown beyond the social network's specific use case. Essentially, the client describes the type of data they want, and the server delivers only that data. At Bearer, we use GraphQL internally to drive our dashboard.
When working with APIs you may come across the term REST or RESTful. REST stands for Representational State Transfer. In essence, REST is a set of recommendations that an API can adhere to. This makes designing the API easier and using the API more predictable.
API has become one of those catch-all terms that developers throw around without really considering the context. On any given week, you will come across discussions like "How to use the Twitter API", "New framework X is great because it has a low API surface", and "Best practices for building an API." Is an API a data source? Is it a service? Is it a way to call native functionality? The truth is, in modern software development it can mean any of these things.
Your application is running smoothly. Tests have passed. Suddenly you start to see 429 error responses from an API. As the name implies, you have made too many requests and your application has been rate limited. The 429 (Too Many Requests) error is an HTTP status code that often occurs when you've hit a request limitation of an API.
Out of the box, Node.js offers the http library for making requests, but it isn't particularly user friendly and requires some customization before it can be easily used. As a result, a large ecosystem of third-party libraries have emerged to make AJAX and HTTP requests easier. Some offer cross-platform (browser and Node.js) support, while others focus on bundle size or developer experience. With some many options, how do you choose?
Javascript's built in Error provides useful information, but can often feel lacking in clarity. One-size-fits-all is great for the language, but we can do better in our own apps. That's where custom errors come in.
Working on the web means coming into contact with HTTP responses. Whether you spend your time primarily on the client or on the server, you're likely familiar with the popular ones like 200, 404, and 500. While memorizing all the codes using cat memes as a mnemonic can be helpful, let's dive deeper into what some of the most common codes mean.
Welcome to Part 2 in our series on building your own circuit breaker in Node.js. In Part 1, Building a Circuit Breaker in Node.js, we built a starter version that handles the core states of a circuit breaker. In this article, we will add configurability, manual overrides, and fallback request support. You can find the complete code for each example here.
