IdeaWell

Project ideas from Hacker News discussions.

Parse, Don't Validate (2019)

Original Article

Hacker News Discussion

📝 Discussion Summary (Click to expand)

1. Typed value objects vs. “string‑ly” code
Many commenters argue that wrapping a raw string in a dedicated type (e.g. PhoneNumber, EmailAddress) gives the compiler a guarantee that the value is used correctly and eliminates accidental mix‑ups.

“An explicit type” – jalk
“You can’t pass a PhoneNumber to a function expecting an EmailAddress” – flqn
“If you are not checking that the phone number is 10‑digits … it is absolutely pointless” – JambalayaJimbo

2. The “Parse, don’t validate” principle
The core idea that the author promotes—parse once at the edge, then assume validity inside the system—recurs throughout the discussion.

“Parse, don’t validate” – seanwilson (repeated by many)
“The parsing step is validation but it produces something that doesn’t require further validation” – jghn
“If you put validation logic into all of those functions … why not just parse the phone number into an already validated type and pass that around?” – xboxnolifes

3. Practical trade‑offs: performance, language support, and culture
Commenters weigh the benefits of strong typing against runtime cost, boilerplate, and ecosystem maturity.

“It has a cost at runtime … it’s not like in some functionals languages a non‑cost abstraction” – barmic12
“You can have a lot of boxing/unboxing … a lot of boilerplate” – rorylaitila
“If you want to use a type for a phone number you have to parse it once, otherwise you’ll write defensive code everywhere” – munk‑a

These three themes—value‑object advocacy, the parse‑vs‑validate debate, and the real‑world cost/benefit calculus—capture the main currents of opinion in the thread.

🚀 Project Ideas

TypedSchema Generator

Summary

  • Generates strongly‑typed value objects (e.g., PhoneNumber, EmailAddress, URL) from JSON Schema or OpenAPI specs, embedding validation logic in a single constructor.
  • Eliminates boilerplate, reduces defensive code, and guarantees that only valid instances exist in the codebase.

Details

Key Value
Target Audience Java/Kotlin/C#/TypeScript developers dealing with string‑heavy APIs.
Core Feature CLI + library that parses a schema, emits immutable value classes with parse/validate methods, and optional code‑generation for multiple languages.
Tech Stack Rust (CLI), Kotlin/Java, C#, TypeScript; uses Jackson, kotlinx.serialization, System.Text.Json, and tsc.
Difficulty Medium
Monetization Revenue‑ready: subscription for enterprise features (schema versioning, CI integration).

Notes

  • “Java makes it a pain” (bcrosby95) – the tool removes the need to hand‑write constructors and validation.
  • “Huge pain” (vips7L) – auto‑generation eliminates the repetitive new PhoneNumber(value) boilerplate.
  • “I have to write defensive code” (seanwilson) – with a single parse method, defensive checks disappear from the rest of the code.
  • Sparks discussion on best practices for schema‑driven development and cross‑language code sharing.

ZeroCostValue Library

Summary

  • A lightweight runtime library for Java/Kotlin that leverages inline classes and records to create zero‑overhead value objects with a declarative validation DSL.
  • Provides compile‑time guarantees that only valid values can be constructed, while keeping runtime cost negligible.

Details

Key Value
Target Audience Java/Kotlin teams wanting strong typing without the memory/performance penalty of POJOs.
Core Feature Inline‑class wrappers (value class PhoneNumber(val raw: String)) with a fluent Validator DSL; auto‑generated parse functions that throw ParseException on failure.
Tech Stack Kotlin 1.9+, Java 17+, JSR‑380 (Bean Validation) for DSL, Gradle plugin.
Difficulty Medium
Monetization Hobby

Notes

  • “Java makes it a pain” (bcrosby95) – the library turns Java’s heavy objects into zero‑cost wrappers.
  • “I have to write defensive code” (seanwilson) – once a value is constructed, the rest of the code can assume validity.
  • “Huge pain” (vips7L) – eliminates the need for manual null checks and defensive copies.
  • Encourages discussion on the trade‑offs between inline classes and traditional POJOs.

TypedIngest Service

Summary

  • A web‑based ingestion platform that accepts raw CSV/JSON, validates against a user‑defined schema, and outputs typed data structures and code snippets for Java, Kotlin, Rust, Go, and TypeScript.
  • Centralizes parsing/validation logic at the edge, ensuring downstream services receive only validated, typed data.

Details

Key Value
Target Audience Backend teams, data engineers, API designers needing consistent data contracts.
Core Feature Upload raw data → schema editor → validation → generated typed DTOs + API client code; supports CI/CD hooks.
Tech Stack Node.js (Express), PostgreSQL, Docker, OpenAPI Generator, Rust for performance‑critical parsing.
Difficulty High
Monetization Revenue‑ready: tiered SaaS pricing ($49/mo for small teams, $199/mo for enterprises).

Notes

  • “I have to write defensive code” (seanwilson) – the service moves all defensive logic to the ingestion layer.
  • “Java makes it a pain” (bcrosby95) – downstream Java code receives already‑validated DTOs, eliminating manual checks.
  • “Huge pain” (vips7L) – reduces the risk of mixing up stringly typed arguments (e.g., callNumber(String) vs callNumber(PhoneNumber)).
  • Opens conversation about the value of edge‑processing versus in‑service validation and the role of code generation in modern microservices.

Read Later