And this code is, of course, callable from any HTTP-enabled application so FileMaker, although a really good prototyping client, is not required.
There are two big reasons to want to use JS in FM:
1- pure computational stuff, like in your examples
-- data visualization (charts, datatable,..)
-- widgets like sliders, progress bars, bread crumbs, collapsable hierarchies, calendars, photo galleries,...
What you're showing here works well for the first class but not for the second class. And certainly if you already have a web service running that you can add to, then your approach is a good option. And most definitely if that piece of logic needs to be shared across multiple applications (distributed architecture and all that).
The 'traditional' way of doing the same thing natively without outside dependencies is to use the web viewer and that one works for both of those two big use cases. A little kludgy in 13-18 if you want to use it in WebDirect because the return mechanism is a little tricky; but fairly easy to do in Pro and Go.
Our whole Carafe.fm open source library is built to both demonstrate the principles of it and to lower the threshold for developers who are not up to speed on it yet.
Pardon if I'm misunderstanding your posting, but your micro-service can be anywhere: local computer, local network, or, yes, anywhere accessible by URL.
PLUS, when you create a JAR file for your service, sharing is easy. You could email that JAR file to someone else and the JAR file has all the dependencies so someone else could start and use your service separately. Not sure why you'd email the JAR to someone else, but it's really that flexible and easy. (You can also create a WAR file you can install on an application server like Tomcat.)
So, if I understand your posting, no, using a micro-service does not require you be online. Completely flexible where/how you put/use it.
Sorry about the soundtrack. Doing a sound track is easier than spending lots of time narrating, compressing, and getting the narration to sound as good as NPR.
One limitation would be a mobile device, not connected to a server or network of some kind. I haven't seen yet where you can run a micro-service locally on a mobile device, though always happy to be proven wrong there.
I changed the end of the video to say "Micro-services" instead of "Web Services". I think "Web Services" was causing confusion.
Yes, you can, if you want, run your service locally (offline). Or you can host it on AWS. Whatever. Total flexibility. For development and testing, I always run the service on the same machine I'm on. (Mac or Windows, same thing/approach.)
Let's say you build a JAR file called "service.jar". That's a file with all your libs and other dependencies bundled (same file format as ZIP).
To start this service you would type this at the command line and the service would be up, locally, listening at its default port or the one you specified:
$java -jar service.jar
Then your command window would look hung, but it's just the service running. You can minimize that window. You probably saw this in the first video I posted on getting a basic Sparkjava service running.
Or, you can create a WAR file (still same format as ZIP). With a WAR file, you just drop it into Tomcat's (or other App server's) "webapps" folder and it auto-magically "deploys" (unpacks). Using a WAR file, there's no command window and no JAR file needed (but the service is still listening on whatever port. 8080 is the default for Tomcat but you can easily change that in the Tomcat config).
In production, I always use a WAR file. It's the same as a JAR in that it has all the resources and dependencies bundled.
The only external dependency is Java installed on the local computer or server.
I'd really like to make sure I'm being clear so please contact me and I'll help, OK?
Yes... it is just a consideration that sometimes people miss. I agree with you. For some things, I've had it run as an external micro-service, because of performance and universal access...but also included a backup to run in a web viewer if the user wasn't connected.