Now that MWLUG 2015 is history and MWLUG 2016 is in the planning stage, I can now start writing a series that I have wanted to do for awhile about creating a MVC framework.
This will a multi-part series on my adventure into creating my own MVC framework. I will be talking about MVC in the generic sense and it will include MV* of all types.
Creating your own MVC framework? Am I out of my mind? Why in the world would you do that you may ask. There are so many popular and great MVC frameworks available including Angular, Backbone, Ember, React, and etc.
Well, SECURITY, SECURITY, SECURITY.
When we rolled out iPhora Touch v2 just before MWLUG 2014, the feedback for the interface was lukewarm at best, it was slow since the page had to be refreshed each time and it did not work well on tablets and other devices. Though we were using Bootstrap the interface it just would not respond the way that we wanted.
So after MWLUG 2014, I set out to figure out a way to improve the design so that it would be faster, more responsive, and easier to maintain. The previous UI framework was built using Dojo 1.53 which needed a significant amount of Javascript to be loaded before the page would initialize. So moving forward we wanted a AMD JavaScript framework to reduce the loading time.
We wanted to provide a simple and usable user interface for our iPhora solutions that would work for both desktop and tablets. In our iPhora technology, the UI is totally decoupled from the server and there is a total separation between the data and the form. We have never been a big fan of having the server generate the HTML interface. That approach requires you to couple the data with the UI. By decoupling the data and UI, what technology is used to generate the data is irrelevant. Currently, it is Domino, but it could easily be a combination of other propriety or open source technologies. All information is sent and received through a series of JSON RESTful APIs that is managed by the iPhora Gatekeeper. What information you have access to is based on user authentication, roles, ACLs, and permissions. Note for Domino developers, don't use DAS.
Our approach of using Restful APIs makes the use MVC framework ideal. We have long been intrigued by the different MVC frameworks including the popular ones like Angular and Backbone. So our goal was to replace our entire front end with one of these open source MVC frameworks. Even Dojo has a MVC framework, kind of.
However, the selected MVC framework had to meet a number of criterion including easy adaption to how our iPhora data security model worked. It had to handle our multi-level UI Bootstrap-based widget design that is part of the iPhora security model. It had to be lightweight, while being very structured allowing the use of design patterns to help maintainability. In addition, the goal was to have a multi-pane single page application (SPA) interface to help to reduce the constant loading of core libraries over and over again while allowing for constant changes to what appeared on the screen. Since iPhora is designed to handle sensitive information, we needed to control when and how information was to be cached or destroyed both in memory and visually.
From our research and experimentation, we decide the popular MVC frameworks were not going to meet our needs. Stuff like bi-directional coupling did not work for us since it is assumed that at every RESTful API call your security level and access might have changed. Not only that, the security level for each of the multi-panes within the single page application interface may be different.
So our adventure of creating our own MVC framework began. We rolled up our sleeves, got many 6-packs of beer and started laying out want we needed.
Next time, Design Requirements.
This will a multi-part series on my adventure into creating my own MVC framework. I will be talking about MVC in the generic sense and it will include MV* of all types.
Creating your own MVC framework? Am I out of my mind? Why in the world would you do that you may ask. There are so many popular and great MVC frameworks available including Angular, Backbone, Ember, React, and etc.
Well, SECURITY, SECURITY, SECURITY.
When we rolled out iPhora Touch v2 just before MWLUG 2014, the feedback for the interface was lukewarm at best, it was slow since the page had to be refreshed each time and it did not work well on tablets and other devices. Though we were using Bootstrap the interface it just would not respond the way that we wanted.
So after MWLUG 2014, I set out to figure out a way to improve the design so that it would be faster, more responsive, and easier to maintain. The previous UI framework was built using Dojo 1.53 which needed a significant amount of Javascript to be loaded before the page would initialize. So moving forward we wanted a AMD JavaScript framework to reduce the loading time.
We wanted to provide a simple and usable user interface for our iPhora solutions that would work for both desktop and tablets. In our iPhora technology, the UI is totally decoupled from the server and there is a total separation between the data and the form. We have never been a big fan of having the server generate the HTML interface. That approach requires you to couple the data with the UI. By decoupling the data and UI, what technology is used to generate the data is irrelevant. Currently, it is Domino, but it could easily be a combination of other propriety or open source technologies. All information is sent and received through a series of JSON RESTful APIs that is managed by the iPhora Gatekeeper. What information you have access to is based on user authentication, roles, ACLs, and permissions. Note for Domino developers, don't use DAS.
Our approach of using Restful APIs makes the use MVC framework ideal. We have long been intrigued by the different MVC frameworks including the popular ones like Angular and Backbone. So our goal was to replace our entire front end with one of these open source MVC frameworks. Even Dojo has a MVC framework, kind of.
However, the selected MVC framework had to meet a number of criterion including easy adaption to how our iPhora data security model worked. It had to handle our multi-level UI Bootstrap-based widget design that is part of the iPhora security model. It had to be lightweight, while being very structured allowing the use of design patterns to help maintainability. In addition, the goal was to have a multi-pane single page application (SPA) interface to help to reduce the constant loading of core libraries over and over again while allowing for constant changes to what appeared on the screen. Since iPhora is designed to handle sensitive information, we needed to control when and how information was to be cached or destroyed both in memory and visually.
From our research and experimentation, we decide the popular MVC frameworks were not going to meet our needs. Stuff like bi-directional coupling did not work for us since it is assumed that at every RESTful API call your security level and access might have changed. Not only that, the security level for each of the multi-panes within the single page application interface may be different.
So our adventure of creating our own MVC framework began. We rolled up our sleeves, got many 6-packs of beer and started laying out want we needed.
Next time, Design Requirements.
Comments
The reason that you do not want to use DAS is security. Since DAS is pulling from views, you can not easily control the amount of information a particular user sees. It assumes all the users should get the same stuff which is never the case. This is not good practice even behind the firewall.