The goal of the new design is to support several reusable components with the intent of keeping them light weight and modular. Some desirable features include:
1. A JavaScript based navigation widget
This could also include common header, footer, left-hand navigation, etc. The idea is to use the browser to apply common UI components into the page. This appeals to me as a software designer because it enables one solution to be used consistently across all application components within a site having nontrivial architecture, regardless of the technology or templating mechanism used. As long as the UI is rendered in a browser and each application can provide the same hooks (possibly just insert at start or end of page) then this will cut down on re-implementation of the same functionality leading to inconsistencies and annoying maintenance issues.
At first, the design would focus on a simple and static navigational structure, possibly leaving a second tier navigation for each participating application to manage on its own (probably won’t have that complicated of a site myself). The more static the JavaScript, the better the user experience from a performance perspective.
Eventually, the navigation will also be concerned with customized navigation elements. Custom navigation assumes a user has been authorized or has selectively chosen to view a subset of the overall site. This user experience feature becomes more important if you have private areas of your site or the site becomes so large, the navigation cannot comfortably fit within a single view. I personally had a revolutionary thought a while back (tunnel vision, I suppose) when I realized a Java Servelet (or any other dynamic web code) is just as capable of rendering JavaScript dynamically as it is rendering HTML.
Note that custom navigation requires some concept of identity for the current user. Identity will not be within scope of this widget, but will need to consume that identity information, which leads me to the next component.
2. Identity Service
Identity management is a nontrivial issue to tackle when dealing with distributed applications. There have been many attempts at solving the problems in this domain, and even the simplest solutions are not as simple as one would hope, particularly when implementing both the identity authority and consumers for a single site. Since my goal is to aggregate many technologies under one web experience, I will need to have them relay identity seamlessly for Single Sign On, as well as share basic information between them… if identity is needed. One technical detail in my favor is I intend to run much of this under a single domain, which makes cookies a viable option for relaying some critical details (e.g. a cross-application session cookie containing a token that can be used to look up identity and session status info from a centralized RESTful web service). Of course, since there are already standards surrounding identity distribution, it would also be nice to leverage some existing libraries for supporting this. Since I’ve already had experience with OpenID, perhaps a light-weight OpenID Connect server would be a good path forward, though a bigger investment in time and brain power that may not be feasible in the near future.
This feature is of particular interest to me because I’ve been working in this space professionally for the past few years. I have some ideas on how to simplify this given this specific use case, and have a desire to explore the use of Akka’s actors to support this. Ideally, the server would be extremely easy to start up and configure, and is designed out of the box to support high availability if not global distribution; however, I’ve not been able to get a global distribution under my belt yet. The biggest threat to this not happening is I will not be implementing and/or using this in my day job. This may also turn out to be a blessing, as it will force the implementation to be simple due to time constraints and a “just get it done” mentality. Using a terse language like Scala may help as well, but running in the JVM does somewhat ding my goals for minimal resource usage. Right now, I am taking the Hudson/Jenkens deployment model as inspiration, and I’m hoping that if I can implement this once, integration with other systems should be low hanging fruit.
3. A JavaScript based commenting widget
The design principal is pretty much the same as the navigational widget, but this is intended for distributing a comments & collaboration system that is centrally managed. The thought for this widget came to mind because I intend to serve most of my content in a static format going forward rather than running an application server to serve up the same stuff over and over. This has benefits from a resource usage perspective, as well as an operational support perspective. The fewer moving parts, the more reliable and less critical the issues.
The django server I’ve been running in “production” (with extremely low traffic) has not given me much grief at all, and it already has a pretty good set of administrative functions for comments, so maybe I’ll build this feature on top of what I already have running.
One potential wrench in the works I’ll have to work around is cross site JavaScripting support. Keeping all applications running as application contexts under a common domain will make this a non-issue, but I don’t want to design myself into a corner that prevents sites with differing domains from using the commenting tool. This may require a kind of server-side proxy that lives on the different domain, but relays data via a server to server communication… food for thought.
The concept of identity also plays a part in posting comments, though it isn’t absolutely critical. The initial implementation may function anonymously but allowing the user to provide a name via a form field. Then as identity gets rolled out, a signed in user would automatically have their name populated and fewer limitations would be applied on what the user can post.