Login if you already have an account



Create a new account. join us!



Need some help? Check out our forum.

February 19, 2013 kevin nickels

FYI – FatFractal provides an amazingly flexible event model for your business logic (when foo changes, do bar)

As a developer, I want to be able to create business logic for my backend using a language that I am familiar with so that I can quickly implement my solution without having to learn something new.

I must confess that this is one of my favorite things about the FatFractal platform. Essentially this involves an amazingly simple method for creating business logic on your backend and I hope that you will find the freedom and flexibility as convenient and useful as I do.

Business Logic

I am used to creating object classes on my backend, and then writing lots of inline business logic to manage my objects (data). I would create actions like createOrder within which I would do all kinds of things like validation, notification, etc. within each one. All fine, but requires lots and lots of code, a lot of discipline to ensure consistency as well as to avoid overloading any particular function with too much cruft.

So now, Backend as a Service provides good CRUD methods making it easy to persist your data to the backend, but most leave a * huge * amount to be desired in terms of implementing business logic on the backend, relegating the developer to dealing with in the client code causing bloat, poor performance and data reliability concerns.

Maybe there is a better way…

As Gary writes in his blog about the origins of NoServer -

“The cloud should:

  • Store and retrieve my objects.
  • Securely – permissions and security should be robust and at a fundamental level.
  • Efficiently – with easy to create queries that get me what I want.
  • Execute code on the backend when my data changes (events).
  • Not prevent me from doing anything else that I want to do.”

Event Handlers/ User Stories

With FatFractal’s Event model, I am now free to define discrete pieces of functionality that are bound to events generated as my data “changes”. All together, they define my business logic for my application backend much easier than ever before.

This means that I need to think about things differently in terms of how I architect my code. The good news is that, if you are a fan of user stories as I am, then this you will find it interesting that this maps really well for those that can be implemented on the backend. You can literally implement one-for-one against user stories. It also means that I can implement my business logic with amazingly little code – very cool!

For example:

As the administrator of foo, I want to make sure that all requisite info is present before I store an Order so that I do not have a lot of zombie orders in my data.

exports.validateOrder = function() {
var order = ff.getEventHandlerData();
if (!order.amount || (order.amount <= 0) {
throw {statusCode:400, statusMessage:'An order amount greater than zero is required'};

As a vendor, I want to be alerted via email when an Order greater than $5000 is received so that I can be glad that I started this business afterall.

exports.alertBigOrder = function() {
var order = ff.getEventHandlerData();
if (order.amount >= 5000) {
var user = ff.getObjFromUri("ff/resources/FFUser/" + order.createdBy);
var name = user.firstName + " " + user.lastName;
var msgSubject = "Woo Hoo - you got an order for " + order.amount;
var msgString = "Order " + order.amount + " was created by " + name;
        ff.sendEmail ({
            host: "<mailserver>", port: "<port>",
            auth: "<true|false>", authPort: "<port>",
            username: "<username>", password: "<password>",
            from: "<fromAddress>", to: "<toAddress>",
cc: null, bcc: null, // included for completeness
            subject: msgSubject,
            text: msgString,
html: null // included for completeness. When supplied, the HTML message is
// sent, the text is also included as fallback if HTML viewing
// is not enabled in the receiver's email client

Controlling your Event Handlers with FFDL

You have complete control over how these events are handled (SYNC (PRE or POST), ASYNC) as well as the order in which things are executed using FFDL (what’s this?). So to define the two functions above in your FFDL, you just add the following:

CREATE HANDLER validateOrder PRE ON /Order CREATE AS javascript:require (‘scripts/MyEventHandlers.js’).validateOrder();
This means that the validateOrder() function will be called when a new order is Created, but before the Order is actually stored (PRE). This ensures that the order has all the requisite info and prevents storing zombie orders.
CREATE HANDLER alertBigOrder ASYNC ON /Order CREATE AS javascript:require(‘scripts/MyEventHandlers.js’).alertBigOrder();
This means that when a new order is Created, an alert will be sent via email Asynchronously, but only after the PRE event is cleared.

So – there you have it! Events makes it really simple to visualize and implement your business logic with simple functions that are easy to create and maintain. While this makes it really easy to do many, many things – there are some things that need even more, and that is where Server Extensions come to bear. Will post about those soon.

Happy coding!


For more information about Event Handlers, see here.

For more information about FFDL, see here.

See Gary’s blog post about the origins of NoServer here.

Tagged: ,

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>