At various conferences and blog posts, we’ve been advocating for Distributed Architecture when making architecture decisions for solutions you build.
Consider functionality that FileMaker Pro / Claris Pro is not good at:
- heavy computational tasks
- long-running and resource-intensive tasks that can be heavy on your solution, such as custom PDF generations
- Anything else that can slow your users down
In these cases, deploying a microservice for FileMaker to communicate with in a RESTful way makes a lot of sense.
How to Build a Microservice
Building a microservice is easier than most of us think. When not constrained by a particular tech stack mandated by the client, we tend to use a node.js Express app. An example of such an app is the small service we built to generate a token for accessing the Data API on FileMaker Cloud. You can read about that and download it here: Your Guide to Using the Data API on FileMaker Cloud (soliantconsulting.com).
How to Deploy a Microservice
With VS Code, you can run and test your microservice very easily: for a Node.js app that’s just issuing the npm start command from the command line.
The microservice, however, will only run for as long as that terminal session is active. While that is fine for testing, it is not robust enough for production.
And at some point, you need to deploy it so that it runs somewhere and is available at will.
The tools that allow you to do that are called Process Managers. On the Express website, you will find some of these listed: http://expressjs.com/en/advanced/pm.html
We like pm2 and will use that one for the rest of this walkthrough.
Switch to your deployment machine and make sure you have a working version of your microservice. (The easiest way to do this is to use git clone, assuming your microservice is under git control in a central repository like GitHub). Don’t forget to use npm i to make sure your new installation grabs all the required node modules that you use in your code.
Confirm with npm start that your microservice works and use ctrl-c to exit running mode.
A process manager like pm2 will allow your microservice to run in the background. It will automatically launch it when its host launches and adds features such as automatic load balancing and more.
pm2 can be installed just like any other node package with npm:
npm install pm2@latest -gWith your terminal session on the host, located in the proper folder where npm start works from, tell pm2 to create a new background process for your app. Using the FileMaker ID Data API token app, this looks like this:
The start command is followed by the command that starts your microservice.
The –name option lets you specify an easily recognizable name; without it, your app will show up as “npm start” when you ask pm2 for the list of running apps. The –watch toggle will automatically re-launch the app when you change any of the JS files.
You can always bring up the same UI by asking pm2 for a list of running apps with pm2 list:
If you don’t see all the columns, make sure your terminal window is wide enough and rerun the command.
The important columns to check how your app is doing are the status and the uptime. If your app is down or its uptime is just a few seconds when it should have been up for longer, then use pm2 logs to check for clues. The output shows the last 15 lines from three of the pm2 logs. It also shows the path to these logs in case you see something that needs further investigation.
This is a live view of the logs, so use ctrl-c to exit the view and go back to your command line prompt.
If your host has sufficient resources for the work, you can run multiple node.js apps on the same server. Each would need its own port, obviously.
You can stop the app with pm2 stop dapi_token, and similarly, you can start it again by using its name.
To remove the app from pm2’s control, use pm2 delete dapi_token. This doesn’t remove your app’s files.
SSL Repercussions
Typically, the apps we create in this fashion do not take care of SSL termination; they just function through HTTP.
However, for production use, we do want to go through the HTTPS protocol and a valid SSL certificate.
One way of doing that is to update the app’s code to handle SSL, but that makes it more difficult to manage if you have multiple apps and it is time to renew the SSL certificate.
An easier and more common way is to use a reverse proxy. This is just a fancy way of saying: let an existing web server handle the incoming traffic and the SSL handshaking. Then let it forward the traffic to your microservice when necessary. 
Setting up a reverse proxy using nginx is detailed in this blog post. In a separate blog post, we will show how to use reverse proxying in IIS.
When to Leverage a Partner to Deploy a Microservice
When working custom development into your FileMaker applications, it’s best to work with an experienced partner. Our team has a deep bench of both FileMaker and web development experts who work together to deploy microservices for our clients.
If you have any questions about how to deploy a microservice, how they could work for your business, or how we could support your business in building one, please contact our team.
I’ve never understood the widespread fascination with microservices. I’m not saying there’s no circumstance where they might be appropriate, but generally, with the incredible flexibility FileMaker offers all by itself, I find creating and maintaining external microservices adds a great deal of additional complexity, introduces greater fragility, external dependencies, greater maintenance & admin needs, and reduced solution portability, plus extra hosting and SSL and/or proxying concerns, as well as needing the developer to be a node or java programmer in addition to being a FileMaker developer, all often in exchange for trivial functionality that could be done within FileMaker with almost the same amount of work and without all those extra concerns and hassles.
It may be that there are odd things here and there that FileMaker is so “bad at” that it clearly merits all the extra development time, resource consumption, and additional dependencies that come with a microservice-based solution, but in nearly 30 years of developing for FileMaker, including a vast panoply of integrations and calculation-intensive applications, I’ve never once run across one.
Microservices are an interesting thing to know about, and if it came up as a topic of remote interest every once in a blue moon I’d say that’s justified, but I don’t see them as much more than a minor curiosity. I can’t understand the years-long apparent obsession with them in the FM Community forums… I’ve actually at times been tempted to preemptively include “no answers involving microservices, please” in my questions in the FM Community forums, because they are so persistently volunteered as a solution to seemingly every problem, when in fact they only rarely, if ever, are a good solution.
I’ve always felt adding additional infrastructure requirements should be avoided unless there’s a very compelling reason, and while those situations may on occasion exist, I’ve never run across one.
I haven’t looked at your token generation example but I know I’ve done full-blown oAuth management entirely within FileMaker without any more difficulty than doing oAuth token management on any platform (which is always a pain, but it only needs to be written once.) It’s completely portable and can be used in any solution, all I need is the individual FileMaker oAuth management file, and it runs easily on a laptop. Having to host a microservice to run it would have made it more complex, more fragile, and non-portable, as well as taking longer and being harder to implement and maintain. I just don’t see the advantage.
Hi Theodore,
Thanks for adding your perspective.
A big reason for these blog posts is to demystify and debunk some of the concerns that you are voicing. In this era where more and more FileMaker developers acquire some JavaScript skills to use the many features that the FileMaker platform makes available through JavaScript, and given how many of us do API-driven integrations to a wide variety of services; the jump to setting up your own custom APIs is a small one and it is easier than ever before. Hosting is seldom an issue, there is no need for extra SSL certificates and while using a distributed architecture approach does add dependencies to a project, so does using plugins, an add-on or adding an extra FM file to a solution.
We don’t advocate for using micro services just-because-you-can, it will always be a careful weighing of all the options. But there are a vast array of problems that are already solved elsewhere that you can plugin into with this approach instead of rewriting them in FM. And we see a lot of solutions that are struggling with performance where easy and substantial performance gains can be had.
Best regards,
Wim
In response to Theodore….. I have a use case of a client needing to update FM data from excel workbooks many times/week– often with up to several million records….
Fm is just too slow unless you can have the workbooks match fm fields and use the native import process- since setting fields for that many records is not tenable.
js libraries can update the excel in a flash and then you can have matchable excel columns….
not sure there is a way to do this without an external app.