Posterior a buscar en varios repositorios y sitios de internet finalmente nos encontramos con la resolución que te mostraremos ahora.
Solución:
Gran pregunta. Hago una arquitectura inspirada en MVC en capas.
BACKEND
Modelo (formato) los datos en el backend de acuerdo con su orden ‘natural’. En otras palabras, sigo la organización interna de los datos. Esto se debe a que mis API a menudo son utilizadas por varios clientes que cambian o evolucionan, y volver a escribir la API varias veces o tener varias versiones requiere demasiado tiempo para mantenerla.
Esto no significa que deba enviar el contenido de la base de datos con cada llamada a la API. Definitivamente, debe reducir el modelo de datos para cada llamada, pero debe ser una versión reducida del modelo de datos backend (“natural”), no una estructura de datos personalizada para una vista particular.
INTERFAZ
En la interfaz, tengo un controlador estrechamente acoplado que recibe los datos del servidor y los transforma en el modelo que se ajusta bien a una vista determinada. Dependiendo de la tecnología utilizada en el lado del cliente, puede haber soporte de biblioteca para esto (por ejemplo, AngularJS para javascript/HTML Swing para Java, WPF para C#, etc., etc.)
Encuentro que esta arquitectura da como resultado una separación limpia y una alta productividad.
Realmente depende de la naturaleza de la transformación que necesita hacer con sus datos y también de la frecuencia con la que se necesita un determinado tipo de transformación.
Haría que el backend devolviera los datos sin procesar de forma predeterminada, pero para formatos de datos particulares que a menudo requiere el frontend, haría que el punto final del backend aceptara un parámetro de solicitud que le indica al backend en qué formato debe devolver los datos.
Me ocupo de esto con otro desarrollador con el que trabajo. Le encanta trabajar en SQL y básicamente hace todo lo que hay allí, lógica de negocios, formateo, etc. Me molesta muchísimo. En mi opinión (y al menos para las aplicaciones en las que trabajamos), SQL es para manejar el almacenamiento y la recuperación de datos, el código de servidor/código de cliente es para presentar los datos al usuario y manejar las interacciones del usuario con esos datos.
Sin embargo, esto no se limita solo a SQL (u otro motor de base de datos) frente al código de su aplicación. En los casos en que el código del servidor es más una API, entregando datos a una aplicación web pesada de javascript, se aplica lo mismo. La API no sabe qué podría querer hacer la interfaz de usuario con los datos, el propósito de la API debe ser entregar datos sin procesar y dejar que el código de presentación/javascript se ocupe de formatearlos de la manera requerida.
Estoy seguro de que hay excepciones a esto, pero esa es la regla general que me gusta seguir. El formateo está en el ámbito de la presentación, no en la lógica empresarial ni en la recuperación de datos. Mantenlo ahí.
EDITAR: releí tu pregunta y creo que me perdí un punto sutil pero crucial. Si tiene un constructor o modelo o lo que sea que espera una entrada en un formato particular, sería conveniente realizar ese formateo/conversión en SQL para evitar el paso adicional de convertir los datos antes de poder usarlos. Sin embargo, dependerá en gran medida del problema que se intente resolver y de los detalles de dónde provienen los datos y dónde se utilizarán.
Valoraciones y reseñas
Recuerda algo, que tienes el privilegio interpretar tu experiencia si acertaste tu atasco a tiempo.