Amorphic is a front-to-back stack composed of five separate components, each of which could stand on its own:
SuperType is a type system for building a model using classical inheritance, mix-ins and composition.
Bindster, connects your object model to your markup and functions as a bi-directional template.
Semotus synchronizes objects so you can make calls between browser and server transparently.
Persistor lets you serialized to and reconstruct objects from MongoDB.
Amorphic pulls it all together in support of a model, view, controller paradigm that spans browser and server.
The goal of Amorphic is to let you focus on the logic of your application with minimal regard as to where your code executes. You use the same objects on the browser and the server, making calls seamlessly across the browser/server border. The state is synchronized to create the illusion that you have a single environment.
When you need to persist your objects you use Persistor which maps complex relationships to collections, managing foreign keys and cascading references to objects. This means that the relationships you create between objects can always be serialized and reconstituted declaratively rather than through code.
On the browser, Bindster glues the object model to your HTML mark-up in a bi-directional fashion. It extends HTML to support what is functionally equivalent to templates. Bindster is tightly coupled to SuperType such that validation, formatting and values for multi-value properties can all be defined in your object definitions.
Amorphic is complete enough to write real applications but falls short in terms of documentation, tests and diversity of use-cases. I am looking for early adopters and anyone willing to contribute to the project. At work we have started working on several new applications and have already had applications in production using the framework.
To make sense of it all we have a reference application which is a simple trouble-ticket system on github at https://github.com/selsamman/amorphic-ticket-demo. This illustrates complex data-base relationships, validation, security aspects such as authentication and registration yet keeps things simple and focused. In the next series of posts I will explore this application in detail.
These are the principals that guided the conception and implementation of Amorphic:
Minimal Structure – The only real structure imposed is that all objects must be defined via SuperType and that all objects to be transported and synchronized must hang off of the controller, directly or indirectly. You can structure the application itself including the routing however you like. We like to put as much as possible in the object model but you get to decide that for your project.
Single Page Apps- While oriented towards a single page application, Amorphic lets you break out pages when you want a search engine to see one specific page for a given URL. Because the state is always available on the server when you arrive on a new page your full state is preserved and you wake up where you left off.
Session Based – Amorphic is built with traditional applications in mind and so sessions are rigorously isolated with sharing achieved via the database. When you scale to multiple servers, the session needs to represent the complete state of your application so REDIS can do its magic. Amorphic is built on XHR calls though a socket IO pub/sub will eventually be layered on top for applications that need real-time channels.
Security– Because Amorphic is a new paradigm that is not based on form posts or RESTful. we provide ample rope to hang yourself with in terms of security. While you can’t just save or delete an entity from the browser you still need to think about security. Over time design patterns will mature so that you have to think about this a lot less. In the meantime, Amorphic itself has the building blocks needed to write a secure application. This includes validation at the object and property level of data going to the server, preventing secure data from leaking back to the browser and restricting properties around which you have business rules from being modified other than on the server.