Bearer

Relying on third-party APIs? Do you know what is an API Service-Level Agreements (SLA)? How to find them? What to look after?

Find out in our checklist about API SLA for CTOs, CIOs & CISOs

Machine learning (ML) used to be a tool limited to specialized developers and dedicated teams. Now, thanks to many web service providers and approachable tooling, applications can use pre-build learning models and machine learning techniques the same way you would use any web service API.

This is a quick way to test out and benefit from machine learning without having to invest in artificial intelligence, building your own learning models, or shaping your application around ML. To learn more about the ML offering within the big players, read on: https://blog.bearer.sh/machine-learning-api-web/

At Bearer, we are a polyglot engineering team. 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. This post goes into some of the details that caused the need to change languages, as well as some of the decisions we made along the way.

The Google Sheets API is a very powerful service, used by thousands of developers every day. While the API is very well structured and I'm delighted to use it, one part is prettty hard to use: the authentication part.

It's not tied to the Google Sheets API though, as it uses the public OAuth 2.0 authentication framework. In a recent blogpost, I've detailed how to authenticate with the Google Sheets API in 5 minutes, using Pizzly, a tool that I'm actively contributing to.

Read on: https://dev.to/bearer/how-to-integrate-with-the-google-sheets-api-in-2-minutes-569o