Engineers like to solve problems. If there are no problems handily available, they will create their own problems.

— Scott Adams

When asked why I quit a full-time job and devoted all my energy to an open-source project, I gave inconsistent answers: an intended gap period for my career, some business prospect head in the domain, or a change of lifestyle. Today, I sat alone and tried to retrospect on the past seven months of the journey, the superficial reasons receded, and the true cause surfaced — it’s all about the joy of creating new things and has always been.

Vercel is a fantastic cloud platform that stands out from the crowd by its simplicity and excellent developer experience. One reason for its success is the intense focus on full-stack Javascript web apps. However, that doesn't mean you can't deploy a headless service on Vercel.

In this post, let's have fun building a secure database-centric RESTful API with Express.js, Prisma, and ZenStack, and deploying it onto Vercel. We'll also leverage the new Vercel Postgres offering for data persistence.

Have you ever built a product from scratch? If so, I bet you definitely experienced the trade-off between the design quality and time to market. In fact, you might have to struggle with it more than you expected. In Shopify's practice Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity, they get the conclusion below:

In conclusion, no architecture is often the best architecture in the early days of a system. This isn’t to say don’t implement good software practices, but don’t spend weeks and months attempting to architect a complex system that you don’t yet know. Martin Fowler’s Design Stamina Hypothesis does a great job of illustrating this idea, by explaining that in the early stages of most applications, you can move very quickly with little design. It’s practical to trade off design quality for time to market. Once the speed at which you can add features and functionality begins to slow down, that’s when it’s time to invest in good design.

Most web apps only consist of two things: a frontend UI and a backend transaction system. And most of the time, the "backend" is just a glorified intermediary that reads from and writes to a database. So a naive question is raised: why do I need that intermediary? Why can't I just expose the database directly to the frontend?

Yes, you can! PostgREST is built exactly for that purpose.

When I quit Microsoft and joined the startup company in 2015, the first thing I learned is the concept of Microservices. It was touted as the future of software development, promising increased scalability, flexibility, and resilience. It seems everyone was jumping on the bandwagon, even the fledgling startups despite the inhere challenges involved. There was a joke about it:

There’s a thousand-line program here, we’ve got to break it to make it down into 10 hundred-line programs.

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.

Almost all the SaaS now is collaborative, from the originator Salesforce to the newly emerging one like Notion. To make it collaborative, technically, we need to build the foundation to support tenant isolation with an access control policy. A classic challenge here is striking a balance between app security and dev productivity. ZenStack’s access policy provides an innovative way to achieve that balance using the declarative schema.

I still recall the day that my co-founder approached me with his plans and asked if I wanted to join him. Usually, when I'm presented with a similar opportunity, the first question I usually asked is:

What makes this thing different

But this time the question I asked was:

Why do you want to build it

Why? Because of the book “Start with WHY”. This simple yet powerful question uncovers the true motivation behind a project and is what truly inspires people.

Implementing security is one of those tasks in software engineering, which we all know its importance, but often don't spend enough energy to do it right. Who wants to build features that users can't see? However, the uneasy feeling will just keep haunting you, and someday you'll pay the price for your negligence. Data breaching is one of the best ways to ruin customers' trust and devastate a business. So better be a responsible programmer and implement the necessary measures from the beginning. But how?

No matter what programming language you are using, one common suggestion you all probably hear is that:

Don’t use switch statements

Besides people usually forgetting to add the break statement, the more profound reason is that developers often avoid using special cases in their code. Instead, they prefer to use more flexible and powerful constructs such as polymorphism or dictionaries.