TL; DR: muchas tecnologías JavaScript y HTML5, con una pizca de PHP y Flash.
Tenemos una capa PHP que se ocupa del inicio de sesión (y alguna otra lógica del lado del servidor), así como de servir aplicaciones en diferentes dominios (por razones de seguridad). El resto es todo JavaScript.
Para que JavaScript se comunique con el back-end, lo hace a través de lo que llamamos un “punto de acceso” (AP), un servicio C ++ altamente optimizado que puede manejar muchas conexiones activas a la vez. Este servicio es responsable de enrutar las solicitudes al servicio de fondo correcto. Este servicio es capaz de ejecutarse sobre los puertos 80 y 443 para superar las restricciones de firewall. La comunicación se realiza a través de WebSocket (o Flash para algunos navegadores).
- ¿Cómo crear una plataforma simple basada en la web para conectar compradores y vendedores de un producto específico en un área geográfica específica? Debería subcontratar
- ¿Cuáles son los aspectos económicos de una barra de herramientas del navegador web?
- ¿Existe una aplicación móvil o web para el seguimiento del tiempo de trabajo que también haga un seguimiento del tiempo restante o del trabajo excesivo del día anterior?
- ¿Cómo se aprende a escribir mejores métodos?
- Cómo iniciar una aplicación web
Para comunicarnos con servicios de backend específicos, enrutamos las solicitudes a través del AP utilizando nuestro propio transporte llamado “Hermes”. Esto es básicamente un esquema de URL que le permite al AP saber dónde enviar la solicitud. Las cargas útiles están codificadas como Protobuf. Hermes tiene un buen sistema de almacenamiento en caché (lo llamamos “Mercury”) que almacena los resultados en IndexedDB para los navegadores que lo admiten (tenemos el mismo sistema en el cliente de escritorio, pero implementado en C ++), para evitar solicitar los mismos datos dos veces. Esto es muy útil para recursos que se vuelven a solicitar mucho, como artistas, álbumes y pistas.
Para la interfaz de usuario, hemos escrito un marco de aplicación bastante avanzado (llamado “Stitch”) para permitir que cada vista sea desarrollada independientemente por diferentes equipos sin tener que preocuparse por romper nada. Las vistas se ejecutan en un de espacio aislado, pero aún pueden depender de bibliotecas compartidas para cosas comunes como cargar metadatos de pistas, etc. A partir de este escrito, tenemos ~ 35 vistas únicas (o aplicaciones) en el reproductor web.
Las vistas obtienen datos y realizan acciones a través de lo que llamamos un “puente” (básicamente, una API) usando postMessage, por lo que no necesitamos reinicializar todo el código común para cada aplicación. Lo realmente genial de esto es que muchas de esas ~ 35 vistas que mencioné antes también pueden ejecutarse dentro del cliente de escritorio sin modificación. Por supuesto, en lugar de postMessage, usarán un gancho en Chromium Embedded Framework y nuestro núcleo C ++.
Intentamos utilizar las tecnologías HTML 5 tanto como sea posible, pero en algunos casos dependemos de Flash. Creo que tenemos una pila tecnológica realmente genial para nuestro reproductor web en general.
