Sort of… You could use Aloe to handle web requests that return data from the SQLite database.
For instance, http://ipaddress:port/contact/123 could return an html page, json, xml, whatever format you want by receiving that url, extracting ‘contact’ and ‘123’ from the url then doing a query on Contacts for ID=123 and then returning the columns formatted any way you want.
For an api, you might just return json. In Xanadu, we return a responsive web page with a form.
I’m grateful for all of the great feedback that I’ve received over the past few days. Please keep the ideas and questions coming.
Here are a few notes about Aloe Express…
AloeExpress was originally designed for use in Xojo console projects, but you can also use it in Xojo Web framework projects. Here’s a quick tutorial on how to do so: https://aloe.zone/tutorials/web-framework-demo/index.html
Starting with AloeExpress v1.1 (which I hope to release next week), you will be able to run multiple instances of the AloeExpress Server class in a single Xojo app. In other words, you will be able to create a single Xojo app that listens on multiple ports, and optionally processes requests based on the port that they came in on.
In the works:
Support for SSL/TLS. Until then, I recommend running your apps behind nginx, HAProxy, etc.
Support for WebSockets. Until then… Well, I’ve got nothing.
An Aloe Express version of Luna. The goal is to make it as easy as possible to develop Xojo-based Web APIs that support CRUD operations on SQL databases.
And finally, I’ll be giving an “Intro to Aloe Express” session at XDC. I hope to see you there.
Aloe Express looks very nice, good job.
My only feedback is selling it as multi-threaded with non-blocking I/O might be a bit of an exaggeration. Xojo uses cooperative threading so you really can only handle one request at a time. Using the built in database or FolderItem classes can lock up your whole app. You end up needing to load balance several instances to scale.
Xojo Web uses threads as well for each request so the architecture there is similar.
The main advantage I see to Aloe based projects is bypassing the Xojo Web event loop and being closer to the ServerSocket.
Thanks for taking the time to explore Aloe Express and for your feedback. I appreciate it.
Due to Xojo’s use of cooperative/non-preemptive threading, it is still possible for Aloe apps to block on I/O operations. However, by processing each request in its own thread, the frequency and severity of blocking in an Aloe Express-based app are, to some extent anyway, reduced and mitigated.
Perhaps a better way to describe Aloe Express’s multi-threaded model is that it’s as close to non-blocking as we’re going to get.
The impact of I/O operations will be dependent on many factors, including the purpose of the app itself, the load that it is under, the environment that it is running in, what you are interfacing with, etc. Those are factors that are beyond Aloe Express’s control.
But there are steps that you can take to improve performance and “scale” your apps. For example, I highly recommend running Aloe Express-based apps behind something like nginx, HAProxy, etc. Doing so gives you the ability to scale by load balancing multiple instances of your app. It also provides SSL termination, authentication, rate/connection/bandwidth limiting, and more. I’ll be providing more best practices on the Aloe Web site soon, and covering them in my XDC session.
Yes, when using Aloe Express in Xojo Web projects, the framework’s standard ServerSocket and event loop are substituted.
Regardless of whether you’re using Aloe Express with the Xojo Web or console framework, I think that its most important benefits are easy access to request attributes, easy methods for building responses, and complete control over the responses.
[quote=371776:@Tim Dietrich]I’m grateful for all of the great feedback that I’ve received over the past few days. Please keep the ideas and questions coming.
Here are a few notes about Aloe Express…
AloeExpress was originally designed for use in Xojo console projects, but you can also use it in Xojo Web framework projects. Here’s a quick tutorial on how to do so: https://aloe.zone/tutorials/web-framework-demo/index.html
Starting with AloeExpress v1.1 (which I hope to release next week), you will be able to run multiple instances of the AloeExpress Server class in a single Xojo app. In other words, you will be able to create a single Xojo app that listens on multiple ports, and optionally processes requests based on the port that they came in on.
In the works:
Support for SSL/TLS. Until then, I recommend running your apps behind nginx, HAProxy, etc.
Support for WebSockets. Until then… Well, I’ve got nothing.
An Aloe Express version of Luna. The goal is to make it as easy as possible to develop Xojo-based Web APIs that support CRUD operations on SQL databases.
And finally, I’ll be giving an “Intro to Aloe Express” session at XDC. I hope to see you there.[/quote]
Hi Tim,
Great job so far, I wanted to ask about the SSL part but I see that is under progress.
Any idea how to make the app to run as a service on Mac and start on login or on pc start ? and not to show the terminal interface to the user , as a daemon as well ? the idea is to have the main app that handles the interface and the aloe express as a service provider , a middleware for the sqlite database so in a way allowing multi user usage for the sqlite database via API JSON services.
Thanks again .
This isn’t an Aloe-specific question, and I primarily host on Linux-based servers, but I’ll try to help…
I would start by creating a shell script that changes to the location of your compiled app and launches it using something like this:
./aloe-express-demo &To run the shell script when your Mac starts, follow these instructions:
https://stackoverflow.com/questions/6442364/running-script-upon-login-mac
I hope that helps. Good luck.
[quote=373037:@Tim Dietrich]This isn’t an Aloe-specific question, and I primarily host on Linux-based servers, but I’ll try to help…
I would start by creating a shell script that changes to the location of your compiled app and launches it using something like this:
./aloe-express-demo &To run the shell script when your Mac starts, follow these instructions:
https://stackoverflow.com/questions/6442364/running-script-upon-login-mac
I hope that helps. Good luck.[/quote]
Thanks Tim,
Any ETA for the SSL part ? I`m thinking to start some tests for an api based on AloeExpress but the SSL part put all on hold.
Thanks .
No ETA.
My advice is to run your app behind a proxy server (such as nginx) that can also handle SSL termination.
[quote=373679:@Tim Dietrich]No ETA.
My advice is to run your app behind a proxy server (such as nginx) that can also handle SSL termination.[/quote]
Well I prefer to avoid installing extra servers and services but if that needs to be done I`ll think about it .
Thanks .
[quote=373682:@Aurelian Negrea]Well I prefer to avoid installing extra servers and services but if that needs to be done I`ll think about it .
Thanks .[/quote]
its not extra servers. just an extra application. Using Nginx or HAProxy to do the SSL termination makes working with Xojo WE StandAlone Apps and AloeExpress apps very easy to use (in regards to SSL).
Tim’s suggestion is the way to go. Using Nginx or HAProxy to handle SSL will take extra load off your app and provides much more like running more instances of your app behind a single URL. 
Or use Luna, which is close and offers SSL, which was the next in line.
Thanks.
I’ve got a total stupid question: What is the difference between Aloe/Aloe Express/Luna?
Aloe was a module for building Web APIs and sites with Xojo. It relied on the Xojo Web framework for all of the “heavy lifting” involved in handling sockets. It used the HandleURL event handler to bypass the normal processing of requests.
Luna was an older module that made it easy to create APIs to support CRUD operations on databases. Like Aloe, it relied on the Xojo Web framework.
Aloe Express (AE) is a much more complete Web server module that’s designed for building Web apps, APIs, etc. Unlike the original Aloe, AE does not depend on the Xojo Web framework - so you can use it in console apps. It’s more efficient, more flexible, more powerful and I think generally easier to use than the original Aloe.
My advice is this: If you aren’t already using Aloe or Luna, don’t bother with them. Give Aloe Express a try instead.
Thanks for the explanation!
[quote=374208:@Tim Dietrich]Aloe was a module for building Web APIs and sites with Xojo. It relied on the Xojo Web framework for all of the “heavy lifting” involved in handling sockets. It used the HandleURL event handler to bypass the normal processing of requests.
Luna was an older module that made it easy to create APIs to support CRUD operations on databases. Like Aloe, it relied on the Xojo Web framework.
Aloe Express (AE) is a much more complete Web server module that’s designed for building Web apps, APIs, etc. Unlike the original Aloe, AE does not depend on the Xojo Web framework - so you can use it in console apps. It’s more efficient, more flexible, more powerful and I think generally easier to use than the original Aloe.
My advice is this: If you aren’t already using Aloe or Luna, don’t bother with them. Give Aloe Express a try instead.[/quote]
@Tim Dietrich you might want to add this explanation to the FAQ on http://Aloe.Zone. I forsee others asking the same question in the future.
Just did an experiment with Aloe Express 3.0 w/Xojo 2017r1.1 on a Mac, uploading a 320MB file to the multipart demo. It took an exceedingly long time but worked, however the application was using 1.27GB after the upload, even after I closed the browser window entirely.
Might be a memory leak? Unfortunately, I won’t have more time to test with it this week…
Additional details: All I did was open the demo project, modified the MaxEntitySize constant and uncommented the multipart demo, and then tried uploading the 320MB file on a debug run (no other changes to the code).
The upload succeeded, eventually (it took a very long time–I think it was over an hour but can’t say for sure since I stepped away for a while).
@Seth Ober: Thanks for the quick feedback on Aloe Express 3.0. During testing, I uploaded a wide range of file types and sizes. I didn’t notice the slowness that you described. I’m seeing 300Mb files upload in just under a minute. As the saying goes, “your mileage may vary.”
However, I am seeing the memory consumption that you described. To some extent, this is due to the persistent connection feature that was also added in AE 3.0. There were other contributing factors as well.
I’ve just gone through the Request class and optimized it a bit. As a result, you should see a significant reduction in the amount of memory being used as multipart forms are processed. When larger files are uploaded and processed, you’ll still see relatively large amounts of memory being used, but it should free up more quickly.
These optimizations can be found in Aloe Express v3.1, which is now available for download:
https://aloe.zone/resources/downloads.html
Thanks again.
Tim, you posted an updated version in response to my comment within 3 hours?
on a Sunday night?
for a free open-source project?
Seriously?
Ridiculously awesome!
Thanks!
@Seth Ober: You’re welcome!
I feel very strongly about Aloe Express and its potential to change the way that current and prospective Xojo developers perceive and use the platform. So it’s extremely important to me that it works properly.
Please keep the feedback coming!