Satisfy my Curiosity?

I’ve been curious lately about potentially trying out Xojo Web. But I have a couple of questions first?

1. - Can Session management be disabled completely in a Xojo Web app? And if so, can the App server still set custom cookies?

I ask, because I have my own custom-rolled Session management logic that resides entirely in a Database (aside from setting a custom session-cookie). This allows for a greatly reduced memory foot-print on an App server, custom Session timeouts measured in hours or days (with no additional overhead) and makes non-sticky load-balancing a non-issue.

2. - Can a Xojo Web app be used to create a public REST API, that accepts and responds in pure JSON? Or XML for that matter?

It appears that a Xojo Webpage communicates with the Xojo App back-end using JSON, to support the application logic. But what I’m looking for is to produce JSON or XML output that can be accessed from any outside external client (e.g., other non-Xojo websites, Mobile devices, etc.)

My apologies if this already documented somewhere, but I’ve only lately returned to Xojo and couldn’t find any obvious answers after some preliminary searching.

Thanks.

  1. You should not second guess the Xojo session management, if you want to spare yourself of a lot of pain. Engineers have spent a lot of brain juice to make Xojo Web work transparently like desktop, and that includes the Session object.
    It does not seem extremely difficult to implement custom session timeout in very long periods using plain out of the box Xojo Web.

  2. Look at HandleSpecialURL. It lets you build web services with any specifications you have.

So the answer to my first question is a no?

Thank you Michel for the pointer to HandleSpecialURL, I’ll check it out.

With regard to question one it cannot be disabled, but it also does not consist of very much either apart from the basics necessary to maintain the session between the client and the server. How you implement that application specific part of the session is up to you - store it in memory or in a database.

If however you are talking about a session web application targeting several thousand concurrent users, including load balancing and all the other good stuff, then no that is not what XOJO is targeted, nor for that matter most of its competitors. On the other hand if that is your target then I’d be surprised if you are trying to roll your own session management.

I’d choose the XOJO framework for work group type solutions rather than say securities dealing or airline reservation system.

Thank you James, I appreciate your technical feedback.

By day-job is as a Web developer using a competitor’s platform. The rules behind Web-based Session management that most platforms support out-of-the-box, so to speak, are pretty straight-forward. Nearly all of them are based on having Session scope variables loaded into RAM of the application server (where the memory store for each Session is indexed by your session-cookie value).

It’s not necessarily a wrong thing to do, because this kind of built-in Session management makes the job of a Web developer much easier, for less demanding projects. And of course I have no idea how Xojo Web implements their Sessions, so this is not meant as a criticism of Xojo.

Well, about 15 years ago or so, I built a custom version of the common Session management rules, where these rules and its associated data all resides in my App’s database (indexed by the decrypted session-cookie value). This change allowed me to turn off Session scope on the App server - then guess what? Boom, I had a high-performance low-memory consuming web app that supported round-robin (non-sticky) load-balancing - allowing thousands of concurrent users. All my projects since are based on this custom Session management database design. This part of my apps has proven pretty solid over the years (on more than one competitor’s platform).

If you look at any popular website built say in the last 10 or 15 years, that have subscribers in the millions - I’d be extremely surprised if any of them are using the built-in (RAM based) Session management that comes with their platform.

Anyway, I was just wondering if I could do the same with a Xojo Web app. Because I have a personal project coming up and was wondering about giving it a go.

Thanks again James.

seems like a console app might be a better option for you. check out https://aloe.zone

For the public REST API question, I’ll second the motion to check out Aloe but then also check out an available add-on called Luna Express in the Add-Ons section of the downloads page.

You may also want to consider buying the 2018 session videos (from the Xojo store) as they are available for only $99 until the 2019 XDC starts. One is by the author of Aloe, and a few others talk about providing APIs from Xojo. The session list is available in PDF format here if you are curious.

Edit: Depending on what your REST API needs to do, you may also want to check out the Key-Value Store add-on also available free on that same download page for Aloe.

[quote=427790:@Scott Cadillac]Thank you James, I appreciate your technical feedback.

By day-job is as a Web developer using a competitor’s platform. The rules behind Web-based Session management that most platforms support out-of-the-box, so to speak, are pretty straight-forward. Nearly all of them are based on having Session scope variables loaded into RAM of the application server (where the memory store for each Session is indexed by your session-cookie value).

It’s not necessarily a wrong thing to do, because this kind of built-in Session management makes the job of a Web developer much easier, for less demanding projects. And of course I have no idea how Xojo Web implements their Sessions, so this is not meant as a criticism of Xojo.

Well, about 15 years ago or so, I built a custom version of the common Session management rules, where these rules and its associated data all resides in my App’s database (indexed by the decrypted session-cookie value). This change allowed me to turn off Session scope on the App server - then guess what? Boom, I had a high-performance low-memory consuming web app that supported round-robin (non-sticky) load-balancing - allowing thousands of concurrent users. All my projects since are based on this custom Session management database design. This part of my apps has proven pretty solid over the years (on more than one competitor’s platform).

If you look at any popular website built say in the last 10 or 15 years, that have subscribers in the millions - I’d be extremely surprised if any of them are using the built-in (RAM based) Session management that comes with their platform.

Anyway, I was just wondering if I could do the same with a Xojo Web app. Because I have a personal project coming up and was wondering about giving it a go.

Thanks again James.[/quote]
So the primary challenge of sessions in Xojo is object serialization. That’s something Xojo just doesn’t have. There’s no way to store all the objects Xojo uses per session in a database that can be recalled by another instance. The sessions reside in memory and must stay there. I went through many possibilities for session storage web initially Xojo Web Edition, even tried to get and restore a ram dump. Long story short, it’s not happening.

You can of course assist sessions with your database. You can load variables of your choosing into a new session based on any logic you choose.

Imagine Xojo Web is running a desktop app on the server and the browser is just a remote viewer for that app. That’s more or less what Xojo is doing. So you can imagine how hard it would be to move your running desktop app to another machine without the app noticing. Now imagine the Xojo framework has to do that without requiring input from the developer. It’s just way too impractical.

Trust me, as a “traditonal” web developer, I tried very hard for sessions to behave as you describe. It just isn’t happening without an extensive automatic serialization framework for Xojo.

Thank you Thom, Douglas and Brandon, you have all saved me a ton of hours on experimenting and research.

If my ideas are to work at all, it sounds like Aloe is the route to start with.

Thanks again everyone for your help.