The Good, the Bad, The Ugly of Deploying Xojo Web Apps

It’s been a very busy first half of the year at BKeeney Software.  We’ve just finished up three medium sized web apps.  One was deployed to Windows Server, one deployed to a Linux web server, and the last to Xojo Cloud.  We’ve done a couple of small web apps to a Xojo friendly host too.  I will describe our experiences below.

Windows Server

The first project was a CRM project where we converted a really old MS Access and ACT! system to Xojo.  The UI wasn’t all that complicated but the data conversion was a pain since it was so dirty.  We ended up using a MySQL database server.

Since we didn’t want to go through the hassle of getting an IIS server we made the decision to deploy as a standalone app.  The hardest part of the whole installation was figuring out how to create the service.  We ended up using NSSM – the Non-Sucking Service Manager to create the service.  After that, installation and updates were a breeze by simply stopping the service, changing the files, and restarting the service.  We are able to VPN into the server and copy the necessary files over.

The server was virtual and running on a VMWare server.  Despite our specifications the server was set up initially with a single core (virtual) processor.  Performance all the way around sucked.  We complained, the client complained, and as soon as they upped it to dual core processors (as we specified) everything went smoothly after that.

Xojo Cloud

The second project was another CRM-type project though a little smaller.  It was using an SQLite database.  We converted the data from a FileMaker database.  The data was much cleaner and more straightforward so it was a relatively easy transition.

The client decided to host on Xojo Cloud so deployment is done from with the Xojo IDE.  The only file we didn’t deploy via the IDE was the database itself which we transferred via SFTP to the appropriate shared document directory on the Xojo Cloud server.

Xojo Cloud, for the most part, works flawlessly.  There have been occasions, however, where it fails to upload properly.  It’s a frustrating experience, to be sure, but Xojo customer service has always been able to fix it.  When it happens on a weekend you’re kind of out of luck.  Here are a couple of suggestions to try and get around the issue:  1)  Restart your server via the Xojo control panel.  2) Change the application ID of your application and try uploading again.

Linux VPS

Our third application has been around a while but we switched over from using SQLite to MySQL after our little db reached about three and half million rows in single table.  It still worked but some of the queries were taking *minutes* to complete.  The decision to move over to MySQL wasn’t a hard one.

You’d think that updating an existing app would be easy.  This one turned out to be anything but easy.  Since this one bites a lot of people deploying Xojo web apps to various Linux distorts it’s worth writing them all down.

  • Until Xojo web apps are 64 bit you’ll have to make sure the 32 bit compatibility libraries are installed.  Each is different so it’s ‘fun’ finding them.  Honestly, check on the Xojo forums to see what people have found.  Hopefully, this becomes a non-issue with Xojo 2015 R3 being scheduled to compile 64 bit apps.
  • Make sure permissions are 775 for all files and directories *including* the overall directory.  The latter one has bitten me more than once.
  • Make sure permissions for the config.cfg file is 664 or 666 (I’ve seen it both ways and I’ve never had a problem with either one).
  • Make sure the owner and group of the files matches that of the system.  If you’re FTP client shows owners/groups and it says something like “mixed” you’ve got a problem.  You’ll need to figure out how to change the owner/group on your own.  This may involved getting SSH access.  It may be easier to work through the CPanel File Manager to upload files because you’re guaranteed, then, to have the right owner/group.
  • Make sure the .htaccess file has been uploaded.  Since it’s a hidden file on Mac OS X it’s easy to miss this one.  If you zip the output directory and then upload the zip it will be there automatically.  If you’re zipping the contents of the directory don’t forget it!
  • Does the server have libicu installed?  Xojo 2015 R2 requires libicu and if you don’t have it your app will just crash with maybe an obscure error in the error log like “Can’t find missing file.”  I had this happen to me this week and when I reverted to 2014 R2 the app started up right away.  If you suspect you’re missing a library and have SSH access, try starting the app via the command line.  It will tell you what the missing library is.  You don’t always have SSH access so that’s kind of a drag.

Not really an issue with web app deployment, per se, but it’s an issue we deal with quite a bit.  MySQL on Mac OS X doesn’t care what the case is of a table or view.  tTable (mixed case) is the same as ttable (all lowercase).  On Linux and Windows this does not appear to be the case.  I know there’s a system variable that can turn this on or off but for this project the client had existing databases on the server and I really didn’t want to muck anything up on them.  Many queries that were running great on our local (Mac) system were not on the server.  Switching everything to lowercase isn’t a big deal (especially with ActiveRecord) but some db apps this will be a nightmare.  So don’t forget to test!

1701 Software Inc.

We have deployed to 1701 Software several times in the past six months for ourselves and for various clients.  We’ve found their servers to be Xojo friendly from the get go (not so with most hosts) and their service is excellent.  They also offer a number of database options that Xojo Cloud does not like CubeSQL and Valentina in addition to MySQL and PostgreSQL.  Frankly, the fact that they are Xojo developers too makes them the top of my list of non Xojo hosting services.  Their prices are pretty good too for those that are price conscious.

That is our experience with deploying Xojo web apps in the past six months.  When everything works right it’s incredibly easy.  When it doesn’t – well, you tend to swear like a sailor.  Hopefully you’ll find this guide to be somewhat useful.  Anything I forgot?

Happy Coding!

[Edit:  Updated to not include an implied timeframe for the R3 release.]

10 thoughts on “The Good, the Bad, The Ugly of Deploying Xojo Web Apps

  1. “we switched over from using SQLite to MySQL after our little db reached about three and half million rows in single table. It still worked but some of the queries were taking *minutes* to complete.”
    I thought a few million rows should be “nothing” to a database but I’m no expert. What do you think the reason for this was, and how much faster was MySQL?

    • You are right, of course, we’ve had SQLite database go into the billions of rows with no issues. However, in this case we were doing some complex SQL queries on views that were taking too long in SQLite. Moving them to MySQL made the performance better. One query went from around 30 seconds to down to less than 6. The other reason we went to MySQL is that if we couldn’t get better query performance we could always turn to Stored Procedures.

      We *love* using SQLite. Rarely have we had issues with it. For this application it wasn’t doing as well as we had hoped. Plus, it was being using a web app with simultaneous users and there were times that between the query slowness and threading issues it was a noticeable delay in response that was unacceptable.

      Oh, and one other thing that I forgot about is that we got a corrupt SQLite database twice in two weeks. Not sure why but it in the long run it seemed better to switch because the db wasn’t going to get smaller – ever.

  2. Hi Bob,

    Thanks for this interesting article!

    But this sentence a little surprised me:

    “Our third application has been around a while but we switched over from using SQLite to MySQL after our little db reached about three and half million rows in single table. It still worked but some of the queries were taking *minutes* to complete.”

    MySQL can work with multiple writers simultaneously, ok. On the other hand, what advantage of MySQL to read a big table? A query on a large table is really much faster with MySQL? Maybe the cache wasn’t enough for SQLite (it is very sensitive to the size of the cache). If it was a writing, don’t forget to delete the index and rebuild after.


  3. Ah sorry, I hadn’t read the comment by Markus! Others are surprised too then.


  4. >When it happens on a weekend you’re kind of out of luck.

    Can you explain what this means? Is no-one on-line on weekends to fix things, or are the people on-line just not always knowledgable enough?

    I got the impression that an app could be down from 7pm on Friday until they opened on Monday…

    • I would suggest never deploying on a Fri Sat Sun whether there is / isn’t 24 / 7 support from your hosting provider unless you want your weekend to also be on the line.
      Now, if its an absolutely critical app update then there may be no choice.
      But if you deploy an app on Fri for customers and it has a flaw your weekend is now just part of the regular work week. And you’re on the hook to fix it – whether its a weekend or not.

      Have a life – don’t deploy on Fri Sat Sun

      • Well, sure, deploy on Tuesday. but what if it breaks on Friday evening and users want to use it on Saturday? Can you clarify what hapens then?

        • I can’t really speak for Xojo. You’ll have to take it up with them.

          The few outages I’ve had with Xojo Cloud have always been during the week. My guess is that a weekend outage might take a while to correct. But to be honest, the smaller the host company, the more likely that is to happen.

          I’ve never had any Xojo Cloud app break days after deployment. Most have happened during, or right after, deployment.

Comments are closed.