I decided to stop using Twitter, but for my own content and supporting Ukraine against its barbarian invaders, I understood the contemporary media landscape was quite fragmented. I bet on Mastodon, Bluesky, and LinkedIn. My flow is the following: when I read a piece I find interesting, I schedule it for publication.

When exposing an application to the outside world, consider a Reverse-Proxy or an API Gateway to protect it from attacks. Rate Limiting comes to mind first, but it shouldn’t stop there. We can factor many features in the API Gateway and should be bold in moving them from our apps. In this post, I’ll show how to implement authentication at the Gateway API stage.

Lots of companies are eager to provide their identity provider: Twitter, Facebook, Google, etc. For smaller businesses, not having to manage identities is a benefit. However, we want to avoid being locked into one provider. In this post, I want to demo how to use OpenID Connect using Google underneath and then switch to Azure. OpenID Connect The idea of an authorization open standard started with OAuth around 2006. Because of a security issue, OAuth 2.0 superseded the initial version.

Recently, I designed a simple metrics-tracking system. A Python script queries different providers' APIs for metrics, e.g., Twitter, GitHub, etc. The idea is to run this script each day, store them in Google BigQuery and provide an excellent data visualization in Google Data Studio. I’m a big fan of automation, so I’m using GitHub Actions. Accessing Google Cloud with a Service Account I query the different APIs with different Python libraries.

I started developing on the Java EE platform 15 years ago (yep, you read that right). At that time, the only way to authenticate in a webapp was through a callback. Recent Java EE versions offer alternatives. This post aims at describing both, how they work and their respective benefits.