I introduced how to achieve soft delete in ZenStack in the previous post below:
Soft delete: Implementation issues in Prisma and solution in ZenStack
The solution appears quite elegant with the help of the access policy in the schema.
model Post {
...
deleted Boolean @default(false) @omit
@@deny(‘read’, deleted)
...
}
In the past month or so, Google managed to piss off two distinct groups of people. The first group who manage domain names, either for their employers or themselves, are hit by a surprise attack from Google’s selling its domain service to SquareSpace. The other group is digital marketers who are forced to switch from Universal Analytics to Google Analytics V4, which is said to be “unbelievably hard to use”.
Since Google has a good tradition of killing products, we can’t help but wonder who’ll be the next. Will it be … Firebase 🤔?
Modern web applications often intensively deal with accepting and storing user-generated data. The interaction can happen by submitting forms, uploading files, or any other form of interactivity. Data validation is crucial to ensuring that the application functions correctly and securely. However, having separate validation logic in different places in the application stack makes the app more costly and harder to maintain.
An ideal solution would be to express the validation rules in a central place (close to where data is defined) and let it take effect in every application layer. In this post, I will demonstrate how to achieve this with the ZenStack toolkit.
RedwoodJS is an opinionated full-stack framework for building modern web applications. It makes some of the most critical decisions for you - like using React for UI development, GraphQL for API, and Prisma for database programming, etc. - so you can stop struggling with choices and focus on building your app.
Regarding authorization, RedwoodJS has built-in support for RBAC (Role-Based Access Control), which can work well for simple apps but can easily hit its limit for complex scenarios. In this article, we'll explore an alternative way of implementing authorization that may surprise you. Instead of doing it at the GraphQL API and service code level, we move it down to the ORM layer.
Having been involved in the development of four commercial SaaS products at my previous company, I've come to realize the multitude of complexities that arise compared to typical consumer products. Among these complexities, one prominent area lies in the intricate realm of permission control and access policies.
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.