web-applications routing client-side server-side

web applications - ¿Cuándo usar "enrutamiento del lado del cliente" o "enrutamiento del lado del servidor"?



web-applications routing (3)

Creo que el enrutamiento del lado del cliente lo usan las aplicaciones de una sola página, donde el sitio real nunca se deja.

El enrutamiento funciona adjuntándose a la página actual, donde los marcos de enrutamiento del lado del cliente reaccionan.

index.html # / mysubpage

El enrutamiento del lado del servidor es similar al que apache realiza de forma predeterminada cuando llama a un subsitio por su url, pero node.js lo hace mediante el uso de rutas porque los archivos html deben procesarse primero.

Si tiene un SPA con un marco de enrutamiento del lado del cliente y está utilizando Node.js, aún necesita el enrutamiento del lado del servidor para cambiar entre los sitios

Estoy un poco confundido acerca de esto, y me siento un poco estúpido al hacer esta pregunta, pero quiero entenderlo.

Entonces, digamos que estoy trabajando con un framework web del lado del cliente, como Backbone, Angular o Durandal. Este marco incluye enrutamiento.

Pero, por supuesto, todavía tengo un servidor para las cosas de la base de datos, y así sucesivamente, que también tiene enrutamiento.

Mi pregunta ahora es:

¿Cuándo usar "enrutamiento del lado del cliente" o "enrutamiento del lado del servidor"?

¿Cómo se "decide" si el enrutamiento ya se realizó en el lado del cliente o si la solicitud se envió primero al servidor web?

Me resulta particularmente difícil imaginar esto porque el lado del cliente podría enrutar antes de que el servidor llegue a conocer esa solicitud.

Estaría muy agradecido si alguien pudiera explicar cómo funcionan estos dos sistemas de enrutamiento juntos.

PD: No he incluido muestras de código porque no estoy buscando una respuesta sobre un marco particular, sino sobre el proceso de enrutamiento en general.


Las aplicaciones modernas a menudo usan el enrutamiento tanto del lado del cliente como del lado del servidor de una manera "mixta" o "híbrida", por lo que es bastante difícil trazar una línea entre estas dos técnicas.

Para comprender mejor cuándo y cómo usar el enrutamiento del lado del servidor y el enrutamiento del lado del cliente, es probable que tenga que averiguar qué sucede cuando tiene una aplicación grande que se utiliza para administrar una gran empresa de fabricación (esto NO ocurre muy a menudo en el mundo real. Es solo un ejemplo útil).

En estos casos, es probable que tenga diferentes personas (con roles diferentes) que vean diferentes partes de este entorno complejo (diferentes aspectos o dominios ). Por ejemplo, un ingeniero vería un servidor de archivos con una gran cantidad de documentos digitales, mientras que las personas que trabajan en el comedor de la compañía verían el menú preparado, el horario de trabajo y la tienda. Estos son "dominios" de aplicación totalmente diferentes que requieren interfaces de usuario totalmente diferentes, por lo que tiene sentido servir diferentes SPA para cada tipo de usuario.

En este caso, podría usar el enrutamiento del lado del servidor para servir una UI específica (SPA) a un usuario específico, mientras que podría usar el enrutamiento del lado del cliente para navegar dentro de esta UI (y cargar datos). Piense en estos SPA como "tableros de control" o "paneles de control" dedicados a "tareas" específicas y utilizados por tipos específicos de "profesionales".

Por ejemplo, podría tener una ruta / myapp / engineering para todos sus ingenieros y una / myapp / cantina para todo su personal de cantina. Cada una de estas URL representaría un dominio específico y serviría un panel específico para un tipo específico de usuario . Estas URL serían administradas en el lado del servidor .

En su lugar, utilizaría el enrutamiento del lado del cliente para navegar dentro de cada uno de estos paneles , cargar datos y volver a configurar la interfaz de usuario según sea necesario.

Por supuesto, su aplicación probablemente también tenga una API RESTful utilizada por sus SPA para obtener los datos que necesitan. Las URL que pertenecen a la API REST deben ser administradas desde el lado del servidor para realizar su trabajo (incluso si NO están asociadas a páginas HTML reales) y solo son llamadas por sus SPA "detrás de escena". Por lo general, se mantienen en un "dominio" separado como / myapp / api.

Lo mismo sucede con la página web estática (como la página "contactos" y "sobre") que generalmente se guardan en una carpeta / myapp / static (o "dominio") y en el lado del servidor administrado (esta carpeta o "dominio" puede ser - y a menudo es - alojado en un servidor diferente).

Por lo tanto, probablemente debería usar el enrutamiento del lado del servidor para separar los dominios de las aplicaciones entre sí y el enrutamiento del lado del cliente para navegar dentro de cada dominio.


tl; dr:

  • con el enrutamiento del lado del servidor, usted descarga una página web completamente nueva cada vez que hace clic en un enlace,
  • con el enrutamiento del lado del cliente de las descargas de aplicaciones web, procesa y muestra nuevos datos para usted.

Imagine que el usuario hace clic en un enlace simple: <a href="/hello">Hello!</a>

En una aplicación web que utiliza el enrutamiento del lado del servidor :

  • El navegador detecta que el usuario ha hecho clic en un elemento de anclaje.
  • Realiza una solicitud HTTP GET a la URL que se encuentra en la etiqueta href
  • El servidor procesa la solicitud y envía un nuevo documento (generalmente HTML) como respuesta.
  • El navegador descarta por completo la página web vieja y muestra la descargada recientemente.

Si la aplicación web utiliza el enrutamiento del lado del cliente :

  • El navegador detecta que el usuario ha hecho clic en un elemento de ancla, al igual que antes.
  • Un código del lado del cliente (generalmente la biblioteca de enrutamiento) capta este evento, detecta que la URL no es un enlace externo y luego evita que el navegador realice la solicitud HTTP GET.
  • La biblioteca de enrutamiento luego cambia manualmente la URL que se muestra en el navegador (utilizando la API de historial de HTML5, o tal vez URL hashbangs en navegadores más antiguos)
  • La biblioteca de enrutamiento luego cambia el estado de la aplicación cliente . Por ejemplo, puede cambiar el componente raíz React / Angular / etc. según las reglas de la ruta.
  • La aplicación (particularmente la biblioteca MVC, como React) luego procesa los cambios de estado. Presenta los nuevos componentes y, si es necesario, solicita nuevos datos del servidor. Pero esta vez la respuesta no es necesariamente una página web completa, sino que también puede ser datos "en bruto", en cuyo caso el código del lado del cliente lo convierte en elementos HTML.

Enrutamiento del lado del cliente suena más complicado, porque lo es. Pero algunas bibliotecas realmente lo hacen fácil en estos días.

Hay varias ventajas del enrutamiento del lado del cliente: descarga menos datos para mostrar contenido nuevo, puede reutilizar elementos DOM, mostrar notificaciones de carga al usuario, etc. Sin embargo, las webapps que generan el DOM en el servidor son mucho más fáciles de rastrear (mediante búsqueda motores), lo que facilita la optimización de SEO. La combinación de estos dos enfoques también es posible, el excelente Flow Router SSR es un buen ejemplo para eso.