3 ms·
1. HTTP stuff should be an adapter for transport agnostic business logic. You want to be able to support gRPC or whatever later without disturbing the internal
by tlarkworthy 5y ago
1. HTTP stuff should be an adapter for transport agnostic business logic. You want to be able to support gRPC or whatever later without disturbing the internal domain functionality.
2. this article is about using HTTP servers to provide general purpose concurrency handling in Java, so your point is off topic. Of course if you are writing a HTTP server you need HTTP server code, thats kinda obvious but not what we are talking about. We are talking about: if you need concurrency, should you bring up a HTTP server?
- Supermancho 5y ago> HTTP stuff should[1] be an adapter for transport agnostic business logic. There's no reason to assign methodology or context to a software process. It's useful or it is not, for qualities of utility that are unique to use cases. With such soft terms as "adapter" and "business logic" you can rationalize anything anyway, so I'm not sure that's a compelling statement on it's face. Across various languages, this methodology has been used since the 90s. It's "an oldie but goodie". [1]"should" is a weasel word, that typically is a stand-in for "I believe this". It's unlikely that I subscribe to your specific belief.
- melony 5y agoYou are throwing the past two (three?) decades of research and development in software engineering if you insist on tightly coupling code structure to implementation and rejecting design patterns.