¿Cómo funcionan las páginas de GitHub, Shopify y Volusion?

Gracias Medet Tleukabiluly por A2A.

Por lo general, se llaman subdominios.

Según Wiki, un subdominio es un dominio que forma parte de un dominio más grande; El único dominio que no es también un subdominio es el dominio raíz. Por ejemplo, west.example.com y east.example.com son subdominios del dominio theexample.com, que a su vez es un subdominio del dominio de nivel superior com (TLD).

Los subdominios son las configuraciones de nivel de servidor web que se pueden hacer usando el archivo httpd.conf de Apache o cPanel. Pero estos subdominios son estáticos y debe crear manualmente una entrada para cada página.

Los subdominios dinámicos como en github, Shopify, etc., se pueden hacer de muchas maneras, un método simple es implementar redirecciones http en el servidor web donde subdomain.domain.com sería redirigido a domain.com/subdomain.

La otra forma es actualizar el registro A y CNAME en DNS.

Implementé una redirección similar para un sitio de comercio electrónico donde todas las solicitudes de store.xyzcompany.com serían redirigidas a xyzcompany.com/store. Pero en este caso solo hay un subdominio y una raíz de contexto. Por lo tanto, es relativamente fácil de implementar.

En el caso de aplicaciones como github que son más grandes que nuestra imaginación, confían en redes de Content Delivery como Akamai para alojar contenido estático, servidores web personalizados para manejar solicitudes HTTP.

Entonces estás preguntando sobre los nombres de subdominio DNS, ¿verdad?
No creo que los métodos exactos de esos sitios sean públicos, pero aquí hay una suposición educada sobre cómo trataría de construir algo así:

  1. Averigüe si / cómo es posible redirigir todas las solicitudes de DNS a una sola dirección IP. Esto podría lograrse, por ejemplo, almacenando un registro como `* .github.io 123.123.123.123` en una tabla de búsqueda de DNS.
  2. Una vez que todas las solicitudes apuntan al mismo servidor, podemos comenzar a actuar sobre ellas mediante programación al verificar el encabezado HTTP del host para las solicitudes entrantes, por ejemplo, `Host: foo.github.io` en nuestra aplicación del lado del servidor.
  3. Con ese conocimiento, realmente podemos hacer lo que queramos, es solo una entrada de cadena como `/ path / after / the / host /` o cualquier otro `X-Http-Headers: así ‘.
    Pero incluso si el paso # 1 resulta ser más complicado que eso, esto es lo que estamos buscando. Canalice la entrada desde el exterior para que sea solo una entrada de cadena regular de nuestro servidor web, porque una vez que tenemos eso:
  4. Podemos decidir servir contenido estático o dinámico en función de esa cadena de entrada. O envíe una página 404 si no tenemos nada que mostrar para esa solicitud en particular. O cualquier otra cosa que se te ocurra, de verdad.

El único límite es su imaginación ™, y la especificación HTTP, por supuesto.

Todas las páginas, gráficos, diseño y estilos generalmente se encuentran en una base de datos de administración de contenido, ya que esa es la forma de administrar sitios web en estos días. El backend es probablemente algo así como Joomla, pero personalizado. Como ese es su modelo de negocio, probablemente no lo dirán.
GitHub es probablemente diferente pero no conozco todos los detalles.
El tipo de medio que utiliza la base de datos también depende de cuán sofisticados quieran ser. Podría ser un conjunto simple de unidades, matrices RAID optimizadas para bases de datos, SSD, SAN, NAS o almacenamiento en la nube de terceros (menos probable).

Por cierto, esta es literalmente una buena respuesta ¿Cómo funciona shopify.com, github.io, volusion.com, etc.?