4 ms·
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 blissfull
by _1tem 1y ago
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.
- giorgioz 1y agoWhat's your SaaS? I would like to check out your use case that allowed you to build a great product without SPA.
- _1tem 1y agoBasecamp and Hey are $100m+ software companies that use Ruby on Rails without an SPA.
- tauchunfall 1y agoYes, 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 https://github.com/bigskysoftware/fixi
- SebastianKra 1y agoWell 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.
- _1tem 1y agoAny 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.
- dhruvrajvanshi 1y ago> 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.
- zachrip 1y agoZod has nothing to do with SPAs and isn't just a frontend tool. Do you not validate inputs in your code?
- _1tem 1y agoLaravel/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
- ramon156 1y agoWell zod is for typescript, not laravel/livewire
- tauchunfall 1y agoYeah, 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.
- justarobert 1y agoIn 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.
- hdjrudni 1y agoZod is basically the standalone version of Laravel's validation (https://laravel.com/docs/12.x/validation#quick-writing-the-validation-logic 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
- dimitrisnl 1y agoEntire classes of problems simply don't exist, if you also close your eyes.
- andrewingram 1y agoWe 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.
- _1tem 1y agoIf it’s backend only why do JSON shapes need to be continually checked? Can’t you serialize higher level classes or use the database?
- tauchunfall 1y agoIf 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.
- hdjrudni 1y agoUse 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?
- tauchunfall 1y agoI 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 https://en.wikipedia.org/wiki/British_Post_Office_scandal [2] https://en.wikipedia.org/wiki/Bates_%26_Others_v_Post_Office_Ltd https://en.wikipedia.org/wiki/Bates_%26_Others_v_Post_Office...