Escaping Low Code

For the last two years I've been helping a company with modernizing their in-house application built on top of a Low-Code platform called FileMaker.
Low-Code platforms provide the ability for non-tech businesses to slightly update their application without asking the help of a professional developer.
But they provide only a small subset of features compared to what you would be able to make by building your own product with a traditional programming language, this makes it hard to build complex user experiences.

Thankfully the devs did realize these drawbacks and created some escape hatches.

Layout problems

One of the big disadvantages has to do with the positioning of layout elements and more specifically how they behave when the window changes dimensions.

A FileMaker window has a native size and will create a scrollbar if you shrink it more that that, what happens to the elements as you expand the window depends on each element's anchor points.

You see in FileMaker you can specify the anchor point of each element individually, one anchor per side, four in total, the opposite sides work in conjunction to determine the size of the element.

• When 1 side is checked:
  The element will remain at the same distance from the same side of the window as the checked one as it was at native size.
• When 2 opposite sides are checked:
  Those sides of the element will stay where they were placed at native size growing its width/height by the same amount as the excess window size
• When 0 sides are checked:
  The excess size will be divided by 2 and added to the distance the element was from the sides of the window

This might sound all well and good, but what happens if I want, let's say, 2 even columns?
As I said before the elements are sized individually so the left one will just overlap the right one when it gets big enough.
That's just not what you want, ever.

This is why, sometimes, when I really need it, I will will use a Web Viewer.
A Web Viewer is just a browser embedded in a FileMaker application, on a Mac that means it's basically an instance of Safari.
That means I can create a little HTML page as a string, like you would when using a programming language on a server and use CSS and Javascript to do whatever I need!

Iterfacing with the OS

Another method to squeeze out more functionality out of FileMaker is to use Applescript (MacOS only) which allows you interface with other programs on the system and access Apple provided Frameworks.

I was tasked to make a generator and verifier of the Italian Fiscale Code (Codice Fiscale). The generation was easy to make using a FileMaker Script but sadly the Agenzia delle Entrate is the only one allowed to say for certain a code is in use for the person we want to check.

Now they don't have an API endpoint to easily check, that would be too convient, but they do have provide a form you can fill out on their website.
So I created an Applescript that would ask the browser to open that page and run some Javascript to fill the fields of that form automatically from the information that was stored in FileMaker.
Now the users can just press one button and instantly verify the Codice Fiscale, it would have been impossible with just FileMaker.

Another time I was asked to interface with OpenAI's API enpoints, that wasn't much of a problem because FileMaker has a script step for calling a stripped down version of curl, which allows me to specify authorization headers and send files/json data.
The problem arose when I discovered the API did not support receiving PDF files, that's really inconvenient for us because FileMaker has container fields that can only contain one file at the time and the scanner we use can only stitch pages together when outputting PDFs not JPGs.

Thanks again to Applescript I was able to leverage some Apple Frameworks available in MacOS, namely PDFKit and Core Graphics, to stitch the pages myself!
Now they can continue using their normal PDF workflow and also harness the power of the API.