FileMaker Pro/Rails integration methodology

[Authored by Ian]

Here’s a synopsis of my findings on integrating Rails with FMP.

Goals:

• allow two-way data transmission between FileMaker Pro (FMP) and Rails
• minimize development time required for both FMP and Rails
• accommodate as many clients (which may be another application written with FMP, Rails, or anything else) as possible

Given these requirements the best solution I’ve found thus far is a RESTful XML interface with format translation provided by XSLT.

Why REST?

REST is a simple, standard, interface specification: once you know one REST interface, you know them all. Cleaving to RESTful recommendations aids the development of design patterns that help us reduce development costs when creating more than one interface. REST is well-supported by Rails, making it the fastest way to expose a database object to both human and machine clients. REST is a very simple specification, and is supported by almost all potential clients, including FMP (with the WebServices plugin, AFAIK).

Why XML?

XML is one of the most used, best proven formats for machine clients communicating over a network. While there are many valid criticisms of XML (see below), it is nonetheless standard and something almost every programmer is familiar with. There is a plethora of tools for working with XML in almost every computer language.

Why XSLT?

Rails expects its XML in one format, and FMP outputs its XML in another format. Rails or FMP could be altered to work with the others XML format, but this would pollute the codebase with client-specific concerns, the complexity of which grows to unmanageable levels when supporting more than one client. The solution is to create a translation layer that converts FMP’s XML format to the one expected by Rails. XSLT is the W3C recommended way of doing such a translation, and it is a very easy solution to implement. By keeping XML translation in a separate translation layer, it’s easy to meet the demands of new clients without introducing additional complexity to either Rails or FMP.

REST, XML, and XSLT are industry standards, are well supported, and are well understood by developers. While there are many ways to approach Rails/FMP integration, my recommendation is, perhaps, the lowest common denominator–allowing integrations to be rolled out with a minimum of effort and training.

There are, of course, situations in which my recommendation is not suitable. The main drawbacks I see are:

• Network bandwidth and latency: applications that require high-performance integration may find that XML over HTTP is too slow
• Scalability of default Rails XML parsers: I’ve experienced very poor performance using Rails’ built-in XML parsers with very large XML documents (+100MB). Applications that transfer large documents like that may need to implement custom XML parsers, which reduces the productivity gains provided by using Rails’ vanilla behavior
• Inadequacy of the XML standard: XML is widely criticized on many counts. Despite its many shortcomings I still feel that it is the most standard, suitable solution for this particular problem. Special cases may require the use of JSON, YML, or some other data format, which all can still easily be used with Rails’ RESTful API.
• XML support within FMP: while FMP has support for XML, it is sometimes slow, cumbersome, and poorly understood by FMP developers. These are all important problems, and in some cases may warrant the selection of another solution. For the most part, however, it is my opinion that if a FMP application needs to communicate over the web that it should use web standards, rather than requiring Rails to use FMP-specific standards. Following web standards will allow development work to be easily reused with other FMP clients as well as other non-FMP clients. Following FMP-specific standards often requires additional coding for every client, which can significantly increase long-term code maintenance costs.