Hacker News Reader

Comment by _1tem | Hacker News Reader

As a full stack dev that runs their own SaaS with thousands of users in production, sometimes I get a very pleasant reminder of how many problems I am blissfully unaware of just because I decided not to build an SPA or use JS frontend frameworks. It never occurred to me that I need such a thing as Zod/ArkType - first time hearing of it, and I have no use for it.

It boggles my mind how much effort and complexity and tooling goes into building an SPA. Entire classes of problems simply don't exist if you choose not to build an SPA. Meanwhile, I use the browser as designed: with full page reloads, backend development only, and occasional reactivity using a backend-only framework like Laravel Livewire. Everything is so simple: from access control to validation to state management. And yes, my app is fast, reactive, modern, SEO friendly, and serves thousands of users in production.

View on HN

I worked on two large projects that use Zod and Protobuf to ensure schema evolution goes well with 5+ teams. Even if you have a lightweight frontend, it makes sense to use something that validates the schemas in the backend.

In the end you'll have a schema somewhere. Maybe defined in the database system, maybe defined in the models of an object-relational mapper. Since defining the schemas in database system or using object-relational mappers can cause very difficult problems in large projects we do not use it and use Zod and Protobuf instead. While I think you could even replace Protobuf completely with Zod or something similar.

There is the British Post Office scandal [1] around an IT system called Horizon (the legacy system in this case). After reading about the details I'm pretty sure something like Zod (I mean any schema validation) would have contributed to prevent this scandal. They even mentioned the lack of using a schema in the technical appendices in the court documents of the group legal action [2].

[1] https://en.wikipedia.org/wiki/British_Post_Office_scandal

[2] https://en.wikipedia.org/wiki/Bates_%26_Others_v_Post_Office...

Zod has nothing to do with SPAs and isn't just a frontend tool. Do you not validate inputs in your code?

Laravel/Livewire handles it. I have no idea why something like Zod should be the concern for a high level application dev. For a framework dev, sure

Well zod is for typescript, not laravel/livewire

Yeah, it's very useful to validate schemas at compile-time and runtime. It prevents several different problems to occur.

Lately, I used code agents a lot, and having typescripts types infered from Zod schemas allows me to catch errors when the large-language model generated slightly wrong code.

In that case, your objection seems to be to light weight or minimal frameworks rather than SPAs on this point. There are plenty of minimal backend frameworks for Node (and Python, and others) that can be and are used to build traditional "load a page for every interaction" applications, and Zod or something like it would be useful for those since minimal frameworks often don't include validation. Zod isn't exclusively for SPAs or even web applications. It's schema validation, which is useful in many domains.

Zod is basically the standalone version of Laravel's validation (https://laravel.com/docs/12.x/validation#quick-writing-the-v...) so I'm not sure what exactly you're objecting to.

Unless you're saying

a) You don't validate user inputs b) You prefer validation to be bundled with the framework rather than having a choice

Entire classes of problems simply don't exist, if you also close your eyes.

Well how do you do server-side validation?

Because now I have the impression that you're just defensively writing a bunch of if-statements. Or worse, you rely on html client-side form validation only.

Any good backend framework (Laravel, Django, Livewire, Rails) does server side validation out of the box without me as a developer needing to manually pass around JSON objects and continually checking their shape. The boundary between user input and backend code is well defined and border checks are easy.

> manually pass around JSON objects and continually checking their shape

Well Zod is a library that's typically used on the boundary.

I don't know why you're assuming stuff about a library that you've never used. No one would continually check their shape once it's validated at the api boundary.

We have an enormous number of backend-only Zod schemas that are used as part of our data pipelines; so it doesn't seem like something that only exists to solve SPA problems.

If it’s backend only why do JSON shapes need to be continually checked? Can’t you serialize higher level classes or use the database?

If a JSON shape is maintained by another team, e.g. how can you know they did not change the shape without speaking with them? You could instead validate the schema and log the errors and get notified by the errors and then change your client code. This also means your client code does not need to know about the details of the database.

Use the database? As in just throw user input straight into the DB without so much as checking its length to make sure it fits? Just let it error out? No sanitization, nothing?

What's your SaaS? I would like to check out your use case that allowed you to build a great product without SPA.

Basecamp and Hey are $100m+ software companies that use Ruby on Rails without an SPA.

Yes, and it actually works. I use something like htmx or fixi [1] for my frontends of side-projects. Alternatively, I could also use laravel livewire, I even argue you could use them for large-scale projects like ERP systems. I even re-build small parts of a large ERP system including the design system implemention using htmx. No need for react or similar things, if you know HTML and CSS well and are a bit disciplined.

But once you don't use ORMs or have a non-monolithic architecture, you need something to validate your schema.

[1] https://github.com/bigskysoftware/fixi

Reply on news.ycombinator.com