I hate to say it…but anything Xojo web related (not bashing the product honest) – is a little flakey. I too have some very simple apps that can run for more than a month…or a day or less…with or without active users. Most of my experience is with Stand-Alone apps. There are no memory leaks that I’ve found etc. (I monitor the memory consumption daily) – I’ve found nothing. The process is usually “gone”…and yes…I do get a core dump – which I’m no expert at reading – however some of these apps are so simple it’s hard to imagine. Just for fun. I may build an app that is a blank page with a single button. Clicking the button could display a MsgBox (or update a label on the page) – I’d be willing to bet…it would crash inexplicably eventually. I’ve not experienced this issue in some other frameworks. The general consensus here is usually…use a script to restart it when it crashes. Ouch! I don’t really blame the product…anything web-based has a certain amount of flakey tech built into it. The Xojo framework seems a little more flakey than some…not as much as others. I’m willing to accept a certain amount of “crashes” in exchange for a flexible/powerful system that otherwise performs pretty darn well. Rest assured if/when I figure out where the root of the problem is…I will pass that along if it’s a framework issue.
Flakey is probably not how I would describe it.
I have to be in the TOP 5 if not the at the top regarding number of Xojo web apps deployed in any configuration. Literally a thousand times - I’ve seen it all.
There are some community best practices here that are actually kinda bad:
Example 1: Open a database connection for each session. This sounds cool except you discover that the framework builds a session for any web request to the root with a suitable browser user-agent. This means your app is HIGHLY susceptible to denial of service attacks. Take a HTTP testing tool and fire off 1000 connections to your Xojo app and watch it fall apart as it tries to open 1000 database connections…
Solution: If your database server plugin of choice provides asynchronous queries (MBS and possibly some Xojo standard ones) then you should use a pool of open connections as opposed to a connection per session.
The framework also does not protect you from very painful lessons:
Example 2: There are VERY VERY limited use cases for the Open() event in web controls and pages. Even in Session it’s dangerous if you are trying to manipulate which page is showing or content on a page/control. The Open() event while representing the instantiation of the control/object on the backend does NOT represent the same thing it represents in the desktop framework. On the desktop framework Open() is both instantiated AND shown. On the web Open() occurs when created but you shouldn’t really do ANYTHING in it and use Shown() instead. Someone will find a use case for it but you could just as easily put that stuff in a constructor method and avoid Open() all together.
Solution: Xojo should have made the Shown() event the Open() event and never provided access to Open() or called it “PreRender()” so it was obvious nothing was (potentially) drawn yet.
The framework is the opposite of responsive:
Example 3: While RubberViewsWE or some hard work can mimic responsive design this is not what the tool was designed for. I appreciate the pixel perfect renditions of my app but more views for different screen sizes paralleling “xs, s, m, l, xl, etc” from bootstrap would be appreciated. Think how on Xojo iOS you can switch between iPad and iPhone views. Xojo Web needs the same.
Lastly and only a problem in the largest deployments:
Example 4: No ability to centralize or share Session data forcing you to use sticky sessions and in general can’t scale out horizontally as nicely as one would like. If your load balancer gets restarted or an individual instance crashes you lose a lot of valuable sessions in the process.
I hope that’s valuable food for thought for those on the fence. If nothing else Xojo Web is a great prototyping tool and you’ll find you get 90% there. A little elbow grease and a little learning and you can build something that rivals any other tool.
Thanks Phillip, I appreciate your examples. It will be cause for me to revisit some of my code. I wonder if some things are really truly bad ideas in general or just under specific use cases. Take Example #1) Opening a Database connection for each session. If your app runs only on an intranet where a DOS attack would have to be launched internally (and against a non critical system) seems like session unique database connections should be ok. I’m not worried about “load balancers” and high traffic install. I have an app that’s used by maybe 20 people infrequently…but regularly. I try not to do much in Open events except maybe the session open where perhaps I read hashtags and load up some session wide variables. Perhaps I could do this a better way. I call most web browser based stuff “flakey” because …well…my limited experience has demonstrated it. I work with other programs running under another framework served up by IIS that run until I shut them down without a crash. These have hundreds of users and database connections. That said…those programs took many months to develop. I can do 90% of the job with Xojo in 10% of the time. It’s great for Prototypes and smaller scale apps of me…but I’m no Xojo expert. It’s hard for me to see Xojo as an enterprise tool that can integrate well with something like Team Foundation Server or Bit Bucket. Perhaps that’s just my perception. I’m very appreciative of what I CAN do easily with Xojo.There is so much overhead I don’t need to worry about when putting something together quickly. It’s a very helpful tool. I follow the Xojo blog, and I really appreciate the helpful tips from power users like you.
Session unique database connections: New database connections are expensive too so you are slowing down the user experience. Just FYI.
A framework like ASP.NET is probably not comparable to Xojo Web on the operational level. ASP.NET pages are rendered in unique threads and IIS maintains a thread pool. In a lot of ways it’s like a load balancer. An individual page cannot take down the overall web server. In Xojo Web the application IS a web server so a unhandled exception can cause a loss of all sessions.
I think you summarized the “Xojo dilemma” if there is such a thing. The quick-to-prototype is often enough to go into production only to discover its deficient in some core areas. You spend a lot of time massaging around that. Also factor in the terrible default aesthetic of Xojo Web. Of course you get none of that for free in other framework either and its a LOT of work to make a good looking app. It’s a lot of work in Xojo too and in some ways harder.
You’ll find that to truly appreciate Xojo you basically have to find clever ways to work around a lot of things it does for you as you slowly build up your application. This is not necessarily a bad thing though because most software projects fail due to taking too long to get going in the first place. Having to improve various areas of your app in clever ways is fun and generally a good problem to have.