3 ms·

Sure, but it escalates quickly. Logging goes from `log.Println("the thing happened")` to structured logging via an API very easily. Adding Postgres is a no-bra

Sure, but it escalates quickly. Logging goes from `log.Println("the thing happened")` to structured logging via an API very easily. Adding Postgres is a no-brainer. Totally agree. But should you architect the database properly? It's going to be tricky to normalise data later, maybe we should start with properly normalised tables now, instead of jamming everything into a jsonb field? Versioning, sure, but does every API need a version? If so, shouldn't we write some standard code for versioning all the things? Should the CICD process version the system automatically? Talking of which, we should set up the CICD. There's a rabbit hole. These things are all good, definitely worthwhile, but where do you draw the line? If we spend a couple of days doing X, then it becomes worthwhile spending a couple of days doing X+1, and so on. The author drew the line here. But that's not the only place you can draw the line. You can draw it a few paces back too. There's always a temptation as a techie to add a couple of days now to save a couple of weeks or months later. That may not be the right commercial decision.

scott_w 4y ago
The detail you're going into are the YAGNI part. Yes, you'll get those eventually, but you deal with _those_ problems later. Log to a file right now and switch to DataDog, Papertrail, etc. later on. Add /v1/ now, worry about integrating CI/CD into that later, when breaking changes means you actually need to worry about using versioning. I'd think it's implied that you just normalise the tables. It's really not hard to build and use a normalised database. I was doing this in my first months as a junior developer, so I'd expect an engineer with any seniority to be able to do it. If you're asking: "should we model the domain perfectly?" then my answer is a simple "model the domain as you understand it _today_." YAGNI is not "write shitty code" but "don't add things you don't need right now." Again, if adding /v1/ into your first URL string or configuring your logging takes "a couple days" each, then I'm going to have serious concerns.

scott_w 4y ago

The detail you're going into are the YAGNI part. Yes, you'll get those eventually, but you deal with _those_ problems later. Log to a file right now and switch to DataDog, Papertrail, etc. later on. Add /v1/ now, worry about integrating CI/CD into that later, when breaking changes means you actually need to worry about using versioning. I'd think it's implied that you just normalise the tables. It's really not hard to build and use a normalised database. I was doing this in my first months as a junior developer, so I'd expect an engineer with any seniority to be able to do it. If you're asking: "should we model the domain perfectly?" then my answer is a simple "model the domain as you understand it _today_." YAGNI is not "write shitty code" but "don't add things you don't need right now." Again, if adding /v1/ into your first URL string or configuring your logging takes "a couple days" each, then I'm going to have serious concerns.