FOAM is “middleware” for the web, that is, software whose purpose it is to bridge or glue the various components of a software system together. Typically, 80-98% of the code in most systems is adapting from one layer or library to another: from the server database to the server object model, from the server object model to the network protocol, from the network protocol to the client object model, from the client object model to/from the client cache, from the client object model to/from the the client’s UI library of choice, to/from XML/JSON/SQL/Protobufs/etc. FOAM acts as a universal adapter, so that developers no longer need to write all of that code themselves.

Advantages of this approach include:

1. Dramatically improved developer productivity, as they’re now only responsible for the actual business-logic and unique features of their application, not all of the glue code.

2. Equally dramatic improvement in quality, since all defects which would have been present in that handwritten code are now gone.

3. Better architectural agility. If a better library or approach comes along (like PWA’s for example), then it is easier to adopt by adding it as a generic “feature” in FOAM, rather than having to rewrite existing code. Also, not all adapter code is straight forward copying of data from one API to another. In the case of PWA’s, it’s quite difficult to implement a full offline search plus two-way-sync data-layer. Having FOAM provide a working PWA data-layer for you, makes this technology much easier to adopt.

4. Software based on one universal middleware component, rather than (# data models) X (# of adapters) handwritten components, is asymptotically smaller. We’ve seen FOAM apps which are 100X smaller and 10X faster to startup than the equivalent applications not written in FOAM.

5. The data in FOAM applications is SLICE-able, since FOAM maintains a clear layering which allows direct access to the data itself, rather than hiding it behind an opaque UI.