Proporcionar recursos locales de JS y CSS para los fallbacks de CDN

14

Dado que

  • Los CDN son Good Thing porque pueden brindar recursos más cercanos al cliente, el cliente puede almacenarlos en caché y puede reducir la carga en su propio servidor.
  • En los navegadores recientes, la carga de recursos de servidores de terceros no reduce la seguridad gracias a Subresource Integrity (SRI) .
  • Los CDN pueden estar desactivados o bloqueados en algunos países y no están disponibles cuando se desarrolla sin conexión 1 .

Creo que es convincente utilizar CDN, pero también estar preparado para que no estén disponibles. Esta publicación del blog ofrece una buena introducción a los diferentes enfoques para proporcionando fallbacks. Si observa el ejemplo de Basic , puede ver que ya contiene un poco de código repetitivo para proporcionar alternativas solo para jQuery y Bootstrap, mientras que la solución favorita sugiere usar Fallback.js , que parece estar prácticamente sin mantenimiento durante el año pasado. Del mismo modo, el más relevante SO question para el tema, solo se trata de proporcionar un respaldo para jQuery.

Sin embargo, en la mayoría de los proyectos del mundo real, esperaría tener 5 o más recursos js / css, por lo que siento que no debería tener que repetir un repertorio desordenado para proporcionar recursos para todos ellos. Además, cada vez que agregue o actualice un recurso, ahora tiene que

  • Actualizar el enlace CDN
  • Actualice la copia de reserva local mediante una descarga manual o cambiando la versión en npm / bower config
  • Actualice el enlace al respaldo
  • Actualizar el hash SRI

Mientras que en el Ideal World , esperaría agregar / actualizar el recurso en un archivo de configuración, y hacer que todos los otros pasos se ejecuten automáticamente (y luego ejecutar pruebas para ver si la actualización falló algo) ).

¿Ya existe un flujo de trabajo establecido para lograr esto?

¿O los CDN, y especialmente el SRI, son demasiado recientes?

¿O a la mayoría de las personas simplemente no les importa proporcionar recursos para los recursos de CDN?

1. Aunque podría tener una compilación de desarrollo que no dependa de CDN, pero también considero que es una forma de repliegue, ya que también debe mantenerse.

    
pregunta ValarDohaeris 30.03.2016 - 14:15

3 respuestas

1

Creo que quizás no entiendes cómo los sitios más grandes que pueden necesitar este tipo de resiliencia usan CDN.

no es solo una cuestión de hospedar jQuery o algunas imágenes. La mayor parte del sitio se alojará en el CDN, y solo las cosas generadas dinámicamente, como las páginas de pago o las canastas de la compra, se alojarán en los "sitios web principales"

Incluso estos se están moviendo cada vez más para ser procesados localmente con JS y cookies para mostrar cosas específicas del usuario sin afectar el procesamiento del lado del servidor.

Si falla un CDN y comienza a recibir todo el tráfico que pasa a su servidor web, es probable que se caiga, de lo contrario no necesitaría realmente el CDN.

    
respondido por el Ewan 04.04.2016 - 17:44
1

El sitio en el que trabajo en nuestro CDN se ha vuelto cada vez más importante para el sitio. Al principio, simplemente lo usamos para almacenar imágenes / CSS / JS. En esta etapa, teníamos una propiedad de configuración que reescribió el nombre de host de estos recursos de www.mysite.com/ a www.cdn.com/ por lo que si el CDN fallaba, simplemente podríamos cambiar este valor de host o apagarlo por completo y dejarlo. Las URL que apuntan a nuestro servidor web.

Sin embargo, ahora hemos pasado al almacenamiento en caché de páginas básicamente completas con contenido personalizado que se carga a través de AJAX. Nuestro CDN se ha convertido en algo esencial para nuestro sitio y podríamos correr sin él tanto como podríamos con nuestros propios servidores HTTP. Le pagamos a nuestro CDN una buena cantidad de dinero en parte debido a su capacidad de recuperación y las promesas de los SLA de tiempo de actividad, por lo que poner tiempo y esfuerzo en las recaídas parece una pérdida de tiempo. Tenemos un plan de DR en el lugar solo en caso de que haya un problema importante con nuestro proveedor, pero no es un proceso automatizado simple y veremos un período de interrupción al migrar a nuestro CDN alternativo.

Entonces, en respuesta a su pregunta, depende de qué tan integral sea el sitio de CDN. Si solo está poniendo sus recursos en la CDN y asumiendo que sus servidores http podrían manejar la carga de la entrega de este contenido, entonces puede usar un interruptor de configuración para activar o desactivar la CDN. Junto con una herramienta de monitoreo, puede automatizar que el interruptor esté encendido o apagado.

    
respondido por el Sutty1000 07.04.2016 - 09:36
0

Veo 3 razones muy importantes para usar CDN:

  1. Reduzca la latencia de la red para usuarios en regiones distantes. Cuando tiene un sitio web para una audiencia global, su alojamiento en América del Norte no parece ser rápido para los usuarios en el sur de Asia, especialmente en China. La diferencia en la experiencia del usuario puede ser tan grande que desalentará a los usuarios a usar su sitio. En este caso, la CDN multirregional será esencial para su negocio.

  2. Sirva la mayor cantidad posible de recursos de alta disponibilidad. La confiabilidad es una de las razones principales para usar CDN en la nube: el tráfico se redirige automáticamente a los nodos disponibles y puede agregar algunas medidas adicionales para redireccionar el tráfico si toda la región de la nube está inactiva.

  3. CDN es más fácil de mantener y más económico que los servidores de aplicaciones que sirven contenido dinámico. Cuando tiene que lidiar con los problemas mencionados anteriormente, es una forma natural de ahorrar dinero.

Todo esto significa que el objetivo de CDN es aumentar la disponibilidad de su contenido para los usuarios finales. Si CDN falla o se ralentiza por algún motivo, el respaldo del lado del cliente aumentará significativamente la carga de la página, ya que primero intentará obtener el recurso al que no se puede acceder. Una mejor solución es tener el diseño del lado del servidor que hará una sustitución de la URL base en enlaces como "{CDN} /js/jquery-version-min.js". Esto permitirá reenviar el tráfico al servidor de aplicaciones en lugar de CDN si falla la comprobación de estado de CDN: los clientes no realizarán solicitudes innecesarias e irán directamente al servidor de aplicaciones, lo que sería su reserva con la solución del lado del cliente. Esto también solucionará el problema de las implementaciones locales y de preparación, ya que puede implementar la lógica de sustitución para determinar la ubicación de los recursos estáticos según el entorno y la configuración.

    
respondido por el Ivan Gammel 08.04.2016 - 17:01

Lea otras preguntas en las etiquetas