> This sounds good in theory, but parsing JSON and then serializing it N times has a real performance cost. It's not just the serialization cost but latency (h

> This sounds good in theory, but parsing JSON and then serializing it N times has a real performance cost. It's not just the serialization cost but latency (https://gist.github.com/jboner/2841832 https://gist.github.com/jboner/2841832) as well, every step of the process adds latency, from accessing the object graph, serializing it, sending it to another process and/or over the network, then building up the object graph again. The fashion in .net apps used to be to separate service layers from web front ends and slap an SOA (the previous name for micro-services) label on it. I experimented with moving the service to in process and got an instant 3x wall clock improvement on every single page load, we were pissing away 2/3rds of our performance and getting nothing of value from it. And this was int the best case scenario, a reasonably optimized app with binary serialization and only a single boundary crossing per user web request. Other worse apps I've worked on since had the same anti-pattern but would cross the service boundary dozens/hundreds/thousands of times and very simple pages would take several seconds to load. It's enterprise scale n+1. If you want to share code like this then make a dll and install it on every machine necessary, you've got to define a strict API either way.