A veces, cuando creo herramientas web básicas, empiezo con un backend de nodeJS, normalmente creando un servidor API con ExpressJS. Cuando se alcanzan ciertas rutas, el servidor responde procesando el HTML de EJS utilizando el estado en vivo de la conexión y luego lo envía al navegador.
Esta aplicación normalmente expondrá un directorio para los recursos estáticos públicos y también los servirá. Me imagino que esto genera muchos gastos generales para esta forma de aplicación web, pero no estoy seguro.
Otras veces, comenzaré con una API (que podría ser exactamente la misma estructura de nodeJS, sin procesamiento de HTML, solo administración de estado y exposición de API) y construiré un Angular2 u otra página web HTML que se conectará a la API, cargar información sobre la carga y rellene los datos en la página.
Estas páginas tienden a depender de muchas llamadas AJAX y jQuery para actualizar los componentes angulares después de que se activan un montón de devoluciones de llamada asíncronas. En esta estructura, usaré un servidor web como Apache para servir todos los archivos y definir las rutas, y el JS en las páginas web hará el resto.
¿Cuáles son las fortalezas y debilidades generales de ambos? ¿Y por qué debo usar una estrategia versus la otra? ¿Son viables y dependen de la escala y el uso? Me imagino que la escala horizontal con balanceadores de carga podría funcionar en ambas situaciones.
No hay un enfoque bueno o malo que puedas elegir. Cada uno de los enfoques que describió anteriormente tiene algunas ventajas y debe decidir cuál se adapta mejor a su proyecto.
Algunos puntos que podría considerar:
Procesamiento del lado del servidor
Seguridad: no tiene que exponer información confidencial (tokens de API, inicios de sesión, etc.).
Más control: tendrá más control sobre lo que hace con sus recursos
Soporte al cliente "mejor": algunos clientes (IE) no admiten las mismas cosas que los demás. Representar HTML en el servidor en lugar de manipularlo en el cliente le brindará más soporte para los clientes.
Puede ser más sencillo renderizar previamente sus recursos en el servidor en lugar de tratar con un enfoque asíncrono en el cliente.
SEO, intercambio social, etc.: cómo su servidor envía recursos, así es como los ven los bots. Si pre-renderiza todo en el servidor, el bot podrá raspar su sitio, etiquetarlo, etc. Si lo hace en el cliente, solo verá la página no procesada. Dicho esto, hay formas de solucionarlo.
Procesamiento del lado del cliente
Tiempos de espera. Hacer cosas en el lado del cliente mejorará tus tiempos de carga. Pero tenga cuidado de no hacer demasiadas cosas, ya que JS es de un solo subproceso y las cosas pesadas bloquearán su interfaz de usuario.
CDN: puede servir recursos estáticos (HTML, CSS, JS, etc.) desde CDN, lo que será mucho más rápido que servirlos directamente desde su aplicación de servidor
Pruebas: es fácil burlarse del servidor backend cuando se prueba la interfaz de usuario.
El cliente es un front-end para una aplicación/dispositivo en particular, etc. Cuanta más lógica ponga en el cliente, más código tendrá que replicar en diferentes clientes. Por lo tanto, si planea tener una aplicación móvil, será mejor tener una colección de API para llamar en lugar de incluir su lógica en el cliente.
Seguridad: el cliente puede leer todo lo que se ejecuta en el cliente. No importa cuánto minimice, comprima, cifre todo, una persona ingeniosa siempre podrá hacer lo que quiera con su código.
No marqué pro/con en cada punto a propósito porque depende de usted decidir cuál es.
Esta lista podría seguir y seguir, no quería pensar en más puntos porque es muy subjetivo, y al final depende del desarrollador y la aplicación.
Personalmente, tiendo a elegir el enfoque de "cliente que realiza solicitudes ajax" o una combinación de ambos: renderizar previamente algo en el servidor y el cliente se encarga del resto. Sin embargo, tenga cuidado con este último, ya que romperá sus pruebas automatizadas, la integración de IDE, etc. si no se implementa correctamente.
Última nota: siempre debe realizar validaciones cruciales en el servidor. Nunca confíe en los datos del cliente.