sgcHTML no WebBroker e DataSnap

sgcHTML permite que você construa uma interface web em Delphi, a partir de componentes, sem nenhum JavaScript para escrever. Até agora essas páginas rodavam no servidor sgcWebSockets. Agora você pode servir as mesmas páginas a partir de qualquer aplicação WebBroker da Embarcadero e a partir de servidores DataSnap, de modo que um backend REST existente pode ganhar um front end web completo sem sair do Delphi. Os detalhes, os componentes e o código estão na nova página WebBroker & DataSnap.

Isso funciona porque sgcHTML é um renderizador, não um servidor. A camada de componentes e nós transforma a sua página em uma string HTML simples, sem dependência de nenhuma classe de socket, transporte ou servidor. Essa string pode ser o corpo de um TWebResponse com a mesma facilidade com que pode ser a resposta de um servidor WebSocket, o que é justamente o que torna possíveis as duas integrações abaixo.

Qualquer aplicação WebBroker

O componente TsgcHTMX_Engine_Server_WebBroker implementa a interface padrão IWebDispatch. Solte-o no seu TWebModule, ou chame seu DispatchRequest a partir de um TWebActionItem, e ele serve a página sgcHTML, os recursos CSS e JavaScript integrados e as suas rotas htmx. Ele roda em um TIdHTTPWebBrokerBridge standalone, sob ISAPI, sob um módulo Apache e como CGI, de modo que se encaixa em qualquer host WebBroker que você já implante.

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

A interatividade usa round-trips HTTP htmx comuns, então nenhum WebSocket é necessário. Se preferir, há um modo clássico sem htmx algum, com navegação de página inteira simples e envios de formulário padrão, que funciona com o JavaScript desligado. A única coisa que o WebBroker simples não consegue fazer é push, porque sob CGI e ISAPI a requisição e a resposta são donas do socket. Para atualizações ao vivo em um host WebBroker simples, use polling htmx, ou passe para os bridge servers abaixo.

DataSnap, com atualizações ao vivo em uma porta

O sgcWebSockets já vem com bridge servers drop-in que substituem o TIdHTTPWebBrokerBridge da Indy em uma aplicação DataSnap ou WebBroker, de modo que o servidor ganha WebSockets, HTTP/2 ou HTTP.sys na mesma porta. O sgcHTML agora se conecta diretamente a eles. Atribua o Server da engine ao seu bridge server e a página, seus recursos e o push de fragmentos WebSocket ao vivo rodam todos na mesma porta dos seus endpoints REST do 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);

A engine reivindica apenas os seus próprios caminhos, a página, os recursos e as suas rotas. Todo o resto passa adiante intocado, de modo que o REST em /datasnap/* e as ações que você já tem no seu TWebModule continuam funcionando exatamente como antes, e qualquer handler OnCommandRequest que você tenha é encadeado e executa primeiro. O mesmo padrão cobre todos os três bridge servers: TsgcHTMX_Engine_Server_WebBrokerBridge serve a bridge Indy sobre HTTP/1.1 e a bridge HTTP/2, e TsgcHTMX_Engine_Server_HTTPAPI_WebBrokerBridge serve a bridge HTTP.sys.

Um backend, duas faces

A consequência agradável de hospedar no DataSnap é que um único conjunto de métodos do servidor pode desempenhar papel duplo. O seu TDSServerModule é a sua API REST e JSON em /datasnap/rest para qualquer cliente externo, e é também a fonte de dados a partir da qual as suas páginas sgcHTML renderizam em processo. Você escreve a lógica de negócio uma vez, e obtém tanto uma API de máquina quanto uma interface web humana a partir dela, em um servidor, em uma porta.

Três demos para começar

O produto vem com três demos que constroem a mesma pequena aplicação em estilos diferentes, para que você possa escolher aquele que combina com o seu projeto:

• Demos\60.HTML\11.WebBroker, uma aplicação WebBroker com um backend DataSnap e interatividade htmx, tanto em um build standalone quanto em um build ISAPI.
• Demos\60.HTML\12.WebBrokerHTML, a mesma aplicação no estilo clássico de HTML simples, sem htmx, com navegação de página inteira e envios de formulário padrão, novamente com um backend DataSnap.
• Demos\40.DataSnap\Server_Indy_HTTP_HTML, um dashboard sgcHTML em tempo real que se atualiza sozinho sobre WebSockets enquanto os métodos REST do DataSnap respondem na mesma porta.

Requisitos e disponibilidade

A engine WebBroker tem suporte de Delphi 7 a Delphi 13. O caminho da bridge DataSnap precisa de uma edição do Delphi que inclua DataSnap, ou seja, Enterprise ou Architect. WebBroker e DataSnap são frameworks Delphi e C++Builder, então esta história de hospedagem é específica desses dois compiladores. O port .NET do sgcHTML hospeda no ASP.NET Core em vez disso, e alcança o mesmo resultado por lá.

Tudo o que está descrito aqui já está disponível. O texto completo, a referência dos componentes e os exemplos de código estão na página WebBroker & DataSnap.

Dúvidas, feedback ou ajuda para conectar o sgcHTML ao seu servidor DataSnap? Entre em contato. Você receberá uma resposta das pessoas que escreveram o código.