sgcHTML en WebBroker y DataSnap

sgcHTML te permite construir una interfaz web en Delphi, a partir de componentes, sin escribir nada de JavaScript. Hasta ahora esas páginas se ejecutaban en el servidor sgcWebSockets. Ahora puedes servir las mismas páginas desde cualquier aplicación WebBroker de Embarcadero y desde servidores DataSnap, de modo que un backend REST existente puede añadir un front end web completo sin salir de Delphi. Los detalles, los componentes y el código están en la nueva página de WebBroker & DataSnap.

Esto funciona porque sgcHTML es un renderizador, no un servidor. La capa de componentes y nodos convierte tu página en una cadena HTML simple, sin dependencia de ningún socket, transporte o clase de servidor. Esa cadena puede ser el cuerpo de un TWebResponse con la misma facilidad con la que puede ser la respuesta de un servidor WebSocket, que es lo que hace posibles las dos integraciones siguientes.

Cualquier aplicación WebBroker

El componente TsgcHTMX_Engine_Server_WebBroker implementa la interfaz estándar IWebDispatch. Colócalo en tu TWebModule, o llama a su DispatchRequest desde un TWebActionItem, y sirve la página sgcHTML, los recursos CSS y JavaScript integrados y tus rutas htmx. Se ejecuta en un TIdHTTPWebBrokerBridge autónomo, bajo ISAPI, bajo un módulo de Apache y como CGI, así que encaja con cualquier host WebBroker que ya tengas desplegado.

uses
  Web.HTTPApp, sgcHTMX_Engine_Server_WebBroker, sgcHTMX_Router;

// Any WebBroker host: the engine's Owner is the web module,
// so the standard WebBroker dispatcher calls it automatically
FEngine := TsgcHTMX_Engine_Server_WebBroker.Create(WebModule1);
FEngine.Router := FRouter;   // your htmx routes and the page

La interactividad usa peticiones HTTP htmx normales de ida y vuelta, así que no hace falta ningún WebSocket. Si lo prefieres, hay un modo clásico sin nada de htmx, con navegación de página completa simple y envíos de formularios estándar, que funciona con JavaScript desactivado. Lo único que WebBroker simple no puede hacer es push, porque bajo CGI e ISAPI la petición y la respuesta son dueñas del socket. Para actualizaciones en vivo en un host WebBroker simple, usa el sondeo (polling) de htmx, o pásate a los servidores puente que se describen a continuación.

DataSnap, con actualizaciones en vivo en un solo puerto

sgcWebSockets ya incluye servidores puente que se integran sin cambios y reemplazan al TIdHTTPWebBrokerBridge de Indy en una aplicación DataSnap o WebBroker, de modo que el servidor gana WebSockets, HTTP/2 o HTTP.sys en el mismo puerto. sgcHTML ahora se conecta directamente a ellos. Asigna el Server del motor a tu servidor puente y la página, sus recursos y el envío en vivo de fragmentos por WebSocket se ejecutan todos en el mismo puerto que tus endpoints REST de DataSnap.

uses
  sgcWebSocket_Server_WebBrokerBridge,
  sgcHTMX_Engine_Server_WebBrokerBridge, sgcHTMX_Router;

// A DataSnap / WebBroker bridge server
FServer := TsgcWSHTTPWebBrokerBridgeServer.Create(Self);
FServer.Port := 8080;

FEngine := TsgcHTMX_Engine_Server_WebBrokerBridge.Create(Self);
FEngine.Router := FRouter;     // your htmx routes and the page
FEngine.Server := FServer;     // share the DataSnap port
FServer.Active := True;

// push a live HTML fragment to every connected browser
FEngine.BroadcastFragment(BuildStatsFragment);

El motor reclama solo sus propias rutas, la página, los recursos y tus rutas. Todo lo demás pasa de largo sin tocarse, de modo que el REST en /datasnap/* y las acciones que ya tienes en tu TWebModule siguen funcionando exactamente como antes, y cualquier manejador OnCommandRequest que tengas se encadena y se ejecuta primero. El mismo patrón cubre los tres servidores puente: TsgcHTMX_Engine_Server_WebBrokerBridge sirve el puente Indy sobre HTTP/1.1 y el puente HTTP/2, y TsgcHTMX_Engine_Server_HTTPAPI_WebBrokerBridge sirve el puente HTTP.sys.

Un backend, dos caras

La agradable consecuencia de alojar en DataSnap es que un único conjunto de métodos de servidor puede cumplir una doble función. Tu TDSServerModule es tu API REST y JSON en /datasnap/rest para cualquier cliente externo, y es también la fuente de datos a partir de la cual tus páginas sgcHTML se renderizan en proceso. Escribes la lógica de negocio una sola vez y obtienes de ella tanto una API para máquinas como una interfaz web para personas, en un solo servidor, en un solo puerto.

Tres demos para empezar

El producto incluye tres demos que construyen la misma pequeña aplicación en distintos estilos, para que puedas elegir la que encaje con tu proyecto:

• Demos\60.HTML\11.WebBroker, una aplicación WebBroker con un backend DataSnap e interactividad htmx, tanto en una compilación autónoma como en una ISAPI.
• Demos\60.HTML\12.WebBrokerHTML, la misma aplicación en el estilo clásico de HTML simple, sin htmx, con navegación de página completa y envíos de formularios estándar, de nuevo con un backend DataSnap.
• Demos\40.DataSnap\Server_Indy_HTTP_HTML, un panel sgcHTML en tiempo real que se actualiza a sí mismo por WebSockets mientras los métodos REST de DataSnap responden en el mismo puerto.

Requisitos y disponibilidad

El motor WebBroker es compatible con Delphi 7 hasta Delphi 13. La vía del puente DataSnap necesita una edición de Delphi que incluya DataSnap, que es Enterprise o Architect. WebBroker y DataSnap son frameworks de Delphi y C++Builder, así que esta forma de alojamiento es específica de esos dos compiladores. El port .NET de sgcHTML se aloja en ASP.NET Core en su lugar, y alcanza allí el mismo resultado.

Todo lo descrito aquí está disponible ahora. La explicación completa, la referencia de componentes y los ejemplos de código están en la página de WebBroker & DataSnap.

¿Preguntas, comentarios o ayuda para integrar sgcHTML en tu servidor DataSnap? Ponte en contacto. Recibirás una respuesta de las personas que escribieron el código.