The concept of instrumentation often refers to tracing where events happen in an application. Many application performance monitoring (APM) tools use it to provide metrics on the inner workings of your application. But sometimes, all you really need are details about API calls.
Note: This is Bearer's monthly newsletter. Subscribe below to get it in your inbox. I hope you are doing well with this never-seen-before-worldwide-lockdown. The whole Bearer team is locked down as well, but still improving your beloved product! We have a lot of updates and awesome new features for you to explore today. Here is a short overview to get you started!
Modern applications aren’t built in silos. They rely on the features of other applications. This reliance can come in the form of open-source libraries, access to a wealth of data, or complex features distilled down into a consumable API. Incorporating third-party dependencies into your own project can be challenging. It comes with the benefits of faster development, and the downside of reliance. There is a relationship that happens when using a dependency.
In Ruby, like in most languages, an exception is a way to convey that something went wrong. While some languages only use exceptions for truly exceptional circumstances, like run-time errors, Ruby uses exceptions for a wide variety of errors and unexpected results.
Whether you're making API calls from Node.js or in the browser, connection failures are going to happen eventually. Some request errors are valid. Maybe the endpoint was wrong or the client sent the wrong data. Other times you can be sure that the error is the result of a problem with the connection to the server or one of the many hops in-between. While API and web service monitoring can inform you about the problem, a more active solution can take care of it for you.
By nature, APIs are meant to be used. Even if all of your users are internal, security problems can still arise. To help with this, we've assembled a list of best practices to keep in mind when securing and locking-down an API or web service.
The ecosystem around making requests in Node.js applications is huge. With countless libraries available, it can be helpful to understand why they exist. This helps to improve your understanding of Node.js as a whole, and makes choosing an HTTP client easier. In the first post in this series, we looked at creating servers using Node's http module. In this post, we will explore making a request using the http.request method and handling the response.
Using Node.js on the web generally involves a server framework, like Express, Hapi, or Koa. These make working with the underlying HTTP support easier. Sometimes you need the full power of a framework, but in other cases that can be overkill. In this article, we'll ignore the benefits of a framework and look at the underlying features of Node's HTTP module and how you can use it to create a web server. In future articles, we'll examine other features of the HTTP module.
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.
