Business Solutions for Back Office and Web
The future of FileMaker's landscape
Do you remember the days that you had to wait for a new movie or music album to be released? And that you now sometimes spent more time choosing what you want to watch/listen than actually doing so? If so, then you’re probably as old as me ;-)
After my recent discovery of the n8n workflow automation platform, I got the idea of creating a database with all the additional functionally that is available to FileMaker Developers (since that’s what FileMaker developers do :-). But then I immediately realized that this database could not be limited to n8n only, but should also include plugins/extensions, custom functions, ad-ons, etc. It then hit me that, in the meantime, the sky has become the limit and the only thing that holds you back is your imagination. The only real challenge is to find the right tool for the job, which now sometimes takes more time than to actually implement it. Let’s take barcodes for example; these can be generated through plugins, web services via API’s and even solutions build in FileMaker natively, of which Honza’s Koudelka’s ‘scalable PDF barcodes purely build with calculations’ is a masterpiece of it’s own. Another example is PDF’s. Not only is it possible to export information from our database to PDF or get text from PDF into our database, it is now also possible te extract stuctured data such as invoice details. The creativity of FileMaker Developers and plugin builders has already given us a huge toolbox, but by giving us easy access to all the Javascript packages, we finally got the cherry on our cake.
n8n is doing a great job at simplifying the utilisation of these packages and accessing API’s through what they call nodes. By combining these nodes, you can build workflows’. These workflow’s can be started through trigger nodes. And voila! ... there’s your new webhook or micro service. One of the first things I build, was a workflow that fetches a set of data from FileMaker’s Data API and converts it to Excel. The next step was the option to feed in raw JSON instead of getting it from my FileMaker database. More recently, I build workflows that could extract email messages into a JSON array with the stuctured data, such as from, to, date, subject, text message, html and attachments. I’m now using this micro service to archive email messages in a searchable (FileMaker) database.
Most of these modern development tools thrive for easy of use, or no-code / low-code as they call it. This is getting better and better, but in order to enjoy the full potential, I think that it’s currently still important to have basic knowledge of at least JSON, Javascript and cURL. Another challenge is how to keep all these systems up and running and up-to-date. Especially because of the sheer amount of dependencies, or in other word code that rely on other pieces of code that rely on other pieces of code, etc. As I write this, this is still a bit on uncharted territory for me. I’ve started playing around with GitHub and was happy to discover that some of my FileMaker collegues are already using it. My goal is to build a system where new releases can be tested and then be easily pushed to the production environments. I’ll let you know when I’ve found the holy grail ...
And finally, where does this leave FileMaker? As far as I’m concerned, it is still the fastest and most user friendly database application development platform on the market. However, it’s going to be a challenge to decide what to focus on. For example, FileMaker’s WebDirect option is handy when you want to connect to your FileMaker data via a web browser. However, the real web feeling is missing as for one it’s not responsive, and more importantly, it’s not a truly scalable solution. In order to build truly responsive and scalable websites, I’m now using AppDrag. Instead of trying to do it all, it might be an idea to concentrate on strengthening it’s core functionallity, such as custom labels for (Excel) exports, native PDF support, being able to drag files out of container fields into other apps and responsive layouts. Make it the best kid on the block to integrate with other systems. And perhaps consider supporting free (text) coding of scripts so that it’s easier to share them with the community.
After my recent discovery of the n8n workflow automation platform, I got the idea of creating a database with all the additional functionally that is available to FileMaker Developers (since that’s what FileMaker developers do :-). But then I immediately realized that this database could not be limited to n8n only, but should also include plugins/extensions, custom functions, ad-ons, etc. It then hit me that, in the meantime, the sky has become the limit and the only thing that holds you back is your imagination. The only real challenge is to find the right tool for the job, which now sometimes takes more time than to actually implement it. Let’s take barcodes for example; these can be generated through plugins, web services via API’s and even solutions build in FileMaker natively, of which Honza’s Koudelka’s ‘scalable PDF barcodes purely build with calculations’ is a masterpiece of it’s own. Another example is PDF’s. Not only is it possible to export information from our database to PDF or get text from PDF into our database, it is now also possible te extract stuctured data such as invoice details. The creativity of FileMaker Developers and plugin builders has already given us a huge toolbox, but by giving us easy access to all the Javascript packages, we finally got the cherry on our cake.
n8n is doing a great job at simplifying the utilisation of these packages and accessing API’s through what they call nodes. By combining these nodes, you can build workflows’. These workflow’s can be started through trigger nodes. And voila! ... there’s your new webhook or micro service. One of the first things I build, was a workflow that fetches a set of data from FileMaker’s Data API and converts it to Excel. The next step was the option to feed in raw JSON instead of getting it from my FileMaker database. More recently, I build workflows that could extract email messages into a JSON array with the stuctured data, such as from, to, date, subject, text message, html and attachments. I’m now using this micro service to archive email messages in a searchable (FileMaker) database.
Most of these modern development tools thrive for easy of use, or no-code / low-code as they call it. This is getting better and better, but in order to enjoy the full potential, I think that it’s currently still important to have basic knowledge of at least JSON, Javascript and cURL. Another challenge is how to keep all these systems up and running and up-to-date. Especially because of the sheer amount of dependencies, or in other word code that rely on other pieces of code that rely on other pieces of code, etc. As I write this, this is still a bit on uncharted territory for me. I’ve started playing around with GitHub and was happy to discover that some of my FileMaker collegues are already using it. My goal is to build a system where new releases can be tested and then be easily pushed to the production environments. I’ll let you know when I’ve found the holy grail ...
And finally, where does this leave FileMaker? As far as I’m concerned, it is still the fastest and most user friendly database application development platform on the market. However, it’s going to be a challenge to decide what to focus on. For example, FileMaker’s WebDirect option is handy when you want to connect to your FileMaker data via a web browser. However, the real web feeling is missing as for one it’s not responsive, and more importantly, it’s not a truly scalable solution. In order to build truly responsive and scalable websites, I’m now using AppDrag. Instead of trying to do it all, it might be an idea to concentrate on strengthening it’s core functionallity, such as custom labels for (Excel) exports, native PDF support, being able to drag files out of container fields into other apps and responsive layouts. Make it the best kid on the block to integrate with other systems. And perhaps consider supporting free (text) coding of scripts so that it’s easier to share them with the community.
|
|
|
|