CGI - Deployment Options

Dear Natale if you try Xojo 2020 Release 1 Build 49176 version you will see how it is really different and new (web projects are completely new, difficult to migrate from old ones and no CGI ! and then for Raspberry there is no 64bit support) therefore I’ll wait and see if next releases will be interesting or not.

If you are using NGINX as a reverse proxy it is relatively simple to forward different subdomains to a specific app and the needed port. Paying @Tim Parnell a few bugs, will give you the insights, that’s the reason I don’t want to post it here ;-), he did a great job!

What are you missing? I bet that thousands of customers had issues building a CGI environment, most probably failed (without knowing) to build a secure environment. The new stand-alone app is really as easy as possible.

I don’t think a viable will ever be possible. Web 1.0 has to die. Both technology approaches are so different that a migration path seems impossible to me, or at least I would prefer seeing the efforts spent on the development of Web 2.x. It is bad news indeed, but those things happen. We started educating our customers a couple of years ago that new technologies might need a partial re-development or that new functionality can’t easily be deployed. I’m not aware of any programming languages not breaking. up things with a new release. Even Apple does this with Swift, or for new policies that 32-bit apps are not allowed any longer. Their restriction to allowing only 64-bit most often requests more efforts than just changing the flag to 64-bit and to re-compile …

Well, others doing that doesn’t mean it’s a good thing.

Their original passthrough stub was some code written in Perl I believe. You can find it in the package created with the older Xojo version. There may be issues with just keeping using it with web2.0 I don’t know how clever it was. It may not properly handle the newer ability to manage persistent connections or something, but it would be fairly easy to try it and see what happens. Just pull that out of the old version and put it into the new version and see… I haven’t looked at it in a long time but all it did was to provide a reverse proxy of it’s own between the CGI stdin/out and a socket or something to the running web app. It may not have been that simple they may have done something with the connection going through a file system socket or something like that so some experimentation may be necessary.

You could definitely alter it, or create a fairly simple perl script from scratch to do the same thing but to connect to the newer web2.0 built in server thus forwarding it on. Back in, oh, the late 90’s? I did the same thing to make an old mac “acgi” program written in realbasic to be able to continue to run on OSX with apache. It just provided a pipe from stdin/out from apache to a socket connection to the acgi app. Used that as the web interface to our home automation software for a decade. I even sold an acgi enabler stub to people who wanted to continue to use older mac acgi’s on OSX :wink:

That being said you’ll get much better performance by properly configuring NGINX to forward the connections. As I recall it wasn’t that much voodoo compared to some of the apache configuration options. But a universal stub like what Christian mentioned above is definitely possible.

This a million times over.

If they can’t do it right they shouldn’t bother doing it at all. And there’s still so much that needs to be done in the migration that I wish they would just stop and focus on making Web2.0 Rock Solid instead. There’s not a single one of my projects simple enough to make the migration process helpful. The one plus side of the migration is it shows all the holes Web2.0 has yet to fill. Thus far we’re losing a ton of events and functionality.

I’ve been experimenting with this … I created an Ubuntu 20 server with Apache configured as a “reverse proxy.” Not really complicated - it took me a while because I’m not really a Linux guy and I’m learning as I go. This test was done with apps created with Xojo 2019R3.1 with build set to stand alone. I’m expecting the same behavior in 2020R1 but haven’t converted any of my apps yet.

First, create/build Xojo web apps, each app on a different port. I used 8080 and 8081. Make sure the executables are running on your server, I used a cron job running at startup for this.

Create a file in /etc/apache2/sites-enabled/
File name shouldn’t matter as anything in this folder is included to the main apache.conf

Content:

[code]<VirtualHost *:80>
ServerName www.mydomain1.com
ProxyPreserveHost on
ProxyRequests on
ProxyPass / http://localhost:8080/
ProxyPassReverse / http://localhost:8080/

<VirtualHost *:80>
ServerName www.myotherdomain.com
ProxyPreserveHost on
ProxyRequests on
ProxyPass / http://localhost:8081/
ProxyPassReverse / http://localhost:8081/
[/code]

I like Apache because certbot can automatically configure it. Quick easy and free certificates and secure website.

I second that one. But I’m afraid that’s how xojo “works”.

Ten years ago, it bothered me, but meanwhile, I’m just maintaining my old stuff with the latest stable release for that purpose, and I’m waiting, waiting, waiting for new stuff before using it. And often, I’m using different programming languages for my customers, and Xojo is max used for a quick mockup. Unfortunately, I don’t believe this will change anytime soon. …

The only “good” news for xojo is, those other companies from MS to Apple are doing the same, changing the game rules all of a sudden. Of course, I don’t support this approach, but I realistic enough that it is just how it works … Web 1.0 is outdated by so many means, migration should just not be an option at all - it will never work properly, especially not if one was using heavily “plugins” like Graffiti Suite etc.

I also think that a R1.x series could be not have a “migration” tool and the focus would be a stable code. Once the stable use is reached they could produce a migration tool tentative. Trying to load an API1 code meanwhile would just emit a version warning and not load it. API1 loading/conversion could come in the R2 while people would be already producing new API2 projects finding deeper issues before trying (and many failing) to convert their legacy API1 code.