El fondo es grande
Si quieres ser realmente bueno en eso, es útil entender qué es y qué no es:
- Back-end es un jugador de equipo, en lugar de ser una primadonna.
- El back-end se encuentra en el medio de una relación de muchos a muchos, (generalmente) no es la pieza solitaria al final de una relación de muchos a uno.
- El back-end tiene mucho que ver con la negociación, en lugar de establecer la ley.
Ser un jugador de equipo:
- Aprendo ambos, front y back end del desarrollo web. ¿Dónde puedo encontrar algunos proyectos para practicar?
- ¿Cómo y por qué se usa C ++ para los servicios de back-end?
- ¿Qué lenguaje es mejor para el desarrollo web frontend / backend: Python, PHP o JavaScript? ¿Y por qué?
- ¿Qué debo hacer si sigo estancado en aprender programación de back-end sin mucho progreso?
- Para una aplicación híbrida (marco iónico), ¿es mejor tener API REST en servidores propios o utilizar proveedores de back-end como Firebase, Deployd o Backend, etc.?
Cuando desarrolla una aplicación independiente, tiene acceso a todos los componentes en el momento de la compilación. Esto ayuda mucho con las pruebas y la corrección de errores, pero también tiende a ocultar errores exóticos ya que algunos estados en su aplicación nunca (o extremadamente rara vez) surgen. Por desgracia, esto no es cierto para el back-end.
Cuando desarrolle el back-end, ningún usuario final verá sus cosas. En cambio, ven el front-end sexy, y estás de acuerdo con eso. De hecho, es su trabajo hacer que el front-end funcione aún mejor. Cuanto más competente sea como desarrollador de back-end, mejor se reflejará en cada parte del producto.
Sentado en el medio:
Hay muchos paradigmas para el back-end. Pueden ser uno a uno (lo que significa que hay exactamente un proceso de servidor para cada cliente), pero eso no escala bien. Todavía tiene sentido para alguien que necesita controlar de forma remota un proceso computacionalmente costoso, pero es muy inusual.
También pueden ser muchos a uno (lo que significa que hay exactamente un proceso de servidor para todos los clientes), y eso es lo que hace Node.js. Tiene algunas ventajas (por ejemplo, probablemente nunca matará la memoria caché para el servidor de bases de datos en un sistema de múltiples núcleos) y algunas desventajas (es posible que no esté utilizando toda su potencia de cálculo y puede experimentar problemas de bloqueo).
Y, por último, pueden ser muchos a muchos (lo que significa que tiene un grupo de subprocesos de procesos de fondo en el servidor que responde a solicitudes en paralelo), y hay muchos (¿la mayoría?) Lenguajes de fondo que funcionan de acuerdo con Este modelo por defecto.
La cuestión es que casi siempre hay algo detrás del back-end, y que generalmente es una base de datos. El modelo que funcione mejor para su back-end puede depender de lo que tenga detrás. Si se trata de una base de datos empresarial completa que viene con un bloqueo incorporado, está bien que la atienda con 10 solicitudes simultáneas. Por otro lado, si se trata de un pequeño dispositivo IOT, es posible que no pueda procesar muchas solicitudes a la vez. De hecho, puede necesitar una capa de arbitraje adicional.
Cualquiera sea el caso, me resulta difícil encontrar un ejemplo de un back-end que en realidad no tenga un recurso detrás, así como delante de él. (Incluso si es solo un disco, también debe administrar ese recurso).
Negociación:
Cuando haces tu primer paquete de back-end / front-end, la negatividad no es algo en lo que pienses mucho. Si actualiza la API de back-end, solo arregla el front-end en el mismo commit. Por lo general, viven en el mismo repositorio en este momento. Sin embargo, desarrollar de esta manera no te brinda la experiencia completa del desarrollo de back-end.
Después de un tiempo, te das cuenta de que también quieres una aplicación nativa para iPhone, y dado que haces llamadas entre back-end y front-end a través de REST, se resuelve fácilmente. Entonces, construyes tu aplicación y la subes a la tienda de aplicaciones.
Sin embargo, la próxima vez que arregles algo en tu back-end, no puedes simplemente empujar la solución. Debe corregir tanto el front-end como la aplicación, y debe enviar la aplicación. Sabe que tomará aproximadamente 1 semana antes de que su aplicación se active, pero no sabe exactamente cuándo sucederá . Aquí es cuando las API versionadas lo salvarán, y esa es una parte de lo que quiero decir con negociación.
Otra parte de la negociación es que los desarrolladores de front-end te pedirán muchas cosas. Cualquier cosa que le pidan es menos trabajo para ellos y más trabajo para usted. Algunas de las cosas que solicitan pertenecen inherentemente a su dominio (asegurarse de que la entrada sea válida, asegurarse de que no se viole la lógica de negocios, verificar los permisos), algunas cosas son buenas (agregar almacenamiento en caché en el back-end para cálculos que también pueden se haga en el front-end, enviando datos preventivos que sabe que el front-end probablemente solicitará pronto, estos son a veces aspectos del jugador de equipo), y algunas cosas están mal (ya sea por razones arquitectónicas, porque es un alcance lento, extremadamente poco práctico o por otros motivos).
Resumen
Cuando eres un desarrollador de back-end competente, tu experiencia te ayudará a tomar buenas decisiones arquitectónicas. No importa si conoce 10 idiomas o solo uno, y no importa si es el rey de las bases de datos o no (en las grandes empresas, probablemente tendrá acceso a DBA de todos modos, y son mucho mejores que sería una tontería no pedirles ayuda). Pero hacer que su back-end funcione dependerá mucho del contexto, y lo tendrá en cuenta.
Por lo tanto, para volverse competente, debe obtener la experiencia.
