Having successfully completed an extremely fast and agile Java e-commerce project recently, I thought it would be fitting to share some of my thoughts on the process, patterns, and technologies that were used. Using agile methodologies to implement new technologies such as Broadleaf Commerce and Mustache, the logic-less template, we were able to successfully launch the full-featured flash sale site, Llustre.com in six weeks.
Just to give you some background, we worked in a development model that many companies have started to use. Over the past few years, there’s been a growing movement to completely separate UI development from the back end. With good reason: there has been a significant advancement in client-side technologies and frameworks. Demand and adoption have risen and the availability of good client-side developers is no longer a rarity. Now I myself have worked with both the front-end and server-side. Lately, I’ve been working mostly on server-side e-commerce development (Broadleaf Commerce), but have worked on the front-end quite a bit before. I know enough to be dangerous. I know enough to appreciate very clean and semantic HTML as well as clean and readable JavaScript. That being said, and being in a role as a server-side developer, I would hate to see front-end guys adding logic in my controllers. As a front-end guy, I would expect the same. It really makes sense to separate the two responsibilities. Leave the look and feel up to the business. Have the designers and front-end developers work on the HTML, CSS, and JavaScript independently of the server-side developers.
As companies start adopting the process of completely separating UI, UX, and Development, the effectiveness of server-side frameworks that generate front-end code (i.e. GWT, JSF, etc…) really come into question. Why would anyone want to mess with ugly generated code that is hard to customize, especially if the look and feel is going to be determined by the business, which it almost always will be.
But, how do you effectively achieve that? How can two teams work separately, know nothing about each others code, but still progressively move forward to a reasonable project completion? How do you effectively integrate once both sides are complete? Having an effective integration plan is key to working in this model. As a Java developer, a typical workflow would be: Receive HTML from the UI team and convert that to a templating language (JSP, Velocity, etc…). The end of the sprint comes, and oh… looks like the business wants to make a couple UI changes. The UI team updates the HTML and hands off the work to development. Development then integrates the changes into the JSP. The end of the next sprint comes, and oh… looks like there are more UI changes. Development “diffs” the new HTML and integrates the changes. Kind of a pain… Wouldn’t it be nice if the UI team were in charge of the presentation layer and had the freedom to change the look and feel at the whim of the business without having to hassle the back-end guys just to integrate style changes. What about all that logic you say? Front-end developers don’t want to touch JSP’s, server-side guys are busy coding the back-end. Enter: logic-less templates.
Logic-less templates were meant to keep your presentation layer clean by limiting your capabilities and preventing you the developer from shooting yourself in the foot.
The mustache website describes it as: “logic-less because there are no if statements, else clauses, or for loops. Instead there are only tags. Some tags are replaced with a value, some nothing, and others a series of values.” Mustache is probably the most popular and most talked about logic-less template out there. It’s the one we used in our most recent project. The premise is simple: Come up with a model (JSON format) that both the back-end guys and the front-end guys agree upon. UI team goes off and does their thing, and development goes and builds the back end.
<h1>{{header}}</h1>
{{#error}}
{{/error}}
<ul class="products">
{{#products}}
{{#sku}}
<li>
<strong>{{name}} - {{retailPrice}}</strong>
</li>
{{/sku}}
{{/products}}
</ul>
|
So in essence, (in terms of Java development) you are pushing all the logic of setting up the page from the template to the controller.
Parallel Development Hurdles
Applying this development paradigm seems easy… in theory, but a little more challenging in practice. The model will be changing frequently in the early stages of the project (especially if you’re working on an agile team). I’ve learned when starting out, it’s best to come up with a solid model with the basic information that will be passed back and forth between client and server very early. Once you get all the naming and coding conventions out of the way early, integrating later won’t be that difficult. But wait, integrate? I thought the whole point was to avoid integration? Truth be told, there’s really no way around that, no matter what development pattern you use. At some point in the development process the UI team and the server-side team are going to become best friends. They’ll need to iron out the final model and discuss integration strategies for AJAX and form submissions. This all seems obvious, but I mention it because this is an important part of the process and shouldn’t be overlooked during project scoping. Many people tend to just add a few days for integration. I believe there will be more upfront work and communication between the two teams during the development phase using logic-less templates. But once all the major integration is done, the responsibilities when issues arise will clearly fall into their respective camps. Making sure to add appropriate time for integration up front into a project timeline is beneficial when coming up with a realistic estimate.
Having used Mustache on this recent project, I still find myself in a love hate relationship with it. There are times when it would be VERY convenient to have an if statement or for each loops in the template rather than pushing that logic to the controller. I’ve learned that it is very helpful to stay in constant communication with the UI team to discuss these very issues. This recent project, we were working with a UI team that was remote which made it a little more challenging when it came time to fully integrate. A colleague described it best when he said, “It’s like trying to build a bridge from both ends and meeting in the middle.” Despite this. I do love what Mustache is trying to accomplish, clean separation. Mustache is also language agnostic (mostly… see the supported languages on their site). The same template can be used for a PHP/Ruby/Java application. The UI team doesn’t have to be constrained to developing their templates on the same platform that the back-end team does. For example, the UI team can be running on Rails or PHP to develop and test their mock-ups, check in their templates to a shared repository, then have the Java server-side team pull down the same templates to use in their application. Magic.
Patterns?
The Logic-less template also lends itself very well to a pattern that many people tend to shy away from. Welcome back DTO! As I mentioned earlier, working in parallel tends to cause disjointed models to be created. The UI team is tweaking the model based on changes to the UI, whereas the back-end guys are creating their models based on other requirements. When it finally comes time to integrate, it’ll feel like you’re trying to fit a square peg into a round hole. I realized this outdated pattern goes completely against the DRY (Don’t Repeat Yourself) principle, but practically (and I’m only speaking about DTO’s because of the limitations of Java and it not being dynamic) the back-end model and the front-end model in an enterprise level application aren’t going to be always identical. There are going to be calculated values, attributes that the front-end only needs for display, attributes the back-end needs maybe for another system that the front-end doesn’t care about. Why not create a DTO? A DTO model that fully represent’s the data on the front-end and can be broken up into discrete parts so that they can be reused in any customer-facing application: AJAX calls, emails, templates, etc… In most cases in an enterprise system, the data model on the back-end is going to need to be massaged to fit into what the business wants to see on the front end. Maybe DTO’s, Value Objects, etc… aren’t so bad after all?
On the client-side, because we’re making everything conform to a JSON model, this pattern lends itself very well to using frameworks like Backbone.js
For those of you who have used logic-less templates like Mustache, what are your thoughts? Love it, Hate it? Are there any patterns or techniques you used that helped on your projects? Please share your thoughts.
