Aloe Discussion

  1. ‹ Older
  2. 3 weeks ago

    Richard D

    Jan 31 Pre-Release Testers Europe (UK, London)

    @scott b JWT is Json Web Token(s). It’s a way to do authentication.

    I thought he added JWT to one of his classes. Not the Redis one but another. I could be wrong. I’m on my mobile or I would search for it.

    Check out https://forum.xojo.com/45709-json-web-tokens/0#p371198

    thanks... there is sooooo much things i need to learn

  3. Tim D

    Jan 31 Pre-Release Testers, Xojo Pro Richmond, VA

    @Dirk C We already have our current API implementation developed under Luna.
    Are there any advantages to moving to Aloe express?
    Would like to know if this is something we need to consider.
    If there are no real benefits, I would prefer not to reprogram over 90 API calls.
    If there are clear benefits, we'd at least have to consider it before programming more calls (there will be many more calls that need to be programmed in the future).

    The biggest technical benefit of Aloe Express (AE) over Luna is that AE uses a multi-threaded model for processing requests. As a result, you get non-blocking I/O, which can be extremely important depending on the nature of your API and the volume and frequency of the requests that it is handling.

    In general, I think you'll find that AE is simply easier to use and much more flexible than Luna (and the original version of Aloe as well). You get convenient access to all aspects of a request, as well as complete control over the response.

    If you get a chance, take a look at the Aloe Express Getting Started guide ( https://aloe.zone/tutorials/getting-started/index.html ) and I think you'll get a sense of how AE works and its benefits.

    That all being said, with 90 API calls wired up to your current Luna-based API, I wouldn't make converting from Luna to AE a priority.

    I hope that helps. But if you have any other questions, please let me know.

  4. scott b

    Jan 31 Pre-Release Testers, Xojo Pro local coffee shop

    @Dirk C Would like to know if this is something we need to consider.
    If there are no real benefits, I would prefer not to reprogram over 90 API calls.

    when i first read your message I read 9 API calls. and was like sure, migrate that over… until I re-read the message on the full-sized screen (laptop) and was like err.. wait a second.. Migrating 90 API calls is a massive chore. Not even in the same ballpark for level of effort.

    @Tim D In general, I think you'll find that AE is simply easier to use and much more flexible than Luna (and the original version of Aloe as well). You get convenient access to all aspects of a request, as well as complete control over the response.

    this and

    @Tim D The biggest technical benefit of Aloe Express (AE) over Luna is that AE uses a multi-threaded model for processing requests. As a result, you get non-blocking I/O, which can be extremely important depending on the nature of your API and the volume and frequency of the requests that it is handling.

    this...

    are my two biggest reasons to go with Aloe.Express. IF I had my API fully fleshed out and running in production today under Luna or Aloe, would I change it? nope. But I would look at migrating to Aloe.Express for the next generation of the API.

    the REST API I was writing under WE+Aloe, I could overrun with a single Postman[1] instance running through the API. And my issue was the startup cost of the session and processing it just took long enough I was dropping ~5-7% of my calls when I had low latency between Postman and the API server. When I was at places like coffee shops, cafes, airports, hotels, I was running ~10-23% drop rate (same laptop running Postman). I mitigated the drop rates by running 3+ instances of the WE+Aloe app on the host with HAProxy in front of it load balancing across all the instances. That got my drop rate down to (near) 0%/1% respectfully. I say near zero as occasionally I will drop a single API call. Now I am going to deploy Aloe.Express the same way I am doing Aloe (HAProxy for load balancing & SSL termination, 3+ Aloe.Express nodes on the backend - all on a single host)

    Now the performance increase, latency in the API server, etc is reduced with Aloe.Express. I don’t have hard numbers for you as I have not ported the API calls over to Aloe.Express yet. I have been playing with some mock up test API to do some basic testing. Now my work with Aloe.Express for non-API server work has proven to me the speed and flexibility of it.

  5. Karen A

    Jan 31 Pre-Release Testers

    I am pretty ignorant of web stuff so I am not sure I understand that what this can be used for so let me ask this...

    Could this be used as the basis for building an Sqlite (in WAL mode) server for desktop apps for light use - say 10-20 simultaneous clients, and if so how easy would it make doing that?

    - karen

  6. Hal G

    Jan 31 Pre-Release Testers, Xojo Pro Orlando, FL
    Edited 3 weeks ago

    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.

  7. Tim D

    Jan 31 Pre-Release Testers, Xojo Pro Richmond, VA

    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.

  8. Phillip Z

    Jan 31 Pre-Release Testers, Xojo Pro Florence, SC

    @Tim D The biggest technical benefit of Aloe Express (AE) over Luna is that AE uses a multi-threaded model for processing requests. As a result, you get non-blocking I/O, which can be extremely important depending on the nature of your API and the volume and frequency of the requests that it is handling.

    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.

  9. Tim D

    Feb 1 Pre-Release Testers, Xojo Pro Richmond, VA

    @Phillip Z Aloe Express looks very nice, good job.

    Thanks for taking the time to explore Aloe Express and for your feedback. I appreciate it.

    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.

    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.

    The main advantage I see to Aloe based projects is bypassing the Xojo Web event loop and being closer to the ServerSocket.

    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.

  10. 2 weeks ago

    Aurelian N

    Feb 10 Pre-Release Testers, Xojo Pro
    Edited 2 weeks ago

    @Tim D 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.

    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 .

  11. Tim D

    Feb 10 Pre-Release Testers, Xojo Pro Richmond, VA

    @Aurelian N 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 ?.

    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.

  12. last week

    Aurelian N

    Feb 15 Pre-Release Testers, Xojo Pro

    @Tim D 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.

    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 .

  13. Tim D

    Feb 15 Pre-Release Testers, Xojo Pro Richmond, VA

    @Aurelian N 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.

    No ETA.

    My advice is to run your app behind a proxy server (such as nginx) that can also handle SSL termination.

  14. Aurelian N

    Feb 15 Pre-Release Testers, Xojo Pro

    @Tim D No ETA.

    My advice is to run your app behind a proxy server (such as nginx) that can also handle SSL termination.

    Well I prefer to avoid installing extra servers and services but if that needs to be done I`ll think about it .

    Thanks .

  15. scott b

    Feb 15 Pre-Release Testers, Xojo Pro local coffee shop

    @Aurelian N Well I prefer to avoid installing extra servers and services but if that needs to be done I`ll think about it .

    Thanks .

    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).

  16. Hal G

    Feb 15 Pre-Release Testers, Xojo Pro Orlando, FL

    @Aurelian N Well I prefer to avoid installing extra servers and services but if that needs to be done I`ll think about it .

    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. :)

  17. Aurelian N

    Feb 15 Pre-Release Testers, Xojo Pro

    Or use Luna, which is close and offers SSL, which was the next in line.

    Thanks.

  18. 4 days ago

    Beatrix W

    Feb 19 Pre-Release Testers Europe (Germany)

    I've got a total stupid question: What is the difference between Aloe/Aloe Express/Luna?

  19. Tim D

    Feb 19 Pre-Release Testers, Xojo Pro Richmond, VA

    @Beatrix W 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.

  20. Beatrix W

    Feb 19 Pre-Release Testers Europe (Germany)

    Thanks for the explanation!

  21. scott b

    Feb 19 Pre-Release Testers, Xojo Pro local coffee shop

    @Tim D 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.

    @Tim D you might want to add this explanation to the FAQ on http://Aloe.Zone. I forsee others asking the same question in the future.

or Sign Up to reply!