Cuando un desarrollador back-end implementa una API, ¿debería tener una idea clara de lo que está haciendo el desarrollador front-end?

Hablando de OOP, una API debe tratarse como una interfaz. Un contrato entre frontend y backend. Frontend no sabe acerca de la implementación de estos Ifaces. Debe quedar claro qué métodos existen, qué entrada aceptan y cuál será el rendimiento.

Tienes toda la razón en que el óptimo de una API es cuando escupe exactamente lo que se necesita en la interfaz. Por lo tanto, la comunicación entre el frontend y el backend es clave para lograr los mejores resultados (rendimiento / usabilidad) en ambos extremos.

Es posible que te encuentres en situaciones en las que los chicos del backend son los mejores y la interfaz tiene que lidiar con eso. Desarrollar un buen código frontend y UX es un arte. Desarrollar un buen código de back-end también es un arte. Si te encuentras en tales entornos, trataría de cambiar las cosas o buscar mejores oportunidades.

¿Tiene un conjunto claro de especificaciones funcionales? ¿O lo estás inventando a medida que avanzas?

¿Está su back-end completamente andamio con un conjunto completo de pruebas unitarias que están pasando?

Si no puede decir que sí, entonces esta es claramente la fuente de sus problemas.

Me encanta escuchar sobre proyectos que no tienen tiempo para especificaciones funcionales, pruebas unitarias, etc. debido a limitaciones de tiempo y pasan mucho tiempo reinventando el código.

De hecho, lo que desea hacer es que los cambios en el front end no provoquen cambios en el backend (a menos que lo necesite). El front-end es solo una vista de las operaciones realizadas, por lo que sí, si edita la lógica de su negocio, habrá un cambio de back-end, pero no todo el tiempo (también puede cambiar el front-end para cambiar la vista también)

Lo que está diciendo es cierto para equipos pequeños, pero para aplicaciones distribuidas grandes, la lógica de la aplicación (back-end) está expuesta por servicios que el front-end puede utilizar para diseñar casos de uso.

La gente no puede estar de acuerdo en esto. Estoy de acuerdo con usted, ya que las funciones del servidor a menudo estarán estrechamente relacionadas con la forma en que la vista de GUI está actualmente dividiendo las partes mostradas. Ignorar esto a menudo conduce a una abominación en la que guicode itera sobre los elementos del servidor y los cherrypicks y los recombina. Para todos menos crud, es horrible. Pero, de nuevo, hay muchas opciones diferentes de dónde se ensambla la interfaz gráfica de usuario (representación del lado del servidor). Desafortunadamente, los gerentes sin idea del desarrollo continuarán pensando ‘nuestros chicos de back-end en el oeste crearán una API de servidor, luego solo nos dirigiremos a los esquemas de los países del este. Por lo general, obtienen el resultado que merecen: – /. Es mejor mar adentro de ambas partes, si quieres ir por esa ruta.

Si ambos se desarrollan en un equipo, generalmente es un esfuerzo cooperativo y las cosas tienden a estar estrechamente vinculadas. Si los servicios están siendo desarrollados por otro equipo, deberá centrarse en el desarrollo impulsado por contrato para definir la API bajo contrato antes de codificar la solución. En ambos casos, la API debe cumplir con la Ley de Postel. Principio de robustez – Wikipedia

Como corolario, si no desea que sus servicios estén estrechamente vinculados porque desea maximizar la reutilización de las características comerciales comunes, asegúrese de que sean desarrolladas por equipos separados.