Wir machen relativ viel mit Micro-Services und Web/Mobile Anwendungen die darauf zugreifen, und unsere Backends sind normalerweise entweder ASP.NET (alt und Core) Web
API oder Node.js Sachen, die nicht in IIS/Apache laufen sondern self-hosted und meist hinter einem reverse-proxy / cache wie z.B. Squid oder Nginx oder einem Relay Server exposed sind. Das hat den Charme das man damit deutlich einfach und schneller skalieren kann, als neue Webserver zu installieren und dann die nochmal hinter Loadbalancer zu packen etc. - und sie sind echt Cross-Plattform lauffähig.
Ich würde das glaube ich eher mit
Indy direkt machen und nicht mit WebBroker.
ABER: Grundsätzlich sollte alles was HTTP(s)-basierte Endpunkte bereitstellt funktionieren
Von daher, wenn ihr gut bis sehr gut mit WebBroker zurechtkommt spricht nichts dagegen. Ich würde im Rahmen der Webifizierung einer Anwendung aber noch so Schlagworte wie OAuth 2.0 und Json Web Token (JWT) in den Raum werfen. Kommt WebBroker mit diesen modernen Security-Standards zurecht ohne dass Du Dir einen abbrechen musst?
Oder konkret: Kann es vor der Abarbeitung des Requests ein Token auswerten, die Berechtigung prüfen und den Request sauber ablehnen wenn das Token nicht passt?
Kurzum: Es geht sicher mit WebBroker, aber ich würde bevorzugt kleine, self-hosted Services (mit eingebautem Http-Server, wie z.B.
Indy) nehmen und hinter einer skalierungsfähigen proxy/cache-Technologie die die Services nach aussen hin bereitstellt aufsetzen.
Ein bisschen Werbung: Wenn Du zum Big Picture wie sowas End-to-End, im Browser und auf Devices funktionieren soll Fragen hast, dann komm z.B. auf die diesjährige EKON. Wir plaudern da in einer Session ein wenig aus dem Nähkästchen und haben auch einen Halbtagesworkshop wie man sowas wirklich End-to-End aufzieht.