4 ms·
Spec-first is my preferred approach these days, but I had to grow into it. It didn't make sense early on until I'd written the same boilerplate 100s of times an
by RadiozRadioz 2y ago
Spec-first is my preferred approach these days, but I had to grow into it. It didn't make sense early on until I'd written the same boilerplate 100s of times and realised how much time I was wasting.
The upfront cost is higher than the 10 lines it takes to make a working FastAPI app, but once you're past that it becomes a huge timesaver. It's an investment that pays dividends, so definitely for the patient programmer with a long-term view. Not to mention the automatic improvement in API consistently.
I worry slightly about AI completion generating all the code-first boilerplate before people give spec-first a try. It's the same speedup, but with none of the determinism or standardisation.
- dtkav 2y agoFor me it was two things: - collaborative live API design/review with rapid iteration. - developing automation on openapi specs to help teams avoid making backwards compatibile changes. It is much easier to catch things in design. spec-first is probably most useful for large public APIs.