Andalay.js is our latest open source library to aid with the creation of an easy to use model layer in client side Angular js applications. It essentially creates a similar interface to that defined by Backbone.js however it is optimised for use within Angular applications. Using Andalay vastly reduces boilerplate controller code for managing data requests […]
Andalay.js is our latest open source library to aid with the creation of an easy to use model layer in client side Angular js applications.
It essentially creates a similar interface to that defined by Backbone.js however it is optimised for use within Angular applications. Using Andalay vastly reduces boilerplate controller code for managing data requests and syncing with the server.
With modern web applications often the client side browser is responsible for most of the rendering of the UI. With the server providing only the data as simple data types such as json.
The tendency when using tools like Angular is to keep all this logic in your controllers. After all most of the time we are just doing a simple http call and passing some data over the wire and then updating it on a successful response from the server. But it is still repetitive and adding unnecessary bloat to controllers, also inevitably this starts to grow in complexity linearly as the complexity of the app increases. Controllers are responsible for linking data to views, they should not really understand this data, or know how to manipulate it themselves. Instead they should simply defer to various objects that know what to do. Like the “Fat Controller”, tasks come in, and he simply tells other people to go and do stuff with it, but has an uncanny skill for selecting the appropriate person for the job. I guess that is why he is fat, he never gets involved with the heavy lifting himself!
Managing it in this way encourages the creation of sensible object interfaces and decouples these interfaces from potentially complex interactions that your controller handles. Many problems in computing are solved by adding a layer of indirection (apart from the problem of having too many levels) and the controller is exactly that, between the data and view (of that data).
We now use Angular for most client side projects. However Angular does not provide any additional libraries for managing models of data, it leaves this up to you. We are left on our own kids.
Feeling very happy one day using Angular’s magical view updating abilities but missing the convenience of a model layer like Backbone provides we decided to roll our own. Mainly because existing implementations either favour tightly coupling to a RESTful backend or are very basic. Also I believe that rolling your own helps you really understand a problem deeply and the knowledge you gain from the exercise is far more valuable than the time you may have saved using someone else’s implementation, (there are always exceptions to this rule, and it could probably fill another blog post. I wouldn’t for example decide to build an SQL database from the ground up). Plus there are some huge advantages to be had by creating standard ways to do things between a server and a front end which you can improve upon over time, I could go off on a tangent here talking about all the many different implementations of Rest-(like) interfaces without worrying too much about general use cases. Rest-like-type-ish are all the rage however keep one eye on DDP spec, meteors standard as websockets become more ubiquitous this would be more desirable a behaviour, especially for real time collaboration apps. It would be excellent to have a backend that supports this whilst maintaining your client side model layer. Currently Andalay assumes you have a simple Rest-type interface. However it does not lock you into this, as you could write an additional backend or override the appropriate functions to support any server side protocol, including DDP and have your models update by server-push magic.
We often use Yii in our projects. The Yii framework is an excellent PHP based library for building web applications, and it comes with its own object layer implementing an Active Record pattern. So by rolling our own client side library I can see an advantage by modelling many of the same function calls making it much easier to transfer knowledge. If the model layer on the client side and server side share a similar interface you save quite a lot of time and can effectively guess some of the API calls. this is slightly different to Meteors approach which take the idea a step further and implement a Mongo database style interface on the client (minimongo). It is an excellent idea and great for small applications but I personally like to have one layer of separation between the database and the application. Also the models represented on the client side are often a little simpler than those on the server. The client side should have a model layer that makes sense for the UI it is representing and can often be an amalgamation of many models (server side into a few client side).
A few potential big wins in the future would be to add validation rules, currently there is a validation function that runs before saving a model, however you are left on your own to implement this. Ideally we would like to emulate something similar to Yii’s rules function and define client side rules. Also error handling can be a pain and create additional controller mess. When the server fails a request in typical applications it also delivers the error messages of what went wrong. which could be something as simple as, you forgot to fill in your name field, for example. Currently it is quite easy to handle this on a case by case bases,especially when using a framework as powerful as Angular. However it would be neat if Andalay automatically understood the server response and was able to neatly organise error messages per model attribute. Thus making it easy to create more intelligent error displaying directives.
Things move fast in the world of web tech. Andalay was a specific library to help with local data access within the Angular framework. As most projects now use a flavour of Vue.js or React this has been deprecated and is no longer supported or maintained.
Subscribe to get our best content. No spam, ever. Unsubscribe at any time.