[Authored by Ian]
This was the first of several articles around 2009 on designing and implementing FM/Web integrations. Some methods are outdated, but we’ve kept them on our blog because we like some of the general approaches described.
One of the basic questions when considering a FM/Web hybrid solution is how FM and the Web will relate to each other as clients, servers, or peers1. Each possible architecture has characteristic strengths and weaknesses.
A client is essentially a front-end to a server. It relies upon the server to house and process data, and does not share its resources with any other nodes (nodes are any other entities) in the network.
Conversely, a server’s main purpose is to share its resources with its clients. It should be the location of any data and logic that is needed by more than one node in the system. The server holds authority over the clients; its data and logic are always assumed to be the most correct and up-to-date.
Peers in a network share resources and authority with each other in a flat, non-hierarchical topology. Rather than having a central server that dictates decisions, peers arrive at decisions through negotiation and consensus (e.g., data synchronization). Peers may also duplicate code and data for purposes of redundancy or performance.
FM and the Web can both fulfill client, server, and peer roles. Choosing an architecture is based on an understanding of the existing system (if any), what the immediate needs are, what future needs may be, and what resources are available for meeting those needs. It may be tempting to find a solution that will accommodate any possible future needs, but the upfront costs of such a solution may be prohibitive, even if the long-term maintenance and extension costs are lower.
For instance, peer-to-peer (P2P) architectures excel at scaling beyond two-node systems because inter-node negotiation only needs to be addressed once–while a client/server model will require a client/server relationship to be implemented between every two nodes in the system, increasing complexity. While P2P architectures scale well and are easy to maintain, they can be difficult to implement in the first place. In cases where there will only ever be two nodes in the system, a P2P architecture may not be useful enough to justify its high startup costs.
In designing the architecture it’s important to delineate what functions each node is intended to perform, and to maintain a separation of concerns (SoC) in the codebases of each node. SoC is an important and well-established principle of software design that seeks to minimize overlap between features of a system. Improper SoC can have a variety of negative effects on a system, including duplicated effort in implementing modifications, and requiring developers to have special and unnecessary knowledge of features. These effects translate to increased costs maintaining and extending the system that can potentially swamp a project.
In practice, it’s rare to see pure client/server architectures since FileMaker and Web systems are very closely integrated and dependent upon one-another. As such, most FM/Web integrations share attributes of both client/server architectures and P2P architectures.
Examples
Let’s take the example of Widgets Pty Ltd., a widget manufacturing and sales business.
FM server, Web client
Widgets Pty Ltd. has all their inventory in a FileMaker system they’ve been using and loving for years. All of their business is bulk orders that are specially arranged for each customer; they don’t sell Widgets at a fixed price, so they’ll need to talk to the customer on the phone to arrange the sale. They do, however, want to use the Web to refer customers to hi-res images and specifications of the widgets they’re selling.
The Web interface need only provide customers with read access to the widgets. Since nothing can be changed on the Web, FM can be assumed to always have the most current data. We can easily setup “shadow tables” in FM using ESS. Anything that goes in these tables will be immediately propagated to the Web for customers to view. Meanwhile, we can leverage FM’s facility with rapid development to keep maintenance costs down. We can leverage the Web’s scalability to give hundreds of customers access to the information they need, quickly, and without affecting performance of the FM app.
Web server, FM client
Let’s say Widgets Pty Ltd. needs customers to be able to order widgets online, and they need traveling sales associates to be able to manage inventory from the road–both needs that a Web application is suited to serving. However, their Widget Creation System is written in FM, and they need to be able to update the Web application with cutting-edge new widgets on a daily basis.
Most of the data can live on the Web where it’s easily accessible to customers, sales associates, and administrators alike. Since the Widget Creation System is working well, would take a lot of effort to rewrite as a Web app, and has a clear SoC from the Web app, we’ll keep it in FM. When a new widget is ready to be sold online, a FM user clicks a “publish” button and the widget specifications and images are uploaded to the Web app over a standard REST API. The Widget Creation System downloads sales statistics for each widget using the same API and stores them alongside each widget’s design so that widget engineers can modify their designs based on the sales stats.
Web peer, FM peer
Widget Pty Ltd. has a robust b2c business, and has recently started selling widgets in bulk to several resellers. The b2b customers are handled very differently than b2c customers, so they decide that they want a whole new system for serving b2b. The b2c Web system allows customers to buy widgets online, but they deal with each b2b customer on an individual basis so they’ll invoice b2b using FM. However, they need all their sales information (b2b and b2c) in one place for aggregated analysis. Meanwhile, all three systems need to have up-to-date information on inventory at any given time.
Since FM is good at reporting and already has sales info for all the b2b customers, we’ll use FM for sales analysis by making it download sales information from the b2c application. Every time a sale is made in FM or on the b2c system, they update the other systems’ inventories. We can simplify the problem by using a unified RESTful synchronization layer that negotiates between the nodes. This way, if we later want to add sales to the b2c system, the functionality already exists to allow it to modify inventories.
Footnotes
- It’s important not to confuse the nomenclature of “clients,””servers,” and “peers” with their more vernacular usages. Some people think of a server as a big box whirring away in a closet, and clients as end-user terminals. In the general senses of “client” and “server” I’m using herein, they all denote back-end servers to which end-user clients may or may not connect. When I’m speaking of an end-user client, I’ll specifically say so. Likewise, by “peer,” I don’t mean Napster or BitTorrent clients; I mean a member of a network that acts as both a client and a server.