FileMaker/web integration technology overview

by Beezwax Team
Posted in All, FileMaker

[Authored by Ian]

Doing a Google search for “FileMaker web” brings up a bevy of methods, technologies, and acronyms that all seem to have something to do with making FileMaker available to Web users. What follows is a digest of many of these technologies, based on Beezwax’s extensive experience with them. While all of them claim to be the be-all-and-end-all, we’ve found that many of them are dead-ends. Others are useful, but only in very narrow cases. Hopefully, our experience will help you sort the wheat from the chaff and choose a solution that works for your needs. Be warned, however: there is no silver bullet.

A Basis for Deciding

Before we dive into the acronyms, let’s address the basic considerations for choosing a technology to get your FileMaker data on the Web. Putting cost and feasibility concerns aside for the moment, the basic question that needs to be asked is: who needs to do what from where? 10,000 users in 20 countries doing real-time image processing is different than 20 users in 2 offices viewing static financial reports. These two scenarios illuminate a basic set of technical criteria for evaluating whether a FM/Web integration technology is a good solution for your problem:

  • scalability: can it serve the expected user load?
  • access: where can users use the system from?
  • functionality: what can the users do from each location?

The business concerns I’ve omitted above are actually often the deciding factors. The basic question for business is: show me the money. (Ok, that’s not a question.) Once technical feasibility is established using the criteria above, the question is whether the solution is affordable in the short and long terms.

  • start-up cost: what’s required to get off the ground?
  • maintainability: how much effort is involved just keeping the solution running?
  • extensibility: how easy is to to add new features to the system?

Analysis of costs of each of these points often hinges on availability and cost of personnel resources. For example, if Web developers are cheaper than FM developers you’ll want to optimize the implementation strategy to put the bulk of the work on the Web developers. If you have a really strict calendar, you may want to plan the project such that the most available developers get the bulk of the work, regardless of their cost. This part of the criteria is where the rubber hits the road: it’s dealing with the realities of cost/benefit, developer availability, deadlines, and budgets.

Technologies

Without further ado, here’s a listing of the major technologies used in integrating FM with the Web. Each technology is analyzed using the criteria established above.

Instant Web Publishing (IWP)

01/04/15 – Editor’s note: Don’t forget this was written in 2009. FileMaker Instant Web Publishing was an option all the way through FileMaker Pro v11.

IWP is the easiest and fastest way to take FM content to the Web. FileMaker exports your forms and tables to a basic website. While it may sound great on the surface, the result is inflexible, slow, and clunky.

  • scalability: poor
  • access: we recommend local only
  • functionality: limited to a subset of what FM can do
  • start-up cost: living up to its name, IWP is probably the easiest solution to get going with–not even requiring developers.
  • maintainability: can be done by lay-users
  • extensibility: since what you see is what you get, there’s no real opportunity for adding functionality

Due to its severe limitations, we only recommend IWP in situations where the users are local and few, and there’s little in the way of technical expertise. Given those caveats, there are few scenarios where IWP is a compelling solution.

Custom Web Publishing (CWP)

CWP is another solution enabled by built-in FileMaker functionality. It’s essentially an XML-based API for querying your FileMaker database. FMCakeMix, FX.php, and RFM use CWP as their backend.

  • scalability: a little less than FM itself, due to the overhead introduced by CWP.
  • access: all functionality is usable from anywhere on the Web.
  • functionality: pure CWP solutions are limited to a subset of what FM can do, ie. what CWP allows you to do. This is a severe limitation on a Web stack that would otherwise use MySQL or PosgreSQL.
  • start-up cost: medium if you use a package like CakePHP’s FM driver or RFM. Higher if you need to start from scratch, because CWP is a proprietary and sometimes idiosyncratic specification.
  • maintainability: since it’s a non-standard technology, debugging can be difficult. Business logic may sometimes need to be maintained on both platforms because CWP doesn’t layer CWP over the application layer in a manner that would allow the Web to leverage business logic written in FM.
  • extensibility: since the Web stack and FM share a DB, changes to the data layer are relatively easy. Changes at the application layer will need to be done in both FM and the Web stack as applicable.

CWP is a great solution for small user bases that are geographically distributed and have relatively simple needs. Since FM is the data back-end, you’re limited to FM’s capabilities and performance at the data layer–you won’t be able to use a lot of techniques that are taken for granted in most Web stacks.

Lasso

Lasso, the only third-party propriety solution on this list, is a FM-backed CGI scripting language sold by LassoSoft. While Lasso 9 advertises support for many DB backends, for the purposes of this discussion we’ll only consider using FM. As we’ll see, Lasso’s biggest pitfall is simply its acceptance (or lack thereof) by the community–a problem they’re unlikely to remedy after about ten years wrestling with it.

  • scalability: limited by FM itself, plus whatever overhead Lasso itself adds.
  • access: as a standard CGI, it provides its functionality to any Web user.
  • functionality: the proprietary nature of Lasso of course means you’re limited to LassoSoft’s vision. We haven’t experienced any major gaps in functionality.
  • start-up cost: it’s relatively easy to get up and running with. Of course, if you’re already using a standard Web development language like Ruby or PHP, “relatively easy” is still more than “already done.”
  • maintainability: the most important barrier to maintainability is lack of personnel resources: finding and keeping someone who knows it can be difficult. Lack of large community support can also make troubleshooting difficult. Having a custom language means you won’t be able to leverage innovations like PHP’s Cake or Ruby’s Rails and the maintainability advantages associated with their convention-driven designs.
  • extensibility: provided you have someone who is good with it, Lasso can be quite rapid and elegant to use. Availability of third-party plugins limits rapidity provided by reusing large components.

Using FM as a back-end is already a non-starter for serious Web deployments where thousands of concurrent users need to be served. Even in small-scale cases, Lasso has added complication of being a closed-source solution that’s in direct competition with FileMaker Inc’s own PHP-friendly offerings. The best argument I’ve heard for Lasso is in situations where it already has momentum. In these scenarios the scarcity of experienced personnel has already been overcome, and the prior investment makes it unreasonable to go to a more standard PHP solution.

External SQL Sources (ESS)

ESS is the first technology we look at here that houses the data outside of FileMaker. It essentially allows FM to directly access your Web stack’s database. This can be really useful and easy to setup in some situations, but can cause problems when conflicts arise due to the two applications (Web, FM) accessing the same DB.

  • scalability: decent–since you’re using a SQL DB you can scale it horizontally without FM even knowing. The Web stack doesn’t touch FM, so it can likewise scale horizontally and vertically.
  • access:  due to concurrency, permissions, and validity concerns, we always recommend the shared data only be writable from one place. This means functionality around modifying data is only accessible from either the Web or FM.
  • functionality: ESS does not require any limitations in functionality on either FM or the Web.
  • start-up cost: this solution is one of the easiest here to setup.
  • maintainability: because only the data is synced between FM and the Web, functionality that depends on that data has to maintained in both places–doubling associated costs. Debugging everything at the database level can be time-consuming. Changes to the database have to be accounted for twice.
  • extensibility: application features have to be implemented twice, but data features only need be done once. Data features may take longer to implement because they have to accommodate both systems.

ESS is great in its simplicity and ease of setup. So much so, that we often have to explain why we can’t do everything in ESS. However, after considering the access, maintainability, and extensibility problems we only recommend ESS in situations where data needs to flow in one direction.

RESTful Web Service

In a RESTful integration scenario FM and the Web typically exchange resources using XML over HTTP. The layered nature of REST architecture lends itself well to keeping FM and the Web independent of one another, while well-designed resource APIs map well to FM’s application design paradigm. Web-based vendors (Amazon, Google) are increasingly migrating to RESTful architectures, so there’s a lot of momentum behind it.

  • scalability: at its most basic, HTTP queries for each piece of data can slow down FM. However, the layered design can be leveraged to transparently incorporate caching to make the solution scale quite well. Of course, implementing that from scratch, while possible, is time consuming.
  • functionality: with a well-defined API and SoC, each platform can do what it does best without worrying about the other–making this path the most functional here.
  • start-up cost: with the right libraries (eg. ActiveResource for Ruby), RESTful API’s are ridiculously easy to work with. Unfortunately, such libraries aren’t yet available for FM, making this one of the most difficult solutions to set up.
  • maintainability: since the resources are served through the Web stack’s application layer, business logic need only be implemented and maintained in one place.
  • extensibility: you can add features to either platform without modifications to the other, as long as it doesn’t change the REST API. Changes that do touch the REST API are easy to work on because they happen at the application layer and in human-readable formats like XML.

While a compelling option on paper, the lack of plug-n-play FM support makes this solution only viable in situations where the start-up cost can be justified. If the REST API is needed for integration with other systems (b2b, mobile, etc.), or if the FM app is already accessing web services, this can be a capable and cost-effective option. More advanced FM web client libraries would go a long ways towards reducing the initial costs of REST solutions.

Show Me the Money

The FM-backed solutions, IWP, CWP, and Lasso are mired by problems typical of proprietary application integration solutions: lack of third-party support, incoherence of standards, and performance and functionality limitations imposed by FM itself. While the other solutions have some advantages, they lack ease-of-use within FM, and, in the case of web services, are prohibitively difficult to incorporate into small projects. Furthermore, all the technologies here are point-to-point solutions; we expect them to have significant manageability problems with three or more integrated systems where a SOA solution would be more appropriate. This is fine, given FM’s traditional niche of small intranet applications. For larger systems that are starting to branch out across organizations and the Internet, there seems to be a need for a scalable, standards-based solution that can bring the best of FM to a Web audience.

 

Leave a Reply