Our Front-End libraries have both short and long term goals. Usually our short term goals are feature driven while our long term goals are for long term adoption. The following long term goals have been driving our development from the beginning.
- Must be generic so that a developer can come in and start extending or adding features as they see fit
- Support the non-developer community by designing a clean API to support programmatic configuration
In our previous libraries we were more concerned with our short term goals by adding features and iterating over those features to get them right. Those goals still exist from a design perspective but from the engineering perspective we needed to shift how we were developing in order to support these two long term goals.
Previously we developed ‘modules’ which provided an interface for a given feature. These modules would provide an API for the feature and handle remote and local communication. We also incorporated jQuery plugins. We used 3rd party plugins and wrote our own to define what feature a node would provide.
If we continued this way, we could never meet our goals. We were only developing the Logic and UI layers. We needed to shift from a scripted feature set to a full feature application with a clear separation of concerns.
Before we started a recent custom implementation, we knew we had to provide better separation if we were going to be successful. We spent a few days drawing diagrams, researching best practices, deciding on how to leverage existing libraries and coming up with names for what we were trying to define.
Once we had flushed out our ideas we had to go back and provide some structure for how we could think and talk about it more publicly. We took the multitier architecture model and identified our layers as the following:
When these were identified we only had a rough sketch of which classes belonged where but we had to start developing due to our impending deadline. However, this was the first time we had a clear separation of concerns and a shared language to work from and couldn’t wait to get started!
We now have the following architecture to work from in order to meet our short term goals as well as quickly and accurately iterate over our feature development:
- BigDoor (inherits from API)
It would be nice if I could predict the future and tell you what features and functionality we are working towards but I can’t. What I can say is that we are working hard to make this publicly available as soon as possible by reintegrating Facebook Like, Badges, etc., as well as prototyping new applications.
I’m super excited with this release and couldn’t be happier to be a part of this team. I can’t wait to see what we can come up with next!