5 ms·
> You don't start by choosing an architecture. It really depends. Some patterns might be specific to problem domains, but a layered architecture applies pretty
by nuerow 5y ago
> You don't start by choosing an architecture.
It really depends. Some patterns might be specific to problem domains, but a layered architecture applies pretty much across all types of software projects.
Between defaulting to a layered architecture and just mindlessly piling up ad hoc decisions without any coherent criteria, a layered architecture always wins.
- munk-a 5y agoHonestly - a layered approach ends up paying dividends even if used solely for code organization. Options like microservices and event frameworks work quite well when using layered approaches internally. Basically, I've seen SQL in controllers and I don't ever want that again.
- keithnz 5y agodepends, some systems are such that all they are doing is pumping SQL results into JSON, in that case, I don't want to see some general purpose programming language in the controller. Which is kind of the idea behind https://postgrest.org/ https://postgrest.org/ ( written in haskell if anyones interested )
- radicalbyte 5y agoIf all you're doing is pumping SQL into json, you should either be generating code, or if you don't care about performance using a dynamic language with meta-programming techniques such that you write almost 0 code to achieve your results.