The result is that more developers are very familiar with hooking up their FileMaker solutions to an external API. We use ‘solved problem’ integrations to integrate with other systems with specialized functionality. In the last five years, we have seen a definite shift away from making the FileMaker solution do everything to let the FileMaker solution do what is special and unique to the client’s workflow. Consider QuickBooks or email and calendaring platforms such as Office 365 and Gmail or document management systems like Box.com, OneDrive, and Google Docs. Very often, we already use API integrations from inside our solutions to talk to other systems. We can also consider using custom API, which I believe we do not do enough. And more recently, we can consider using JavaScript functions inside a web viewer. For functionality that the platform does not natively have, we generally tend to think about finding a suitable plugin. Fortunately, the platform is wide and deep, so usually, that is exactly the way to go. Why Microservices?Īs Claris/FileMaker developers, we tend to limit ourselves to trying to solve problems with the tools in the platform. Distributed Architecture, making the case why you should consider using an API-driven approach to make your Claris-based solutions better, faster, more scalable, and more resilient. Earlier this month, I spoke at the CQDF conference on The Monolith vs.
0 kommentar(er)
