Database for storing data; application code for implementing business logic - the distinctions seem straightforward. Yet, after so many years of evolution, modern (relational) databases are quite capable of running "logic" - extensions, stored procedures, triggers, etc.
If you are a developer familiar with RESTful APIs, you might have heard of OpenAPI. It is a specification for describing RESTful APIs in a format readable for humans and machines. Building a public-facing OpenAPI includes three tasks:
In this post, you'll see how to accomplish all these tasks and build a database-centric OpenAPI service, secure and documented, within 15 minutes.
Although still experimental, Client Extensions are one of the most exciting features introduced in recent Prisma releases. Why? Because it opens a door for developers to inject custom behaviors into PrismaClient with great flexibility. This post shows a few interesting scenarios enabled by this feature, together with thoughts about where we should set the boundary to avoid overusing its power.
One big piece of conventional wisdom for software operation is "never expose internal-facing services to the public", and databases (especially SQL databases) fall into that category. It's good advice because data stored in them are usually highly sensitive and indispensable to most systems' proper running. Investigations with honeypots showed that publicly open databases are discovered within hours after they become active and start getting attacked within a day. What's scarier than this is you often don't even know you ever had a data breach.
Soft delete is a common requirement for SaaS products. But the current solution in Prisma has certain issues. Let's see how ZenStack solves it.
Web development's landscape is ever-changing. We started from bare metal machines serving static HTML pages, to the rise of the LAMP stack, then the MEAN stack, and now the JAM stack.
Backend development is difficult for people who come entirely from a frontend background. The languages, frameworks, and tools differ, but more importantly, the frontend and backend systems have very different principles. Fortunately, a new generation of libraries and services is trying to fill the gap and simplify coding a backend by …, not coding it at all.
No, you didn’t read it wrong. It’s PostgREST, not Postgres 😄. Although the naming is prone to misreading and not friendly to search engines, it perfectly reflects what the project does - it adds a RESTful API layer to PostgreSQL. This post is a quick introduction to what it is, how it works, and what kind of scenarios it fits best.