This post is part of a series. In today’s post, we’ll create a project from scratch, defining API endpoints to build upon. I’ll demonstrate how to use Ktor to develop a web server, which dependencies to install, and how to structure the project for easy maintenance. There’s a lot to cover, so let’s get started!
Welcome to the first post on the subject of authentication with Ktor. As developers, we appreciate the importance of security, but integrating it smoothly within our backend services can sometimes seem like a daunting task. However, when working with Kotlin and Ktor, the task becomes much more approachable due to concise syntax and flexibility. This series aims to delve into the diverse authentication mechanisms. We will find our way through Basic Auth, Form Auth, to more complex ones like JWT and OAuth. Whether you’re new to Ktor or looking to broaden your horizons, this series will offer practical, hands-on experiences to help you effectively bring security to your backend applications.
Console logging is often perceived as a bad practice, but in specific contexts, it’s quite suitable. Consider a scenario of a workshop where printing output directly to the console enhances transparency and simplifies the project setup. Using a comprehensive logger could lead to unnecessary clutter. However, there’s a downside to directly printing to the console—it makes it challenging to verify the result. Well, at least so I thought until I accidentally stumbled upon this awesome article by Thijs Kaper. Although Spring Boot provides out-of-the-box support for output verification, it’s also possible, and sometimes preferable, to implement it independently. In this blog post, I’ll demonstrate how to create a custom spec in Kotest that you can leverage in your tests. This spec automatically captures console output and provides the result for verification.
Today, I would like to share a quick productivity tip. As developers, we sometimes skip writing extensive tests, particularly when under time pressure. As much as tests are necessary, they can also be tedious to write. For example, due to learning a new testing framework or when dealing with intricate business logic. Furthermore, this task often involves a certain degree of repetitive boilerplate, which can be a considerate discouragement for some developers. In this post, we’ll explore how generative AI saves time and effort without compromising on quality of writing detailed tests.
When managing multi-tenant systems, one common anxiety is that a coding error can unintentionally expose user data. Incorrectly routing a user’s data to the wrong tenant, or even distributing it to another user within the same tenant, is a very real fear. Additional precautions are necessary to safeguard against human errors. Supabase is an open-source platform that offers a viable alternative to Firebase. Similar to Firebase, it provides a frictionless user authentication process. Due to its integration with Postgres, it supports sophisticated access controls at a row level, aptly referred to as Row-Level Security (RLS). In this article, we’ll explore a concrete example of leveraging this feature and provide step-by-step implementation guidelines.
As of now, Stripe’s Payment Links don’t offer the flexibility of adding custom fields beyond those available in the API. The fields that you can directly pass into the Payment Links endpoint are complementary identifiers like prefilled_email or client_reference_id. This post shows some of the workarounds you can use to enrich your payment links with additional custom parameters.