I was trying to reproduce some of the laziness issues described in this old (2016) but very in-depth article at the Well-Typed blog: https://well-typed.com/blog/2016/09/sharing-conduit/
But I'm not able to reproduce them when compiling with -O2 --rtsopts (and using GHCRTS=-M20m to limit the size of the heap so that it fails faster in case of a leak) on GHC 9.6.2.
"By default, an element that causes a request will include its value if it has one. If the element is a form it will include the values of all inputs within it." https://htmx.org/docs/#parameters
Even after enabling the DuplicateRecordFields, NoFieldSelectors and OverloadedRecordDot triad, record update for ambiguous fields remains a pain, often alleviated with lens libraries like "generic-lens".
I might be splitting hairs about the semantics of #HTTP PUT, but there seems to be a slight contradiction in #rfc9110
On one hand, a GET after a PUT should return the exact representation that was set by the PUT.
On the other hand, a PUT "might also cause links to be added between the related resources" which seems to say that the representation might be enriched with extra links.
I generally prefer package-by-feature. But: I also like #API-first development (generating controller interfaces using #OpenAPI Generator for example) and I feel it clashes a little with the package-by-feature approach, because you generate an entire "layer" (the controllers) in one go, and all the results tend to be put in the same package. https://openapi-generator.tech/docs/generators/spring/
How to resolve this apparent tension?