Limits of WE?

Hey all,

We’re currently planning a pretty huge project - and I’d love to realize it in Xojo Web Edition. The database structure is already planned - 108 tables so far. We expect a couple of million records in total. We’ll go for Postgres as we have made pretty good experiences when it comes to heavy usage.

As to Web Edition: I think we’d end up with a around 100 WebPages/Dialogues etc, another 100 custom classes. A couple of hundreds users. Will a web app be able to handle that and remain performant? Should we split things up into multiple web apps? What are the requirements for a server roughly?

The requirement is that you benchmark often and plan resources accordingly. If you do something in some part of the app that is CPU intensive, it’s going to weigh down the app. If your database design ends up leaving all your clients waiting for locks to clear, it’s going to weigh down performance. Benchmark incrementally.

General design strategy… If you can plan for multiple app servers and a reverse proxy to assign and distribute load, you’ll probably be more scalable. At the same time, I’ve seen way too many web projects that drastically overestimate load and get bogged down in complex architectures when a single app server and database could handle their real world load for a long enough time to make the business work.

One tip… With that many possible pages, you may want to be sure to close pages as you leave. Or you may want to preload common paths. Balancing the use case with server resources is more art than science. Build in good data collection so you can make smart decisions as you go.

And never forget: There’s always the option to split one huge web app into smaller ones running on different machines, accessing the same database.

Travis Hill did an excellent session in scaling web apps at the conference this year. I suggest talking with him about it as well.

Yes, you can certainly use it to build a complex, high-user application. It’s nearly impossible to just give server requirements because it is going to vary based on how much logic there is (and how hard the DB queries are) to execute for each user’s session. The key driving factor isn’t just the number of simultaneous users, but the code that powers those user’s sessions as well.

One thing to keep in mind is any place where you think you may want to spawn your own (non-framework) thread in a web app- consider if you can make that a job queue with an outside app/daemon. We’ve found it to be a best practice to keep your web app really tightly focused on the UI, and the data queries that directly drive it. Anything beyond that- like email handling, document processing, polling another service, etc- is likely better served as a separate app with a job queue so you can run as many separate instances as it does or does not require. There are exceptions depending on how the workflow of the app goes, but that’s something to keep in mind generally.

Let me know if you choose to pursue it, and I’ll chime in if I can be helpful. While it isn’t without its flaws (no tool is)- one of the best things about Xojo is how quickly you’ll see things coming to life quickly when you get started…

And if speed matters, use the old IDE!