Premature optimization comes with its own set of issues though. Suppose you go for the poison encoder route, to avoid creating some intermediate data. You’ve now tied your model to one very specific representation of JSON. What if you want an additional API endpoint where you serialize users differently? You’re out of luck, there can only be one implementation of a protocol per struct. There’s more on this in a nice blog post here: JSON Views in Phoenix | RokkinCat
Functional programming generally produces a lot of intermediate data, but since this is known, the BEAM (and other functional platforms) are built around handling this well. Immutable data means that very little actually needs to be copied, because you can point to a lot of the same data you were already pointing too since you know it won’t ever change. Garbage collectors are written to efficiently handle this kind of workload, and so on.
At the end of the day, you don’t want to make architectural decisions about how you relate your view layer to your modeling layer on the basis of what might gain you a couple of microseconds within a request that is already at a minimum gonna be several milliseconds.
