Did you know that you can use Bearer with serverless functions? While serverless, or cloud functions, might not be your first choice for making API calls they can be a great way to proxy API requests or even act as a lightweight API gateway. They also offer a great way to bring some of the benefits of Bearer into the Jamstack. The set up process is similar to installing the Bearer Agent into a traditional app, but there are a few things to watch out for.

At Bearer, the whole team is focused on helping developers that rely on third-party APIs. In 2019, our engineers developed a solution that eased the integration with any API that uses OAuth as the authentication method. By handling both the authentication strategy (with refresh tokens) as well as proxying the request, it saved hours of engineering time when working with API integrations.

Offsites are a big part of remote teams. They allow everyone to socialize, connect more deeply with coworkers, and help build shared experiences and empathy. Even if video calls are a great tool to share information, they can be tiring. It's too easy to miss non-verbal cues. Chance encounters over coffee never happen, and we don’t always experience the same personal connections that come from small-talk.

Python is in the midst of a resurgence. It never went away, but usage now grows like never before. With machine learning developers and data scientists relying on Python, much of the web development ecosystem around the language continues to grow. One aspect that affects all three of these specializations is the powerful benefits of APIs. Pulling in data, and connecting to external services, is an essential part of any language.

Note: We sent this monthly newsletter on July 7th 2020. Subscribe below to get this newsletter in your inbox. Today, we are releasing major updates to Bearer. They include a new dashboard, a rebuilt navigation, and improvements to many of our existing features. Each improvement has been designed based on your feedback and with your developer experience (DX) in mind. Here’s a short overview.

Bearer is shedding its winter coat. As we stayed safe at home during the COVID-19 crisis, it gave us the opportunity to think about our vision for the API Monitoring industry. Today, we are releasing a brand-new dashboard, a rebuilt navigation, and improvements to many of our existing features. But one change is quite big, as it is changing one of the core features of our product. We have completely rebuilt the way API call logs are managed in Bearer.

At Bearer, we are a polyglot engineering team. Both in spoken languages and programming languages. Our stack is made up of services written in Node.js, Ruby, Elixir, and a handful of others in addition to all the languages our agent library supports. Like most teams, we balance using the right tool for the job with using the right tool for the time. Recently, we reached a limitation in one of our services that led us to transition that service from Node.js to Rust.

APIs are everywhere within your organization. Many may be internal, but we’re willing to bet there are many third-party web services and APIs that your business depends on too. Keeping track of them all, and ensuring that your team chooses the best APIs for their needs can be a challenge. In some cases, your organization may be using an API they don’t even know about. The solution to this “web of APIs” is to apply the concept of API governance to your API dependencies.

Webhooks run a large portion of the "magic" that happens between applications. They are sometimes called reverse APIs, callbacks, and even notifications. Many services, such as SendGrid, Stripe, Slack, and GitHub use events to send webhooks as part of their API. This allows your application to listen for events and perform actions when they happen. In a previous article, we looked at how to consume webhooks with Node.js and Express.

APIs are stable, until they aren’t. We talk about that often at Bearer. If you control the APIs, it gets easier, but with third-party APIs and integrations it can be more difficult to predict when an outage or incident is about to happen.