3 ms·

While I all generally think of a database being a part of full-stack, I'm not so sure that it makes sense to be a prerequisite. A database is just a tool for st

While I all generally think of a database being a part of full-stack, I'm not so sure that it makes sense to be a prerequisite. A database is just a tool for storing data. If all you need is in-memory data, flat file, or even no long-term data at all, I see no reason the requirement of long-lasting data to be a requirement for full-stack. That being said, the more I keep thinking about it, the less useful the term full-stack even feels. Why is front-end + back-end + database (+ other?) the full-stack? Why not also require third-party integrations? What about the hardware? Should the definition of full-stack expand as the options do, or should it stay static at whatever it's original usage was?

mgkimsal 5y ago
"Why not also require third-party integrations" - it almost has to include that anyway, but.. the skill set required to understand and work with third-party integrations is almost certainly going to be a subset of 'front-end' or 'back-end' anyway. Mastery of client side and mastery of server side are distinct enough that those sort of 'what abouts' you raised seem to fall under the broad 'front/back' domains already, no? There's enough virtualization that 'hardware' itself is a somewhat elastic term. However, I've had to deal with 4 different devs in the last few months, all trying to get set up with one of two projects. Both are docker-based. But... "well, I'm on windows... I'm on WSL... I'm on Mac, but M1... I'm on Mac, but Mojave, and this doesn't work..., oh, I can't have 2 things running on the same port?" Unless every single person is on the exact same hardware/OS combinations, having some understanding of 'hardware and OS diffs' and how they may impact you may still be necessary.