Validate data at the boundary
Check input once, where it enters the system, so the rest of the code can trust it.
Sample post. Replace it with your own writing.
The posts on this site are Markdown files that I type by hand. Hand-typed data is wrong sometimes: a missing title, a date that is not a date, a tag spelled two ways.
One check, at the edge
There are two places to deal with that. Every page could defend itself against bad data, or one schema could check each file as it is loaded. This site does the second.
| Approach | Where the checks live | What a mistake does |
|---|---|---|
| Defend everywhere | In every page and component | Shows up as a broken page, if anyone notices |
| Validate at the boundary | In one schema | Stops the build with the file name and the reason |
What it buys
Inside the boundary, code gets simpler. A function that receives a post does not ask whether pubDate is really a date. The type says it is, and the schema made the type true.
It also gives defaults one home. A post that does not state its visibility is private. That rule is written once, in the schema, and not repeated in each page that lists posts.