[quote=104807:@Travis Hill]but it shouldn’t be run on the public internet directly. Always better to have those behind a reverse proxy to do SSL and handle any other requests up front.
[/quote]
This really depends on the app, the audience, and the sensitivity of data. It is an inaccurate a blanket statement for a very good sized chunk of the apps WE developers are making.
[quote=104817:@Michel Bujardet]I know, Brad, you are a strong proponent of standalone and it probably is a tribute to your competence. But some users do not seek mastering the intricacies of SSH, and appreciate being able to simply upload, set permissions and be confident it runs. For them, Xojo Cloud is even better, that shields them from TCP.
[/quote]
Sure for starting at $50/month. And there are still some prominent nagging bugs in the current release that affect CGI which make Xojo Cloud fall short of “simplu upload, set permissions and be confident it runs.” Reevaluate every release until they’re fixed ;-).
Let me put it this way. I have had a few occasions over the past couple years to show people how easy managing stand-alone deployments was. Some of them are recognizable names here, and all of them were hesitant. I’m hoping one or two might chime in.
Here’s another thing… If stand-alone has security issues that can only be cured by hosting in Xojo Cloud rather than addressed in a timely manner, we’re all screwed. Because that instance you’re running behind apache and firewalls and intrusion detection and whatever else processes requests the same way stand-alone does. If there’s a high enough expected payoff, the hackers will get around everything in front eventually.
One more thing. You know I love you guys and what you do and what you make possible, and I more often than not try to bite my tongue and be supportive. But you need to lose this. Xojo Cloud can be a valuable service at its price point AND alternative deployments of web edition apps can be secure for their needs. If that’s not the case, you need to make it more the case. It’s hard enough coming to a client with a niche development tool. I don’t need people sniping at me because a Xojo engineer says their own product is not secure enough for deployment. That doesn’t win you a Xojo Cloud customer. It loses me a client. And for all intents and purposes with the kinds of projects I do, it’s probably horse excrement.
My point was not about security issues. Nor was it about Xojo Cloud bugs, which are bound to recede eventually. I just tried to share a positive experience with CGI and VPS hosting for someone who had absolutely no experience with WE at the time.
It does not mean standalone is bad. I am not in a logic of either/or here.
I heavily mixed that reply to both you and Travis. Let me sum up my reply to you with this. CGI can be an easy deployment. So can stand-alone. Despite how things may appear, you need not be a rocket scientist to accomplish either. You might need someone to wlak you through it once or twice.
I did appreciate your insight in using standalone. My concern is that standalone needs to be launched to work.
Right now, as I am typing this post, even if for some reason the server was restarted and processes killed, I am assured the CGI will run if one of my customers needs it. How do you insure that the standalone is launched in due course to provide uninterrupted service ?
I haven’t mentioned Xojo Cloud at all on this thread, that’s not what it is about.
I’ll always advise people to put both standalone behind a web server if they can. Web servers are purpose built to handle the latest HTTP requests, they can handle routing to multiple instances, and can easily be made to serve other files. If someone doesn’t need any of those types of things for their particular deployment, that’s fine. It’s just my general advice when asked.
Sadly this problem is made difficult because Xojo only supports CGI or full blown standalone. Performance would be less of an issue if there was a full Apache mod that could speak Xojo’ish.
Brad is correct that CGI has less performance. There’s no way around it. CGI is basically the oldest mechanism of hooking up to a web server that there is and its terribly not optimized for sending/receiving thousands of javascript requests.
Michel is right that CGI offers an easier deployment scenario that when it works is less of a headache. It’s not too terribly difficult to write a cron job that checks the status of the standalone app and keeps it running. However there is one giant disadvantage to that:
IP Addresses
A host that I may or may not know about who frequents this board just recently got approved for a new IP block. That process sounded fairly painful as the World is running out. This means you are NOT a good netizen if you are consuming an entire IP address for your one standalone app. Nevermind the fact that you aren’t fully utilizing the value of your server with your-host-of-choice.
This means that ultimately you must put your Xojo apps behind a load balancer or proxy of some kind regardless of the security implications of Xojo serving the “public internet”. Two IP addresses on a single server is doable but any more than that and the average host is going to be reluctant because they can be held accountable for misuse.
So either Xojo needs to support web servers more natively with easily installed modules/ISAPI extensions, etc. OR there needs to be a simple load balancer/proxy that can be easily configured to run in user land. If you tell someone that they must edit their httpd.conf and configure all these proxy routes and such they are just going to give up.
Brad has a point regarding a niche tool and ease of deployment. It doesn’t do us any favors to make Xojo difficult to deploy. Unfortunately CGI nor standalone can be the final answer. It works for now though.
That’s an interesting idea. The problem is that you’d then need to have Apache experience on how to install modules. For someone like you (Philip) and me, that’s not an issue, but most of our users don’t have nor want to have that type of experience. [quote=104854:@Phillip Zedalis]Brad is correct that CGI has less performance. There’s no way around it. CGI is basically the oldest mechanism of hooking up to a web server that there is and its terribly not optimized for sending/receiving thousands of javascript requests.[/quote]
Agreed. OTOH, it is the most universally accepted mechanism for deploying an application across all of our supported platforms. Since there’s several server versions of Linux (and probably hundreds of configurations), At least 6 versions of Windows (Server and Desktop) which run some version of IIS, and OS X 10.7 - 10.9. We need something that works consistently on as many of those platforms as possible.[quote=104854:@Phillip Zedalis]If you tell someone that they must edit their httpd.conf and configure all these proxy routes and such they are just going to give up.[/quote]
Probably true of Apache modules as well.
In both cases the executable (stand alone or cgi) is a full exe NOT a shared library which is what you’d need for a module.
Until / unless Xojo produces shared libraries an apache module is kind of out of the question.
I agree with everything you said Greg/Norman. I’m not advocating Xojo divert resources to building Apache modules. I’m just explaining that languages like PHP do this in a more optimized way.
I believe a user land load balancing solution is going to be required in the end. Like nginx but in a box thats essentially configured the moment you upload it.
CGI is today what it is and it works. It could be better. We have totally derailed the OP’s post about hanging though. I have that seen as well OP and for the host in question it was the backup process that caused the hang. Depending on the virtualization technology used the server was being frozen and somewhere between Apache/Xojo it got stuck.
I am landing on the theory that the hang/freeze was caused by memory overload. Just two days ago, I was able to observe the server (starter config with a humble 1TB RAM) reaching 100% without much activity. IMO this was caused by the perfect storm of website pings (about 4 very low volume sites - 2 are WordPress - are hosted on this server), a few sessions of customer applications, one of which was spawning on the order of 20-30 myapp.cgi instances (each consuming about 5% available memory) - and a similar number of httpd instances - each of those consuming on the order of 2% of memory. BTW - I am managing a once-a-day FTP backup in the wee hours of the morning, which doesn’t seem to be when the issues occur,
So as I follow this thread - and thanks to all contributors for the great discussion (almost as good as the World Cup thread starring Yoda), I am sorting through the info to see which approach is most predictable, and what I need to do to keep the outside world from creating these issues. Certainly I can beef up my RAM and I need to see if I can set some watermark warnings to catch my attention before a customer freeze happens again. I will also run some experiments with my apps and my server to get me to a directional decision. If anyone disagrees with what I think the root cause is - please let me know.
Correction: myapp.cgi’s consume 1% of memory. A small number of php-cgi’s (I believe from the WordPress sites) each consume about 5%.
Do you not have any swap? Even at 100% memory utilization it should not cause a dead stop if you have swap available. Slower yes but should be able to respond in some amount of time.
Frankly, CGI is much slower than Standalone …
Standalone + reverse proxy (very simple to implement. Especially with Abyss, optimized for Xojo) is the best solution. But it is not fully supported by Xojo!
For example, if you have an SSL connection and if you are using external controls (Google Map …), the browser will display a security alert or do not show the control …
Please vote!
(https://xojo.com/issue/23891)>]<https://xojo.com/issue/23891>
It did keep going at 100% for a little while, but eventually it froze up. So while I have no proof that was the culprit, it is my best and only guess at the moment.
[quote=104959:@olivier vidal]Frankly, CGI is much slower than Standalone …
Standalone + reverse proxy (very simple to implement. Especially with Abyss, optimized for Xojo) is the best solution. But it is not fully supported by Xojo!
For example, if you have an SSL connection and if you are using external controls (Google Map …), the browser will display a security alert or do not show the control …
Please vote!
(https://xojo.com/issue/23891)>]<https://xojo.com/issue/23891>[/quote]
Have you tested this theory lately? I believe all of the external libraries have been fixed.
No, I did not see any release notes on it in the latest versions. If the reverse proxy is now fully managed, it is a very good news. 
If I remember correctly, the external libraries malfunctioned in SSL mode, because the web app does not know that the proxy relaying the request via https. The proxy sent the “X-Forwarded-Proto” header with value ‘https’ so that the app knows that the connection was secure. But the app did not handled this header. Now this is the case?
I should have done a better job quoting (darn iPad doesn’t give me many options).
That’s what I was asking if you had checked…
For what it’s worth, it looks like the Forwarded HTTP extension still hasn’t been ratified. If you remember, we implemented WebSockets before they were ready and the one we chose was obsolete in 6 months. As you can imagine, we’re a little gun-shy of proposed standards now. It looks like it might finally be stable though… http://tools.ietf.org/html/rfc7239
[quote=105531:@Greg O’Lone]For what it’s worth, it looks like the Forwarded HTTP extension still hasn’t been ratified. If you remember, we implemented WebSockets before they were ready and the one we chose was obsolete in 6 months. As you can imagine, we’re a little gun-shy of proposed standards now. It looks like it might finally be stable though… http://tools.ietf.org/html/rfc7239
[/quote]
Yes, I understand. But it is now a de facto standard:
http://en.wikipedia.org/wiki/X-Forwarded-For (and your link)
Especially, the former WebSocket was very young and only supported by few browsers if I remember correctly.
Then this header is used long enough by all major web servers. And even if they finally decide to use a different header, the correction will not be long in any case incommensurate with websocket.
Currently, without this header, with the SSL reverse proxy, we can not properly use external libraries, it is a big problem.