Notes on FileMaker Part 3
While I've emphasized FileMaker's limitations in SQL-like features, there are additional concerns that make it a rather tough choice.
Integration and API capabilities
- FileMaker supports basic REST API calls, but it often requires awkward workarounds or third-party tools to handle complex integrations such as OAuth and nested JSON.
- Most integrations rely on scheduled scripts or polling, which can be inefficient and potentially lead to data lags.
- Integrations with services can come with additional costs.
Cross-platform support and mobile functionality
- Complex solutions might not function as expected on mobile. UI/UX can be clunky without significant optimization for small screens.
- FileMaker WebDirect offers web access to solutions, but it's notorious for its sluggish performance and unreliability. It struggles with heavy use and falls short of the smooth experience and broad compatibility offered by modern web applications.
Development workflow
- On top of the lack of robust version control, FileMaker development often takes place directly in the production environment, which is more than risky.
- FileMaker's script workspace lacks true modularity, making complex applications difficult to manage and maintain. Code reuse is challenging, while refactoring scripts is time-consuming and error-prone.
Scalability and performance
FileMaker’s flat-file structure doesn’t handle large datasets well. It lacks the ability to scale. I've elaborated on this extensively in previous notes.
User interface
- FileMaker’s customization options are limited, comparing to web frameworks. There’s no support for advanced animations, responsive design or CSS. In other words, it’s hard to create applications that feel contemporary.
- The user experience varies significantly across different platforms. What works on desktop might not translate well to WebDirect.
Maintenance
- Frequent manual backups are needed. It becomes a manual task due to the absence of automated backups support outside of FileMaker Server. This can be error-prone, especially when you have multiple FileMaker solutions to manage.
- The process of data migration and updates is manual and complicated.
- FileMaker’s subscription model can get expensive, especially if customizations require a certified FileMaker developer for ongoing support.
Vender lock-in
- Once you’ve invested in FileMaker, you’re locked into Claris for updates, compatibility fixes, and support. Migrating to another platform is costly and time-consuming since there’s no easy way to port FileMaker’s proprietary scripts, layouts, and data structures elsewhere.
- FileMaker solutions can’t easily be repurposed or deployed on other platforms without major re-engineering. If the Claris ecosystem doesn’t meet your needs, you’re left with limited options for reusing your investment.
Issues that developers should think about
- Complexity can’t be erased. You cannot get things working the way you want without understanding the logic, data structure and workflows. Hiding the complexity behind any No-code platforms would probably leave you a massive technical debt.
- Debugging.
- Non-standard scripting. FileMaker’s scripting language is specific to its environment and does not follow industry standards, that is, the time you invested learning it doesn’t carry over to any other programming languages or systems.
Learning SQL, JavaScript, Python, or even using Excel for data manipulation provides you with skills that are highly transferable to other platforms and tools than this.
Summary
It all comes down to “why not learn and write real code” and “why not use dedicated SaaS”.
I understand that there are companies and organizations that have been using it for years and the whole “if it isn’t broken” mentality. But hey, you should’ve known better.
The term “no-code”, same as “AI-powered” hype, is often more of a marketing ploy than a reality. Those tools do help with accelerating processes and routine queries handling, if used properly. From a developer’s perspective, no-code solutions are at best useful for quick early stage prototyping, but they rarely substitute for the flexibility, control, and scalability that true coding offers. The realities of software complexity, performance requirements, and integration needs make it clear that no-code solutions are often insufficient for serious applications.
After all, no tools can replace actual expertise.