I’m planning on building something like social network application. Here in the forum, I read over and over how you should never open up your database directly to the web and always use middleware. So here’s what I’m thinking.
I also read, Xojo server are robust up to 20-30 simultaneous users. Is this 20-30 simultaneous sessions OR 20-30 simultaneous requests (reads, updates, etc.) Of course I understand that’s just a rough estimate and a LOT depends on the complexity of the pages being rendered.
Allowing new users to create accounts without cost could potentially generate a lot of traffic. So I’m thinking of building this as a desktop application and using the Xojo server as middleware. In this way, once time-stamped data is received by the client, it gets stored locally and only new data needs to be sent or retrieved from the server. See any bottlenecks in this scenario?
I know I could pass data to the client using a hidden browser in the html / of a received page. But is there possibly a more efficient way to raw transfer data between an Xojo desktop app and a Xojo server? (Ie: ad-hoc, ftp?)
The potential number of simultaneous requests depends entirely on the cost associated with each in-flight request. CPU time, memory bandwidth, networking bandwidth, disk I/O, etc. It’s important to remember that Xojo’s framework uses cooperative multithreading. This means the number and length of blocking operations in a request (operations which must complete before a thread switch can occur) also affects the number of simultaneous requests.
The other thing to remember about cooperative multithreading is that a single Xojo application can only take advantage of a single core. You can mitigate this in a middleware scenario by designing your API and your server application so that multiple copies can run on one machine, likely with some sort of front end server like nginx to route incoming connections to instances of your server app. This is easier if your API is stateless.
There’s no way to estimate the maximum number of in-flight requests without estimating the work involved and knowing the hardware that the server application will run on. Well written code that’s non-blocking running on a fast system can handle a lot more than poorly written code on a slow system.
If you’re thinking of using Xojo Web as your middleware that’s fine, but don’t build up/tear down entire web sessions and pages just to return information. Use the WebApplication.HandleURL event to implement your API. Then the format of the returned data is up to you. JSON is probably more efficient than HTML unless, of course, you are returning HTML pages to be directly displayed in the desktop app.
I’ve only recently looked at https://aloe.zone/ myself. At first glance there’s a lot of overlap with functionality provided in Xojo Web applications. (The WebRequest object does a lot for you even if it’s in HandleURL and not a full blown WebSession.) That said, I’m sure there’s additional functionality in Aloe, and Aloe is available under a MIT license. So there no reason not to investigate and see if it better meets your needs.
From what I understand the main requirement is your client is a desktop app written in Xojo. What you’re sketching out is the classic three tier client-server-DAL architecture so I think your on safe ground there. I think the next question is how complex the data is you want to retrieve. Is your client doing the heavy lifting of manipulating and displaying the data in the UX (thick client) or is it going to behave more like a web browser and display data that is formatted by the server? Sound like the first scenario is more what you’re thinking?
So in this case you can absolutely write the middleware in Xojo. That said it wouldn’t be my first choice. My person opinion at this point is that xojo is great for the client but you’re going to be building a lot of the boilerplate to make it work WELL. I’d consider something like a .NET core app in the middle. This gives you a framework for building an standard RESTful API that can server your client. Out of the box here’s what you’ll get with that approach:
Cross platform web server build to scale
Routing
Asynch request handling
Authorization
Automatic JSON serialization/deserialization of objects
Data access and ORM mapping (if you want it)
Building all this stuff in XOJO is possible but you are reinventing the wheel, and trust me your not likely to do it much better. Even if you don’t know C# the amount of code required to get/join/update data from the database, perform some basic logic and pass it back to your xojo client is fairly minimal. Xojo clients can play nice with other frameworks and at the end of the days it’s about the best tool for the job.
I’m not knocking Xojo but compared to ASP.Net Core well this is the type of stuff it’s built for. If you’re thinking about old ASP.net .NET CORE is a different story, small, scalable and cross platform. Now if you need a small scale web app that’s going to expose a UI then the Xojo web projects are awesome! But as a web API, not my first choice. Speaking from experience here.
I usually like to mark a thread complete, using the “this answers my question” link, but in this case, every answer is extraordinary. Exactly what I need to hear! Obviously ASP.net Core with its “Asynch request handling” is the best route to go. If only for its ability to scale by utilizing multi-core CPUs. It’s a tough choice. Alo, where Xojo coding is fun. Or learning C again. No fun there. At this point I think it is more important to get out a MVP (minimum viable project), than to start learning a new platform.
To allow for maximum scalability, I am now thinking of using Xojo or Alo middleware, without a relational database; acting only as a manager for user accounts and transferring ip addresses back and forth between my Xojo peer-to-peer app. (Considering how the responsibilities of this Xojo middleware would be minimal, It could always be rewritten later using Asp.net.)
Reading through these posts again, I see 3 new subjects I will need to explore: Alo middleware, cooperative multithreading and the WebApplication.HandleURL function.
Julian-- About Automatic JSON serialization/deserialization of objects. This is where binary data such as photos, can be sent or received as part of a JSON file. Yes. That’s important. Sounds like JSON data transfers are the way to go.
To be fair to Xojo you have to be aware of blocking code, but it’s not normal in these kinds of applications. When Xojo Web fires HandleURL or HandleSpecialURL your code executes on a new thread. As long as you don’t call something which blocks Xojo’s cooperative multithreading then incoming requests continue to fire on their own threads and all the threads work towards completion concurrently.
The trick is taking advantage of multiple cores. With this type of app if you think about it from the beginning and design for it, it’s not that hard to design your middleware to run as a set of child processes. In this particular use case I’m not convinced .NET’s way of handling concurrency is better than Xojo’s way, it’s just different. A big part of the reason why I say this is that if you’re going to have a large user base, you have to design your middleware to run over a computer cluster any way because very soon your issue won’t be cores, but multiple machines. A Xojo app designed to run as multiple child processes is cluster-ready.
The big caveat is that if you do have to call some blocking API or 3rd party library in the course of handling a request, .NET gives you a way to do that while Xojo cannot. Not without some plugin wizardry or yet another child process which is spawned to handle that particular function. This just isn’t common in a middleware scenario.
Your choice to use or not use a database should not hinge on scalability. The major databases are highly optimized for concurrency and support clustering across multiple machines as well. And there’s no shortage of cloud solutions where you can scale your database resources on the fly. From the viewpoint of your Xojo code you’re simply opening another connection to a single database. But that database address/port can actually hide a cluster of machines.
Obviously this excludes the built-in SQLite. You should be looking at PostgreSQL (my personal favorite), MySQL, or MS SQL Server.
Everything coming in over HTTP is effectively a string. And everything you send out has to be a string. Xojo’s JSONItem can directly convert to/from a JSON string. But then you’re responsible for mapping values in a JSONItem to instances of Xojo classes which you create (i.e. myUserClass, myChatClass, etc). Images would have to be converted to a string as well, but that’s not too difficult with the methods already in the Xojo framework.
One thing I have to hand to .NET is that if you take full advantage of what it offers, you will end up writing less glue code for this type of application than you do in Xojo. That doesn’t make .NET an automatic choice, but it’s something to consider.
I would not recommend to develop a REST-Server with Xojo. There are better and more efficient solutions for that (Golang, Node, Express, ASP.NET etc. ).
I would recommend to take a look at a serverless solution like firebase (firebase.google.com).
You can use firebase in Xojo (via curl, HTTPSecureSocket or chilkat) with a ready to go REST-Interface (i.e. https://firebase.google.com/docs/database/rest/retrieve-data). Also there are ready to go solutions in firebase for authentication, storage, security, etc… The firebase database is NoSQL and IMHO ideal for a social network app.
Nowadays serverless solutions are very popular.
The advantages, inter alia, are:
No own server hosting
No server maintenance
No pain with security issues
Fast
Scalable
Quick and easy to develop
You can focus on Your App
Often You can start for free
There are also other suppliers for “serverless” solutions (e.g. AWS).
Thanks guys! I really appreciate you chipping in here and giving me a quick education!!
@Dagmar suggested firebase.google.com Then I looked a this 2 minute video Wow! User authentication, secure NoSQL db, bulk storage, analytics, and maybe even payment processing.
So now considering the “serverless” option; this looks like the best choice; both in terms of time saving and scalability. Having easy and secure access to a NoSQL db, extends the marketability of my (any) Xojo app in imaginable ways!!
Though “Serverless” is kind of a misnomer. I think this can be better described as, hosted milddleware.
CURL is a Linux command, but also supports FTP, TELNET, and even POP and SMPT. With all these protocols, its probably the least secure.
HTTPSecureSocket is the Xojo command used to initiate secure (SSL) connections with remote servers.
CHILKAT takes multi protocol communication way beyond CURL, but involves a yearly license subscription.
I took a look at Amazon’s serverless offering, Amazon Web Services. Can’t say whether Google or Amazon is more economical. Though, it does look like Google’s offering is more integrated and better suited for an Xojo app developer.
Sounds like a big mix-up and the chances of this happening again might be slim, but someday… who knows?
Sounds like good advice. Yep! Google Firebase did sound too good to be true.
Looks like I’ll be going with Xojo Alo Express for all the reasons stated in the previous posts.
And finally, for anyone who is interested in other Firebase problems, (from Firebase users), this message thread proves very revealing: Why Im dumping Firebase for Web
Using webservices from AWS, Google etc seems to be very tempting on the first hand, but after digging into details I found the pricing to be most obscure, to say at least.