One of the projects I am currently working on has escalated from a hardware prototype to systems integration work. The client assured me, ‘The software is done.’ But it turns out what they had was a very carefully constructed demonstration. My client is an entrepreneur who has proven to me they will spend for results but doesn’t do detail, technical or, “It’s difficult.”
There are three Cloud platforms involved, all with REST APIs, driven by JSON, secured behind OAuth2 and one being Google Workspace. I have managed to progress from a demo to a production system by documenting the demo and working up platform configurations and working procedures for human arbiters to follow. What I have currently can be made to work but will not scale beyond a few well trained employees as there is way too much scope for operators to make mistakes.
The requirement is essentially for a Server to Server application to automate a few tasks that need to be coordinated across the Cloud platforms while gathering input from each of the platforms and a disinterested end user. I’ve completed an initial proof of concept investigation using PHP and carefully avoiding the Google auth. It’s clear from the investigation the Google auth will need to be grasped to take the project forward. Projected growth is for 5 systems initially, 50 systems, 150 systems and a wishful thinking maximum of 400.
I am considering using Xojo web to shorten the front end development. Time to market is a high priority and I hate writing HTML and CSS forms, and while I am pretty adept with Xojo my JS is close to non-existent.
Does the integration sound like something Xojo web can do robustly?
Will it scale reliably?
2.1. Will it scale without requiring the mother of all servers with a software stack the height of the Eiffel tower at the back end?
How does one go about calling server side PHP from Xojo web?
4.1 Is there a server side Xojo alternative as robust as PHP?
Are there ready rolled code snippets for Google’s 2 legged auth?
5.1 Are there ready rolled code snippets for internal authentication and session management?
My concern with utilising Xojo is long experience of discovering issues one might never expect, being difficult or impossible to resolve, just as you thought the job was near complete. I have messed around with Xojo web before but either ended up with ‘string and sticky tape’ or back with desktop and console apps to turn out something that worked in the timescale available. I would like to avoid the outcome where I spend longer trying to get a Xojo web app working robustly than it would take to use a traditional long-winded toolset in the first place.
For those who don’t know I’m a Real Basic veteran who fell out of love during the transition to Xojo. Software development is not my 9 to 5 but more an aside to what I can best describe as a, ‘3rd Line Projects Engineer’ for the last 30 years. I’m reasonably adept at turning out narrow scope, desktop and console apps in a variety of toolsets to carry out socket level network tasks, database tasks and file based data-transformations. After a 7 year break I finally renewed my Real Basic license in 2019 to get the TLS1.2 upgrade, and to be honest was not so impressed with the ‘progress’ to want to renew at the price Xojo Inc are asking.
My client will not hesitate to spring for a new license but Xojo has to deliver what I say it will deliver. However long it takes will be too long.
A method we use in aeronautics when tasked to find out if a product is suitable, is the requirements matrix.
All functionality and properties required are written as lines in a spreadsheet. This is the first column ‘requirement’. Second column is ‘full compliance’, third is ‘partial compliance’, fourth is ‘not compliant’. The fifth row describes the limitations and possible workarounds for partially compliant features. The sixth row contains the vendor statement for ‘can be made compliant’: ‘yes’ or ‘no’. And very important, the seventh row holds the compliance achievement deadline for items having a ‘yes’ in row six.
Setting up a compliance matrix is a bit of work. It is worth the effort because once filled out and all answers provided, it gives a clear view on what you can rely on or not.
Xojo is undergoing the transition from Web1 to Web2, and there have been some rough spots. If you are handy with Xojo, I’d recommend you get the free version and try mocking up some simple Web2 apps - you’ll quickly learn what works vs. what doesn’t.
Web 2 was so bad at launch that I didnt’ touch it for 2 years. I have a new web proyect at the end of the year so this mont I installed 2022r2, made a simple mock up and get 20+ bugs in the basic UI elemnts alone (didnt tested half of the controls, the table is a unusable for me), some others in performance and poor design. already reported on the issues track systems some of them, but being this buggy makes me wonder if there are actually people ussing it. Maybe in another 2 years…
Not at this point
You cant use a real web server, Xojo runs its own. Being xojo a single threaded framework, the server cant use real threads, so in order to scalate, you need multiple instances running and something to balance the load among them. More instances means more resources in the server than with multithreaded servers.
I’m in the same spot, still with 2018 for web and 2019 for desktop. Not worth the upgrade, looks like there was a lot of time wasted on renaming things instead of delivering bug fixes and needed features.
@Mike_D Been there before One thing I have learnt about RAD in general and Xojo in-particular is, test early and test often. To test a web application the infrastructure should be tested at the same time, which entails compiling the code and placing it on a server, IMHO. Access to compiled web applications was the very reason I first upgraded to a Real Basic Studio license and was sorely disappointed. And here I am, over 10 years later with another expensive Xojo Pro license, still waiting for Xojo web to convince me it is more than a toy.
@Torsten_Bernhard Thank you for the clear and honest reply. I’m a little shocked to hear Xojo web is not up to a fairly simple API integration job. I’m left pondering, what exactly is it for? Anyhow, I will not be wasting any more time and go grasp the nettle with a traditional open source tool chain.
I am as baffled as anyone as to the path Xojo Inc have followed. Open Vs Opening…Really(!) I bet that was an interesting meeting. Just glad it wasn’t my subscription money paying for the tea and biscuits.
I did, and I am one myself. Aeronautics is a regulated industry where you can’t get along without such things for certification of a product or part.
The concept and the extend of its application can be adapted to specific needs. Maybe too much for small projects, but essential before big investments and strategic decisions are made.
Sure. Interacting with REST APIs with JSON is something Xojo is perfectly capable. There are a lot of OAuth2 flavors, but once you understand how it works, you can build client and servers with Xojo.
You can scale Xojo either vertically or horizontally. You will encounter the very same challenges as with any other language. Deployment is easy if you want to deploy a monolith yourself, you can also go for the Xojo Cloud as our managed alternative, or even use Tim’s Lifeboat if you want to manage your servers yourself.
From there, if needed, you can containerize your app and deploy it to a Kubernetes cluster. Xojo won’t be a problem in any case, it can grow with your needs and usage.
You can call PHP scripts (or any other executable) using Shell.
PHP normally isn’t used as a web server, you put it behind Apache or Nginx using FastCGI. Xojo apps can act as a server, using ServerSocket. Xojo Web does all the plumbing for you and exposes a framework you can use, it works as a server that you can also put either standalone, behind Apache, Nginx or any other reverse proxy.
I was using ‘entrepreneur’ as a euphemism. I guess they aren’t all sales driven, visual thinkers, with undiagnosed ADSD, a propensity for risk taking and incapable of reading anything longer than two sentences To be fair the up side is being trusted to get on with the job until the day you fail to deliver.
I actually started my IT career working for a software house developing lab management systems when SSADM was a big thing. It’s not that I don’t know how to do a requirements and tools analysis, more knowing when not to. I was a relatively early adopter of OOP and RAD as a means to meet a narrow scope requirement before the need changed.