I'm curious what folks do to ensure that the WEB Core app will work with their back-end service? My service is built using XData, but that shouldn't be much of a factor. I finally got the service running on a remote Win Server host, and it's got an old version of the service on it so I know it won't run with the latest client, so this got me curious. I can think of several ways, but I'm curious what others are doing.
Might depend on how many client apps are impacted and how much control you have over them, and as a result, whether old versions need to be accessible.
One common approach is to include different versions of service endpoints. "getdata_v1" and "getdata_v2" for example, when major changes are made and there are many clients that might break as a result of the change.
Another is to have an "info" endpoint or another HTML page somewhere that returns a version identifier. The client can be coded with a "minimum" or a "maximum" server version requirement. It can then check the server-advertised version and see if it is compatible.
There's also the question of what to do about out-of-date clients, particularly PWA clients that don't like to update themselves. In the Actorious project, for example, the latest client version identifier is 'published' in a way that the client can access, so it can check and see if it is the latest version. If it isn't, it does some rather cryptic reset shenanigans that force it to be updated to the latest version. Fun times when the service advertises a client version that is later than what the client can download 
but otherwise it is a way to help ensure that clients and servers are in sync.
Well, as a web app, people will go to a URL to run it, right? It can always be kept current.
It seems easy to keep the Service so it's backward compatible, but if I add a front-end feature that requires new support from the back-end, then that could be a problem if they get out-of-sync for some reason.
Also, I'm unclear how to go about testing new features that require both to be updated. Maybe as long as nothing breaks in the Service with the current Client (since I would have only added one or more new services to it that the current Client doesn't know about), then I can run a NEW Client from somewhere else for testing purposes.
Maybe have an endpoint that returns a list of functions with update timestamps and/or version IDs when they were last changed? But maintaining them manually could be problematic. Another reason to allow separate compilation of methods in the same class... (Actually, I recall seeing a solution to that somewhere once, but I forget the details as well as where I saw it. I think it was an interface unit that was defined in such a way that allowed one or more specific methods to be implemented in their own separate units. I guess that would work with some kind of registration mechanism to override mandatory implementations somewhere.)
Things can get complicated quickly.
I mentioned the PWA thing because it is an example where the current version of a website might not be the version that someone is using. PWAs walk and talk like regular websites, but often they are cached aggressively, to the point where they don't check if the website is different. This is partly how the offline mechanism works - it has everything it needs without ever talking to the website, so it might simply choose not to, and then doesn't know that the website has been updated. So you have to gently coerce it with a 2x4 to get it to update itself to what is on the website.
The same can happen with a regular non-PWA website as well, where the underlying JavaScript file is cached, so it doesn't get updated when the site changes. One way around that is to include a suffix in the Project.html file so that it breaks that cache. Another is to simply turn on the TMS WEB Core project versioning, so the JavaScript file itself has a different name after each build. Different approaches, different tradeoffs.
The information service might be a good place to advertise the available functions and even their versions, depending on how fine-grained you need it to be.
Another option is to just be careful when accessing certain endpoints to check that they succeeded. If you get a 404 error when accessing them, then perhaps the client is newer than the server and you could post a message or deal with it however you like.
1 Like
Working with WEB Core has really raised my awareness of both caching and CORS issues. I've implemented some of my own caching to reduce unnecessary calls to 3rd-party services. But I've been bitten by unexpected cached files. That doesn't happen on typical desktop apps.
So far I'm not working with PWA apps yet. Trying to avoid it, actually.
But if I start using Melitus or Electron, then this could become a real problem.
1 Like
Miletus and Electron work a lot more like a traditional VCL app in terms of versioning and that sort of thing. The entire HTML website is embedded directly in the app, so not really any caching to worry about (or, another way to think about it is that it is permanently cached, so you always have to worry about it), but certainly an issue with older versions laying about because the actual EXE will need to be updated, just like with a VCL app. Fortunately, TMS offers tools to help with that aspect.
PWAs are great when you want to get closer to that "native" app experience, primarily on mobile devices, with home screen icons, no browser controls, and so on. Not 100% there, but pretty close. Or when you want your app to work while not connected to the internet for whatever reason. The headache comes with how different environments cache PWA data differently. iOS has been notorious for not updating the PWA when refreshing Safari or when using an icon on the home screen. Hence the shenanigans to force it into submission.
We have a very strict release process - a client can't be issued if it relies on a server side change that hasn't been implemented.
We also use feature flags (in case we absolutely need to do a client release becuase some features are complete), so the client can ask the server: 'do you implement this?' before showing the menu option etc.
1 Like