OpenLMIS-UI v7 Architecture - QA

Dear dev~

tldr; Please voice questions and concerns about changes to the OpenLMIS-UI which will happen as part of the v7 Architecture epic.

NOTE: AngularJS is referenced in this document, which generally refers to Angular v1.x which is the legacy version of the Angular javascript framework.

We have decided to start moving forward with the OpenLMIS-UI v7 Architecture. You can read more detail about this plan in:

v7 Architectural Goals:

  • More reusable and maintainable code

  • More performant build process

  • Reduce tight-coupling between AngularJS and application logic

Questions from Tech Committee on November 28th 2017

The questions below have been numbered with a letter, so its easy for someone to reply to this thread and mention a topic with just a letter. If you ask a question and don’t add a reference letter, I’ll add one for you.

(A) When and how will this work prioritized

This work is going to be done in an incremental fashion and build on top the the logic and frameworks that we are currently using. As new tooling is added to the OpenLMIS-UI, any current feature work will be encouraged to use abstractions provided by the v7 Architecture instead of underlying AngularJS frameworks. Once the core architectural features are implemented, existing code will be refactored to use the v7 Architecture and make OpenLMIS-UI business logic be more plain.

(B) What is different between AngularJS and v7

v7 will add build time tooling which will allow for developers to write ES6 or ‘traditional’ javascript which will make reusability and maintenance easier.

All v7 Architectural objects already exist within the AngularJS, but the abstractions in v7 are designed to force/encourage developers to use a subset of the functionality in AngularJS. By adding an abstraction layer and limiting the functionality that can be used, we are:

  • Getting ready to remove AngularJS completely (as it will not be maintained… eventually)

  • Force a separation between application logic and presentation logic (which AngularJS doesn’t take a strong stance towards, and makes our code harder to maintain)

  • Adds documentable structures for developers to work with, rather than flexible AngularJS approaches

© Start sections with more of a "why"

Section in the v7 documentation and epic don’t describe “why” we are making these changes. This is a good thing to document so the overall intent of the v7 effort is understandable

(D) Are we re-inventing the wheel?

I’d argue that we are not re-inventing the wheel, but formalizing our architecture with well known application design patterns. This is a good step in any project that gets large as it helps reduce complexity and increases the maintainability of the application.

In the scope of v7 we intend to abstract implementation details from libraries and tools we already use. When we are ready to stop using the AngularJS library, we will be able to replace abstracted implementations with other libraries rather than roll our own.

(E) How much do we save going this route instead of doing a re-write?

This is a hard question to answer because the v7 plan is designed to be incremental changes, so that work on features in OpenLMIS won’t stop (we have deadlines after all).

Full adopting v7 within all OpenLMIS-UI modules will take significant effort, but:

  • Existing functionality has unit tests, which will help assure we avoid regressions (which could happen in a re-write)

  • There will not be immediate pressure to deliver, which would be an issue with a re-write

  • v7 changes are not focused on changing HTML or view-level logic, which would be an issue if we did a full rewrite to a different framework like React

– nick –

···

Nick Reid | nick.reid@villagereach.org

Software Developer, Information Systems Group

VillageReach** *** Starting at the Last Mile
*2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

CELL: +1.510.410.0020

SKYPE: nickdotreid

www.villagereach.org