In the docs, it says that new web apps are not CGI anymore. I understand from that how they worked in the past, but how do they run now with the latest version? Java? A JS Node server? Ruby on Rails? They must be running some programming language in the background.
It seems, from a quick five-minute reading based on the port to open, it’s running a self-contained web server. Is this correct? If yes, what web server is it (on Linux)? I’m not entirely sure if it’s a great idea to run a self-contained web server, usually they can’t be tuned in the settings and crash under very light traffic and have to be constantly restarted or babysit.
Where can I find more info on how the web app is actually running and the settings available?
You are right, Xojo web apps compile to a self-contained webserver. Many people would recommend running a Xojo web app behind a reverse proxy. This allows you to run multiple web apps and handle a higher number of connections. Xojo web apps can be compiled to Linux, Mac or Windows. You really need a virtual private server to run Web apps or deploy to Xojo’s own cloud. Another really good option is to deploy to a VM using Lifeboat by @Tim_Parnell
In the IDE, when you run a Web app, an exe will be launched on your own machine and you will connect to it on local host with your web browser.
So it seems to run similar to Ruby on Rails or Tomcat apps. Sure, putting your own server and a reverse proxy or load balancer for multiple instances is possible. I know they have their own cloud service, but not really an option for more enterprise apps or which need to run in private non-public servers. It’s still very interesting, they do support web with the same source code. My main interest is actually building native apps for different operating systems.
Really? That makes no sense if you have to create a different project for each platform. I can understand that not all API’s are the same on every operating system, but I would expect Xojo to handle that. Why else would you use it if you still have to create different code for different platforms. Isn’t that what Xojo is supposed to solve? Same base source code, and it translates the API on compilation time for each target platform generating native machine code?!
It is a separate app (Feedback) where users make their bug reports, then come to the forum, share the case number and beg other users to “give points” so it can be fixed. If not enough points, it is considered that the “average user” is not affected by the bug and it is just ignored, if you are not constantly updating the report, it is closed and archived.
Non-ui code can be shared between web, desktop and console apps. For example, if you have a module with common functions. We have apps where all of the business intelligence is shared between the three targets I mentioned.
That is great. Of course, I never expected GUI elements to be shared, each platform is different, but if the logic for functions and classes can be shared when it comes to backend code, that is already very positive.
Those checkboxes will allow you to have one set of “library code” which includes functions which might be specific to a specific project type, which won’t break in other project types. (e.g. an extends method on a web control in the shared library code won’t “break” a desktop project)
This combined with various #pragma commands allows a lot of code sharing between Xojo applications targeting different OSes and platforms. It’s one of the very best features of Xojo IMO.