Running JavaScript from FileMaker (v.13-18), or from any HTTP-enabled application

Not sure how folks would want to use JavaScript in FileMaker, but the video below shows how I implemented running ad-hoc JavaScript -- right from a FileMaker field with no web viewer requirement. And, you only need FileMaker 13 or later. No need to do an upgrade beyond version 13 to run JavaScript.

To call the micro-service method (aka, function), you'd only need to encode and pass the text field with the JS code to the micro-service method. The code for running JavaScript is easily searchable and really only a few lines of code. :sunglasses:

And this code is, of course, callable from any HTTP-enabled application so FileMaker, although a really good prototyping client, is not required.

Happy Coding! :slight_smile:

3 Likes

There are two big reasons to want to use JS in FM:
1- pure computational stuff, like in your examples
2- UI:
-- 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.

3 Likes

Agreed, you're #2 above -- the new FMP 19 UI stuff looks like it will be great.

Thanks Wim.

great stuff as usual (besides the sound track :slight_smile: ) but requires being online? I am excited about FM19 since it doesn't .. THANKS

1 Like

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.

Thanks

1 Like

thanks for answering - so in other words it would run offline? or do I have to run on same offline-machine the web services within whatever serves it?

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?

Thanks!

1 Like

wow thanks again! I am old-fashioned - prefer if things don't break when the internet is down ..

2 Likes

micro-services are for you then! :slight_smile:

no not really - you don't know me :wink:

1 Like

HA! Only based on your stated constraints ("prefer if things don't break when the internet is down").

LOL

A mobile device can't run a service locally that I know of. But, connected via WiFi, it could still access a micro-service. Same as another other Internet connection in that case.

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.

1 Like