The article points out a „pro“ of returning a response in handlers - but fails to miss any cons.
However there are a few of them. One particularly important one is that the „return response“ variants lack extremely on the observability front - which then in the end leads to services which are hard to run in production.
Eg let’s say I want to measure in my handler what „last byte latency“ is - or at least when the handler pushed the last byte into a tcp socket. With the Go approach it’s not a problem - we can wrap the handler in another handler which does emit metrics.
With the „return response object“ it won’t work easily anymore. At the time the handler returns nothing actually has happened.
The same thing applies for eg tracking the amount of concurrently executed requests to understand resource utilization (and starvation). No issue with the Go variant - hard to do with „function as a service“.
It’s actually rather unfortunate that all Rust frameworks went down the „response object“ route and made it hard to add proper observability.
However there are a few of them. One particularly important one is that the „return response“ variants lack extremely on the observability front - which then in the end leads to services which are hard to run in production.
Eg let’s say I want to measure in my handler what „last byte latency“ is - or at least when the handler pushed the last byte into a tcp socket. With the Go approach it’s not a problem - we can wrap the handler in another handler which does emit metrics.
With the „return response object“ it won’t work easily anymore. At the time the handler returns nothing actually has happened.
The same thing applies for eg tracking the amount of concurrently executed requests to understand resource utilization (and starvation). No issue with the Go variant - hard to do with „function as a service“.
It’s actually rather unfortunate that all Rust frameworks went down the „response object“ route and made it hard to add proper observability.