Trying WebBroker / Apache 2.4 / Linux (RHEL/SuSE/Oracle), but it hasn’t developed much for the last 10 (or is it 20 now?) years, so there are huge gaps in the functionality. I.e.: only the basic “Hello World” stuff is shipped with RTL, no support for Apache logging, no way to read all headers, all server variables (i.e.: REMOTE_USER), etc.
Anyone is using it? Can you share any details?
WebBroker was added in Delphi 4 and it’s very slim feature set is indicative of the period (late 90s).
That bare bones approach though is why it’s still part of the product today though. It just keeps working while the fancier libraries have come and gone as web trends have evolved over the last 25 years.
These days it’s mostly used as the underlying engine of other libraries, e.g. things like the Delphi REST support are built on top of WebBroker.
That’s what it’s most useful as, underlying plumbing for a more advanced technology. Using it on it’s own to write a web application these days would be hard work for anything but the most rudimentary website.
I’m fairly certain you will be able to read all the headers and server variables you referenced, but I’m a bit out of date on it myself. I’ll dob in @Geoff who I’m pretty sure can point you in the direction of the properties you’re looking for.
Yes, thanks, that’s exactly it.
But there are no libraries on top of it for anything other than REST or UI, unfortunately. And REST is not what I’m after here, there’s a lot to WEB than just REST.
With UI, as great as it is in its own right, I’m now trying to figure out if they do anything else and perhaps they could. But if it’s just UI, then it’s not enough for me, I’ll need more plumbing…
Alex
Hi Alex, I’ve been using Delphi, web broker on Apache and Linux centos/red hat since Linux was first supported in the Delphi compiler and have written an extensive web front end on top of it and haven’t run into any limitations so far. It does feel lonely coding in Delphi in general and in Delphi on Linux especially so feel free to reach out. In your sources folder there is a specific Apache web broker file where the mechanics of communicating with Apache are performed. The web broker interface is bare bones so you’ll need to build the entire foundation on top ie session management/cookies, authentication etc. you can also use a tidhttpserver on Linux as well.
That would be great, thanks! Although I can see no way to message you privately. Can you please contact me offline on apastuhov address at everestsoftint, dot com?
I was wrong about UI: UniGUI components I was looking at only support ISAPI / Apache for Windows (maybe Linux/Wine too – like IntraWeb). So there are no UI components available for Apache/Linux at all, it would seem…
It’s really rather weird, because with Linux being stable and free and Apache being a very good and extensible webserver, the combination looks like a clear winner.
DevEx does not have anything for Linux. And TMS has bits and pieces around, but no UI framework for this either, I think. Curiouser and curiouser…
Alex
You can message a user on the forum by clicking on their username next to a post, this pops up a windows with a Message button. Hope that helps.
The Delphi 6/7 era web UI technology WebSnap was built on top of WebBroker. After that they bundled AtoZed’s Intraweb product for a number of years which I believe if you dig deep enough you find some WebBroker units inside.
I wouldn’t be surprised if there are other third party web libraries built on top of it as well. It’s basically more like a part of the RTL these days than a separate library.
There is also
by far the most extensive delphi web framework out there that I know of.
Though it’s more of a framework for remote web API than a website development framework per se.
It’s probably the most future proof option though, write some REST/JSON-RPC APIs with Delphi MVC to access your database and then get a web developer to design a site that consumes those APIs using the web technology du jour.
Incidentally I think the JSON-RPC interfaces for Delphi MVC gets overlooked too often in favour of the REST interfaces. The last system I used Delphi MVC in, we used it to write JSON-RPC based remote APIs not REST. It mapped far more nicely to the types of operations that we needed rather than the basic CRUD operations assumed by REST.
This is what I would do if I used delphi for web dev - I do the same but with aspnet on the backend - my projects started long before delphimvc existed and at the time (2010ish) I just couldn’t hire delphi devs.
To be fair, and I’m not usually defending Delphi libraries. WebBroker does exactly what its meant to do and those requirements haven’t really changed. Its a library to create an abstraction of a web request from IIS, Apache or TidHTTPServer across both Windows and Linux so you can receive a HTTP request in the various forms (GET,PUT,POST,DELETE etc), process that request and return something, including content, files, redirects or error codes as well as cookies. That’s what its designed to do. Combined with Delphi’s ability to make executables, DLL’s and linux executables, it can create a compatible IIS or Apache web modules or a standalone TidHTTPServer powered app.
I fully appreciate the expectation that Delphi should deliver a sensible web framework out of the box, but that’s not the aim of WebBroker. WebBroker does what its meant to do very well.
Also, whilst the older web apps were built by delivering content in server generated or static HTML files for every request, the modern web app powered more by React & Rest or similar libraries actually suits a Delphi (on Linux) powered server side back end very well as you are mostly delivering static files & JSON to the browser. Stick with database drivers from Devart and you have a very good platform to build on. You’ll need to spend a few days writing out some basic infrastructure if you don’t want to use DMVC, MorMot, UniGui, TMS Web Core etc, but its not an impossible task.
I would somewhat disagree: it’s just not complete, with only a couple of header files translated and included. The omission of any Apache logging support comes to mind immediately. Or any means of communicating between modules, Apache-way. Not enough beef on the bones. Opaque Apache structures, no wrappers of any kind. Just literally enough to receive and process a request and send a response and not a morsel more. Even ISAPI implementation is better, which may be why there are a few large frameworks available for ISAPI.
Yes, enough to start building on, sure, but it turns out there are no readily available components for that yet, so these bare bones is all we have.
Ok, splitting this into server Apache module and a client JS GUI with REST interfaces in between may be doable, but it will complicate it, IMHO.
Regards,
Alexander Pastuhov
0414 453 433
Also, splitting it just won’t work: there’s authentication requirement on the server side, so Ajax calls would malfunction.
Alex
Usually data including Ajax calls are secured by the session cookie. You’ll have to explain your requirements in more detail for me to advise but basically when the request comes in, lookup the session cookie value in your session table, check if the user is logged in, proceed or error. When they log out or the session auth expires, don’t accept it anymore.
I agree if you want to use Apache to its full WebBroker isn’t for you but it wasn’t really meant to be a deep integration with one web server. If you want that you should copy the Apache classes that are written to provide the basics, extend them using the existing code as a template and set the WebModuleClass to your new class. This could be a lot of work.
We managed to build a full Saas Cloud ERP system though by using a single Apache module with our own logging, own authentication using session cookies as per everyone else and no reliance on any other module to make things easier.
The only requirement I can see for apache auth modules would be some kind of kerbos/active directory type auto-authentication which is pretty out of favour for oauth style logins.
I thought from memory writeLn can log messages in Linux to the correct journalctl systems but I might be wrong as we have our own logging system.