Es muy común que un frontend no reciba una respuesta con la estructura que necesita y deba ajustarla; explico este punto con un escenario:

Ejemplo: El color favorito del usuario

Tu empresa cuenta con un departamento de frontend, otro de backend y el cliente desea mostrar en el perfil el color favorito que seleccionó el usuario al registrarse.

Tu equipo cuenta con un servicio web "GET user/[id]" para obtener la información del perfil desde hace mucho tiempo y para cumplir con la funcionalidad, el backend te entrega otro servicio web "GET color/[userId]" para obtener el color.

Nadie del equipo de frontend le habla al equipo de backend, resuelven la tarea realizando 2 llamadas para obtener el perfil.

Llega el día del Review, el cliente nota una demora extraña, el frontend justifica que necesitó realizar una llamada adicional y finalmente el backend dice:

Me hubieran dicho y les incluía el color en el servicio del perfil

Y aclaro que esto no es obvio; ya que, muchas veces se evita modificar un servicio para no afectar otra funcionalidad. Dejando fuera del escenario las pruebas unitarias y soluciones alternas dentro de la arquitectura del frontend.

No todo es color de rosa

Con el ejemplo anterior, podemos ver claramente que la falta de comunicación provoca problemas de performance y código innecesario, lo que conlleva a más bugs.

Tan solo con acercarte, enviar un mensaje o un correo al equipo de backend puedes evitar estas situaciones.

Por otro lado, hay casos que no tienes manera de ajustar la respuesta; por ejemplo, si obtienes el perfil de alguien en facebook, no le dirías a una empresa tan grande para ajustar su respuesta.

Al contrario, ellos tienen una estructura muy buena y ellos se aseguran que te servirá (en la mayoría de casos).

Comunicación Asertiva

De igual forma, hay casos en los que alguno del equipo de backend, arquitectura, diseño y todos los circundantes a tu campo; no visualizan la solución.

Aquí entra en funcionamiento tu conocimiento integral acerca del desarrollo web y tu comunicación asertiva:

Si anteriormente has relacionado una base de datos, podrías visualizar la perspectiva del backend.

Si has diseñado un sitio, podrías visualizar lo que quizo plasmar el diseñador.

Por esta razón, es altamente recomendado que veas las demás áreas que se relacionan con la tuya; de este modo, podrás crecer en tu área (irónico, pero yo lo he comprobado).

Algunas áreas que puedes visitar:

• Diseño: Mejora tu "look & feel" de un buen sitio.
• Backend: Visualizarás la parte lógica y todo el camino que recorre la data.
• Marketing: Sabrás como realizan el engagement, SEO, palabras primordiales y otros
• Arquitectura: En que consiste un API Gateway, los componentes detrás de los endpoints que llamas y como se relacionan.

Hay un océano de áreas, muchas tecnologías, soluciones y sabores; un poco la razón por la que me encanta este mundo.