CGI - Deployment Options

Thanks Christian for your support you are always effective and effective! I will renew in the future when the situation is restored (let’s see it as a little not covid but bug-shutdown)

Can you elaborate on this? I read it as simple but I don’t understand how this could work.

I’m no web expert, but I guess we can run Xojo2020r1 standalone apps using the right port and configure Apache or Nginx as a reverse proxy. Someone with experience can configure their server to use a dedicated URL for the standalone web app, no? Something like https://mydomain.com/myXojo2020app/

Edit: thank you, Christian, at work, we just build standalone, not much experience with CGI

That is what the current CGI does.
Check if the app is running, if not, then launch it.
And then forward data to the stand alone.

Or just provide a redirect to point to the right port.

@Calvi Tecnologie srl Calvi Cloud services aren’t inherently expensive. I wrote a blog post about how to deploy to Digital Ocean on a $5/mo server, and you can build from there to use more than one app on the same server.

I currently run multiple Xojo Web apps on a server running Apache, PHP, and MySQL as well. The whole thing runs my personal collection of websites; static html, php, xojo, and wordpress! $10/mo.

Just takes some time to research; or you can pay someone a premium fee to do all of that for you :slight_smile:

When did you last look at the cost of Cloud Services? Amazon Web Services (Lightsail) starts at $3.50 per month for example and there are many others as well.

it may be good to ask @Geoff Perlman or @Greg O’Lone about how the people using web servers with apache and CGI option can continue to work in the future.

I have been building & deploying Web projects since the very beginning. I have never deployed using CGI and I have never deployed to a cloud server. They’ve all be either my own or belong to my client.

New releases of XOJO 2020 without CGI deployment are not interesting for us because the deploy could not be sold to customer that want CGI on their servers. Only for personal use or as a Cloud service.

Thank you Christian Schmitz for the suggestion, I sended a post to Geoff Perlman, I hope he will give me an answer :slight_smile:

Same for us. Web 2.0 would be dead on arrival, if there is no workable migration path.

And public port must be 443 for HTTPS as a lot of companies block everything else.

generally speaking, I think the pre-release route is very alarming.
almost no documentation, almost no examples.
almost no comments from the Xojo team to the doubts and requests of the users.

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.