Standalone Web App with Apache reverse proxy

Targets Web
21

Hey let’s back up a minute here. We didn’t remove CGI “just because we wanted to”.

A Cgi script added another layer of potential failure for your app. If the app was hung, the cgi script couldn’t tell that and would attempt to launch another copy, which often failed for lack of available ports or memory. If the app was busy but not hung, the script might give up waiting for a response and show another error.

CGI was also the #1 reason we could not offer the built-in HTTP/1.1 server options. There’s no way to offer a persistent socket through a non-persistent script which opens and closes for each request. There was also a performance hit because you literally had to wait for the system to open the script each time.

The CGI script also caused memory issues for the uploader component (or when transferring any large chunk of data). If a user uploaded a big file, the script had to load the entire thing into memory to transfer it to the web app. We actually tried spooling it off to disk in 2015 or 2016 but the performance hit just crippled the already slow http/1.0 server that we had.

I am sorry that you are having trouble with this, but there just was no way forward for us with CGI.

8 Likes
22

I have a standard Wordpress website and added the Xojo webapp to an Iframe on a wordpress page. The webapp is called on a an internal ip and port.
Maybe an Iframe would work for you on an IIS website.
Thanks

1 Like
23

The original poster is requesting help / proper guide / step by step tutorial to setup multiple Xojo Web 2.0 web apps to run concurrently and accessible via the standard http port 80 using reverse proxy through Apache on Windows.

Much like what Jeannot discussed ( for Linux ) here How To Run Multiple Xojo Web Apps 2 on Your Server

I think this should be provided clearly for the benefit of everyone using Xojo. It would benefit a lot of people, especially beginners and citizen developers.
I hope Xojo can come out with clear guide / instruction / tutorial / blog on this.
Not everyone is using Linux.

2 Likes
24

How to access multiple applications through one port without subdomain name?

25

I’m not a CGI fan.
I just say that if you remove CGI you should give an alternative solution.
you can’t tell me: go to the it manager and ask for 1,2,…,10 subdomains.
because Xojo wants it that way while the rest of the world behaves differently.

sorry, I was hoping for a solution, but this discussion only leads to resignation.

26

the tool (Xojo) used to work. now it doesn’t.
because the conductor has changed the rules on the fly.
even from Greg’s words it seems clear that nothing will change.

so I can’t do anything but organize the abandonment of the tool (Xojo).

others have already done it and others will do it.
at the end the damage will be counted.

for me, this thread can be closed.

unfortunately there is nothing good.

maybe someone in the future will read it as an example of dialogue with a rubber wall.

27

As everyone know, I am also no fan of the hard abandonment of Web 1 and the transition to Web 2, BUT:
This is not fair at all.

You can still use Web 1 for your things if only this works in your very specific environment.
Greg already stated out, that there were hard technical reasons why they doesn’t deliver a CGI script mode anymore.

Using the CGI Scripts just doesn’t work very well, it never did (I can confirm). And I see no reason why they then had to bring this to the fresh web framework.

And compared to other languages:
Try to set something similar up with Node.js or Ruby on Rails. You’ll have the same struggle. Only difference is, that Node and RoR is vastly used by millions of developers and companies, and Xojo is “only” a small player.

For you, it’s a pity, sure. But if the new web framework doesn’t fit your requirement, then you can not use it. Then maybe use PHP or Web 1 (which I not really recommend). Or dive into Apache/Nginx configuration - I am sure it is somehow possible to sniff on a subpath an redirect it to the app Port.

28

some time ago someone here in the forum not recommended the webapp into an iframe.
I don’t remember the reason.
thank you.

29

I have been running mine in an Iframe for several years and recently changed it over to 2.0.
It works great for me. There is also 3 options for Iframe settings in 2.0
Thanks

30

In the iFrame-Case, you can run your app behind the actual port like “myapp.com:9999” and build a simple html-file which displays this in full screen in the iFrame.

But it still runs on that port publicly, which is often blocked by the IT. Otherwise you could also make a simple redirect to that location, if you enter the subdirectory.

What I mean is, this iFrame solution doesn’t solve your problem probably.

31

@Hanif_Saad I agree in principle, tutorials are always a good thing, but as Lars mentioned below, you also have to be fair to Xojo. I have (unfortunately) an Apache2 running for an intranet at a customer. The possibilities you have compared to Linux are limited.

Basically, the challenge with tutorials for Nginx, Apache2, etc. is that almost everyone uses a different distribution (Linux), and with Windows, there are probably even more pitfalls. Someone with a bit of experience in the subject will quickly realize this and can adjust the recommendations, but for a beginner, it’s often frustrating and they have to muddle through on their own.

I think Xojo’s approach would have to be the Xojo Cloud. I don’t know if it is now possible to point to multiple domains, or one domain with multiple paths each to (secured with HTTPS) different apps. This would have several advantages from the user’s point of view:

  • Extremely easy for someone who doesn’t want to deal with the depth of WebServers, ReverseProxies, etc.

  • A secure operation of web apps, because Xojo Cloud really does an outstanding job here.

  • Semi-affordable for smaller projects (possibly even home users) because multiple (smaller) apps could run on one server. For the average user, in my opinion, Xojo Cloud is too expensive.

If such a solution would financially be attractive for Xojo? I don’t know and none of my business.
Whether Xojo Cloud can do that in the meantime, I don’t know either. Unfortunately, it didn’t in the past and I didn’t look for over a year into the changes of Xojo Cloud…

But that would then give a solution for the users who don’t want to worry about anything. For the rest, unfortunately, remains only to deal with it. As @Lars_Lehmann has already described, each app can “listen” on a different port and you then only have to configure Nginx or Apache so that certain “URL paths” point to these ports. Xojo is happy to explain this in a manual, but I don’t see it as their main job either. The “problem” exists with every tool that displays data via its own server.

32

If Xojo wants to attract citizen coders, they should explain in simple terms and instruction how several xojo web apps can be run on a single Windows PC and accessible from the outside world via single port (e.g 80) via reverse proxy through Apache (or even IIS).

A simple tutorial on how to achieve that would be helpful to many of us.

1 Like
33

A quick google search gave me this: Setup IIS with URL Rewrite as a reverse proxy for real world apps - Microsoft Tech Community Looks outdated, last update from 2019, but it should give the idea. In the above example, one would probably only need to replace

Screenshot 2021-08-12 at 12.01.45
Screenshot 2021-08-12 at 12.01.452212×746 148 KB

with the link to the particular Xojo app. localhost:9000 for instance. The “logic” is always the same for all reverse proxies (or webserver used as reverse proxies):

  1. A webserver is listening to traffic on port 80 / 443 (e.g. listening for mycooldomain/myCoolApp1, mycooldomain/myCoolApp2, mycooldomain/myCoolApp2Admin etc.
  2. Your apps are running on different ports for each app. For instance 9000 for mycoolapp1, 9001 for mycoolapp2, etc.
  3. Upon the requesting UR, the server has to forward that request to your Xojo server (and not to a directory, showing an HTML index page, as it would be the case in a classical scenario where the webserver is showing a webpage only).

Workload balancing is no different, but only “reverse proxing” on steroids. On top of forwarding a request to one particular, static server, a workload balancer is able to implement a logic to which server a particular request should be forwarded too.

In other words, each and every tutorial explaining reverse proxies forwarding to another server should be fine, and you “only” need to replace the server and ports those are forwarding to, by the servername and port of your running Xojo Web App 2.

I suggest to omit all SSL stuff, this can be added later. I hope this help a little bit, until we will see the magic Xojo tutorial.

3 Likes
34

not to make any more fuss, but if you have sold some applications and you are forced to ask:

instead of configuring yourself:

you need to talk to the it manager.

the customers are not all the same in size and structure, the it managers are not the same.
but it is often not easy to ask for and get something from an it manager.

if the it manager doesn’t like you, these requests are a good opportunity for the it manager to put you in a difficult position.

1 Like
35

To understand better, it would be useful to know which tools well-known and popular worldwide use their own web server.

36

I know, I worked as an IT manager for quite a while ;-). But this isn’t Xojo’s problem, is it?

But yes, you will need to explain it to the manager. Listen, dear manager, as we all know technology is changing. I used Xojo. They moved last year from a Web1 technology to Web2, which is basically a re-design and consequently a few things are now working differently. I need your help to make the following adjustments …

It’s not fun, it is extra work, you might not get paid for it, but it is what it is …

If they will fire you and use something different, they have to reconfigure it anyways. I cross my fingers, that you will successfully convince the respective manager that you will need a helping hand.

1 Like
37

It is possible, that they redirect all traffic of one domain or subdomain to one host.
if “https://sub.domain.com” and/or “https://*.sub.domain.com” is directed to the host/computer where your applications run, then you can configure all sub-sub domains locally by your self.

You’ll then have for instance “https://app1.sub.domain.com” and “https://app2.sub.domain.com”. But the IT manager has to configure it only once for “https://sub.domain.com”. And then you care about the internal traffic.

We do this with over 100 instances of the same app in a cluster of PC. We eben have three or more instances of the same app behind one sub-subdomain.

1 Like
38

Take node.js for instance. You would have there a listener too, picking up the traffic and displaying the results to the server. In this case node.js will listen as well on a certain port, and most likely not port 80/443, but “something” in front of it routes the traffic to that “node.js server”.

I think “your” IT manager might even be happy if you explain the new architecture. Whatever someone thinks about Web2 and its pro and cons, I personally believe it’s awesome that a web 2 app is now only a “mini-server” listening to a port you can define yourself.

As a manager, I would prefer something as simple as a Web2-App compared to a CGI script, where I have to believe the developer that this script is not doing any naughty stuff ;-). Of course, you can do naughty things with every tool and language, but the kind of “encapsulation” Web 2 is offering now, is from my perspective far more “manager”-friendly, and especially more IT security Taliban friendly.

You can basically tell the manager: "you know, all that I need is a windows/linux/macOS folder. my app needs to run and then you have to point the URL you want to that server and the particular port the app is listening on (it is up to you, just give me a unique port). That’s it my dear manager ;-).

That’s exactly the same approach they would have to follow if your tool is developed in any other modern web language.

Please don’t get me wrong. I know that sometimes you have to deal with “awful” customers, and you really don’t want to change a running system, perhaps because you can remember the pain it caused x years ago, etc.

It is sometimes a real pain in the neck but I’m convinced that Xojo made in these regards the right move with Xojo Web 2 and that a smart IT team will understand why Xojo made this move and they will most likely be very happy with this change. Furthermore, I bet that these days more people can handle a “simple port listener”, as if they have to deal with (or trust) CGI scripts.

39

Web 1 was it too. The CGI-Mode was additional, what he complains that Xojo dropped that feature.

40

I’m getting old :slight_smile: , I can’t really remember how I made those old Web 1 apps working, but I do know that for whatever reason I had to play around with CGI to make them work. Sending one more prayer that no customer will ever call me for a change on that old stuff :slight_smile: .