[katello-devel] Thinking about NuTupane Architecture

[Jason Rist]

On 01/08/2013 07:21 AM, Bryan Kearney wrote:
> On 01/08/2013 09:20 AM, Dmitri Dolguikh wrote:
>> On 07/01/13 03:04 PM, Eric Helms wrote:
>>> My two cents:
>>>
>>> Disclaimer:  This should all be taken with a grain of salt, as my
>>> opinions may be compromised by my love for building UI's and all the
>>> fun (some might call it "complexity") that comes with that.
>>>
>>> I have a few take aways and lessons learned having done some complex
>>> JS and UI work in the past, and from experience tackling the most
>>> recent biggest customized UI component to date: content search.
>>>
>>> There are typically four major components:
>>>
>>> Structure (or the "view") - the html/haml/js-template
>>> Logic - the JS code that does all the heavy lifting
>>> Styling - the CSS/SCSS
>>> Data - that which is provided by the server in some structured manner
>>>
>>> General Lessons:
>>>
>>> - Clearly define the line between the data and UI component
>>> - Let the component define what it needs to perform it's function, and
>>> where necessary use an intermediary to massage the server data into
>>> the proper format (if for example,
>>> using API provides RESTfully structured data that is not exactly
>>> compatible with the format the component needs)
>>> - do NOT let the API define the way the UI component works (see above)
>>> - For the UI component itself: separate the structure from the logic
>>> as much as possible
>>> - Keep the structure as simple as possible
>>> - Try to not let the structure influence the styling
>>> - Ensure the difference between structure logic and data logic are
>>> cleanly separated
>>> - When building a complex component, break down into smaller, focused
>>> components that are combined to work together
>>>
>>>
>>> Specific Lessons and Implementation Details:
>>>
>>> Views:
>>> - Views can be crafted such that they are re-usable by both Rails
>>> views and JS-templates, often JS-templates are more flexible when
>>> dealing with complex data sets and multiple-moving parts in the UI
>>> component
>>> - Backbone provides a way to craft self-sustaining views that are
>>> model-agnostic
>>> - Often views are re-usable, crafting them as generic components that
>>> can be combined into large structures can give great flexibility for
>>> future building
>>>
>>> Logic:
>>> - Will be required to drive the mechanics of the structure
>>> - WIll be required to massage the model and collection representation
>>> - Should be cleanly separated between view and model
>>> - Structure logic can be cleanly and nicely contained in backbone view
>>> classes
>>> - Model, or general logic can be contained with Backbone models and/or
>>> custom JS modules
>>>
>>> Styling:
>>> - Nothing revolutionary here, clean, focused SCSS that tries to
>>> emphasize components and the difference between "style" and "structure"
>>>
>>> Data:
>>> - Typically the most controversial as often this requires a
>>> representation of your backend models inside the client-side UI and
>>> while this can feel overly verbose and repetitive, makes complex and
>>> powerful UI components cleaner, easier to work, and more powerful
>>> - Backbone models do not require defining a schema, thus making them
>>> ideal for adapting as data changes or to dynamic data
>>> - API's typically are the best option for usage of backbone modelling
>>> and collection
>>
>> This is more or less in line with my experience of building non-web MVC
>> ui's.
>>
>>>
>>>
>>>
>>> My previous experience and exploration with the various UI frameworks
>>> out there (backbone, knockout, batman, angular, ember, etc.) has led
>>> me to personally believe that generally speaking Backbone is the most
>>> flexible to your needs in terms of using bits and pieces as needed and
>>> crafting components.  While the big everything-but-the-kitchen-sink
>>> frameworks, like AngularJS, EmberJS do really great if your ENTIRE UI
>>> is built using this framework with a set of APIs which I do not think
>>> describes us.
>>>
>>>
>>> While I think the pros of backbone are largely laid out above, I'll
>>> play slight devils advocate and mention the potential cons as I see
>>> them:
>>> - Adds new dependency on BackboneJS (single JS file)
>>> - Moves towards building UI components even more into the JS layer
>>> - Introduces the use of dedicated JS-templates (we already use 'cheap'
>>> JS-templates in a number of places - content search, sliding tree)
>>> - Potentially introduces shift to using API controllers for UI - where
>>> is the line drawn?
>>
>> I'll bite :). I think the existence of UI controllers is an artefact of
>> the traditionally architected web-ui's: web-page carries no state, which
>> is maintained on the server. Ajax helps to move some of the state to the
>> client, but doesn't eliminate it from the server-side completely.
>>
>> Moving to a pure js client would allow us to move the entirety of UI
>> state to the client (and thus creating a true MVC), which leaves the
>> server-side with the task of retrieving of data, which is the task of
>> api layer.
>> In other words, with this approach we'd replace our current UI
>> controllers with the ones running on the client-side (and written in
>> js), and treat API layer as the model.
>>
> 
> Lets please keep in mind... we need more functionality in less time. A
> re-write of hte UI layer means we should be rethinking things.
> 
> --bk
> 

I understand. I'm of the opinion that we have a longer term problem that
needs to be solved and the opportunity is presenting itself. That is my
understanding of how the Agile process works.  We build something, and
we use it for a while, and either a user or a developer realizes that it
can be done better and provide us with lower long term maintenance and
usability costs.

I'll go ahead and continue this spike, unless someone thinks it isn't
worth it.

-Jason


-- 
Jason E. Rist
Senior Software Engineer
Systems Management and Cloud Enablement
Red Hat, Inc.
+1.919.754.4048
Freenode: jrist
github/identi.ca: knowncitizen