sgcHTML on WebBroker and DataSnap | eSeGeCe Blog

sgcHTML on WebBroker and DataSnap

· Features
sgcHTML on WebBroker and DataSnap

sgcHTML lets you build a web UI in Delphi, from components, with no JavaScript to write. Until now those pages ran on the sgcWebSockets server. You can now serve the same pages from any Embarcadero WebBroker application and from DataSnap servers, so an existing REST backend can grow a full web front end without leaving Delphi. The details, the components and the code are on the new WebBroker & DataSnap page.

This works because sgcHTML is a renderer, not a server. The component and node layer turns your page into a plain HTML string, with no dependency on any socket, transport or server class. That string can be the body of a TWebResponse just as easily as it can be the answer of a WebSocket server, which is what makes the two integrations below possible.

Any WebBroker application

The TsgcHTMX_Engine_Server_WebBroker component implements the standard IWebDispatch interface. Drop it on your TWebModule, or call its DispatchRequest from a TWebActionItem, and it serves the sgcHTML page, the built-in CSS and JavaScript assets, and your htmx routes. It runs on a standalone TIdHTTPWebBrokerBridge, under ISAPI, under an Apache module and as CGI, so it fits whatever WebBroker host you already deploy.

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

Interactivity uses ordinary htmx HTTP round-trips, so no WebSocket is needed. If you prefer, there is a classic mode with no htmx at all, plain full-page navigation and standard form posts, which works with JavaScript switched off. The one thing plain WebBroker cannot do is push, because under CGI and ISAPI the request and response own the socket. For live updates on a plain WebBroker host, use htmx polling, or move to the bridge servers below.

DataSnap, with live updates on one port

sgcWebSockets already ships drop-in bridge servers that replace the Indy TIdHTTPWebBrokerBridge in a DataSnap or WebBroker application, so the server gains WebSockets, HTTP/2 or HTTP.sys on the same port. sgcHTML now plugs straight into them. Assign the engine's Server to your bridge server and the page, its assets and live WebSocket fragment push all run on the same port as your DataSnap REST endpoints.

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);

The engine claims only its own paths, the page, the assets and your routes. Everything else falls through untouched, so /datasnap/* REST and the actions already on your TWebModule keep working exactly as before, and any OnCommandRequest handler you have is chained and runs first. The same pattern covers all three bridge servers: TsgcHTMX_Engine_Server_WebBrokerBridge serves the Indy bridge over HTTP/1.1 and the HTTP/2 bridge, and TsgcHTMX_Engine_Server_HTTPAPI_WebBrokerBridge serves the HTTP.sys bridge.

One backend, two faces

The nice consequence of hosting on DataSnap is that a single set of server methods can do double duty. Your TDSServerModule is your REST and JSON API at /datasnap/rest for any external client, and it is also the data source your sgcHTML pages render from in process. You write the business logic once, and you get both a machine API and a human web UI out of it, on one server, on one port.

Three demos to start from

The product ships three demos that build the same small application in different styles, so you can pick the one that matches your project:

Requirements and availability

The WebBroker engine supports Delphi 7 to Delphi 13. The DataSnap bridge path needs a Delphi edition that includes DataSnap, which is Enterprise or Architect. WebBroker and DataSnap are Delphi and C++Builder frameworks, so this hosting story is specific to those two compilers. The sgcHTML .NET port hosts on ASP.NET Core instead, and reaches the same result there.

Everything described here is available now. The full write-up, the component reference and the code samples live on the WebBroker & DataSnap page.

Questions, feedback or help wiring sgcHTML into your DataSnap server? Get in touch. You will get a reply from the people who wrote the code.