Aloe Discussion

Late night programming has its downfalls.

Silly little “/”

Thanks Tim

Looking forward to your webinar tomorrow.

Is it possible to trigger a http request from within “RequestProcess” and return that data back to ALoeRequest.ResponseReturn ?

the app crashes if you call the http request directly.
the http request proceeds if called with xojo.Core.Timer.CallLater(0, AddressOf GetLicInfo) but no data seems to be passed to ALoeRequest.ResponseReturn

Perhaps Threads is the way?

How are you triggering the http request?

This code within RequestProcess runs credit card payments via Stripe using the MBS plugin:

[code]///////////////////////////////////////////////////////////
// Call the Stripe API
Dim theCurl As New CURLSMBS
theCurl.OptionURL = “https://api.stripe.com/v1/charges
theCurl.OptionUsername = APIKey
theCurl.OptionVerbose = True
theCurl.OptionPost = True
theCurl.OptionPostFields = Join( theData, “&” )
theCurl.OptionSSLVersion = theCurl.kSSLVersionTLSv12
Dim theCurlPerform As Integer = theCurl.Perform

// Hold the results in properties
debugJSON = theCurl.DebugData
resultJSON = theCurl.OutputData
resultDictionary = xojo.data.ParseJSON( resultJSON.ToText )[/code]

If I loop until my request gets content it returns data properly to AloeRequest
I know doevents() is a not best practice
whats the best way to delay or trigger the aloeRequest once data is available?
I tried return the ALoeRequest in the pageRecvd event of httprequest however it only works if the doevents is included

dim mkpsock As new mkpsocket mkpsock.request=AloeRequest mkpsock.GetLicInfo while mkpsock.mkpContent ="" app.DoEvents() wend AloeRequest.ResponseReturn

@Tim Kearns:

It looks like your mkpsocket class is sending asynchronous requests, and that seems to be causing some of the issues and challenges that you’re running into. Without the loop that you’ve added, your app just continues on, and never gets the results of the http request.

Depending on what you are connecting to, you might be able to use the older HTTPSecureSocket class to send a synchronous request instead. Then your app will wait to receive a response (or timeout) before continuing.

If you need a code sample that shows how to do this, let me know, and I’ll whip something up.

  • Tim

@Tim Dietrich:

Hello Tim,

Nice job,

Any updates on authentication methods and ways of securing the data and authenticating the clients ?

How is this different from Luna ?

Thanks .

Keep up the good job.

Since the aloe.express is out, is Aloe available to download???

@Aurelian Negrea :

Thanks for the kind feedback regarding Aloe Express.

You asked, “Any updates on authentication methods and ways of securing the data and authenticating the clients ?”

You have a number of options. One is to use HTTP Basic authentication, and evaluate the Authorization request header. For example:

Dim Authorization As String = Request.Headers.Lookup("Authorization", "")

I’m not a fan of JSON Web Tokens (JWT), but that’s another option. I believe there are Xojo-based approaches to implementing JWT. You can also implement them using something like nginx.

You also asked, “How is this different from Luna?” Luna was designed to make it as easy as possible to prop up Web APIs that provide CRUD operations against MySQL databases, and it worked with the Xojo Web Framework. Aloe Express is much more flexible, and works with Xojo console apps.

If you have any other questions, please let me know.

@Richard Duke :

The original Aloe module is still available. Please check out the Aloe Express FAQ for info:
https://aloe.zone/faq

thanks… got the files…

I have used all three. Luna, Aloe and Aloe.Express. I have a REST API (still under development) using Aloe. And I have a website running under Aloe.Express. FYI. I am going to migrate everything I have under Luna and Aloe to Aloe.Express.

Unlike @Tim Dietrich and @Hal Gumbert, I am using Aloe.Express with HAProxy (they are using it with Nginx).

Scott, what do you use Aloe and Aloe.express for???

currently WE+Aloe is being used for an REST API server. This will be replatformed to Aloe.Express.

currently Aloe.Express is being use to host a (fairly) static website. The HTML code is static, with a few things being changed on-the-fly using handlebars as placeholders. Now this site is a very basic use case of Aloe.Express. I am looking to do more complicated/interactive websites down the road.

in the near future the WE+Aloe REST API service will be moved over to Aloe.Express. Aloe.Express lets me control a lot more of the API process. WE keeps getting into my way as I am trying to do the API.

@Kem Tekinay released Xojo based JWT within the last week (if my memory is correct).

do u mean the Redis_MTC ??? what is JWT anyway??

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

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

[quote=371585:@scott boss]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[/quote]

thanks… there is sooooo much things i need to learn

[quote=371614:@Dirk Cleenwerck]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).[/quote]

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.

[quote=371614:@Dirk Cleenwerck]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.[/quote]

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.

this and

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.

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