[Feedhenry-raincatcher] Raincatcher feedback from a newbie

[Niall Donnelly]

Apologies for my late reply. Comments inline below.

On Thu, Jan 26, 2017 at 7:28 PM, Paolo Haji <phaji at redhat.com> wrote:

> I'd like to try adding my individual inputs to each point as well because
> I think they're very nicely put
> On Wed, Jan 25, 2017 at 12:29 PM, Summers Pittman <supittma at redhat.com>
> wrote:
>
>> 0.  I've had Raincatcher described to me as a architecture for writing
>> Raincatcher applications using Raincatcher modules.  For workforce
>> management.
>>
>
> From my start with the team I considered the project a set of apps with a
> feature set around workforce management that would be minimally configured
> to cater to customers' business needs (and maybe cosmetics/branding as
> well), and that a lot of that would be covered mostly by Forms.
> I think I formed this mental image due to the development process focusing
> on the demo projects (both for new features and for verification of
> issues), and the starting point being the template in Studio that just
> gives you all the demo projects.
> It's very important for us to have a vision of what Raincatcher should be
> to progress toward, specially with the opensourcing efforts.
>

[Niall] Yes, the intention is to produce a set of loosely-coupled modules
that implement the functionality required to build a workforce management
application. The intention is for the modules to be the building blocks of
a larger application, using the mediator pattern to communicate between
them. The modules should also be able to stand alone. Any interaction with
functionality outside the remit of their own domain (e.g. fh-wfm-workorder
only deals with logic related to workorders) should be done using mediator
topics. By building the solution from loosely coupled modules, the
intention is to make the process of customising the solution much easier
for the developer as they can swap out the fh-wfm-user module for their own
user module that has different authentication mechanisms. The internal
working of the fh-wfm-user or my-wfm-user module should be abstracted from
the consumer of the application. As long as the module publishes and
subscribes to the same topics it should just plug into the existing
solution.

The same principle applies to developers that want to extend the
functionality of the demo solution. Developers should be able to create
their own modules that publish their own topics and subscribe to topics
published by other modules.

That is the goal of the project, however we are not there yet. I am spiking
Epics at the moment around how we can better improve the boundaries between
the modules and application code. Ideally, the applications would just
initialise the relevant modules (both fh-wfm- and custom developer defined
modules) with configuration.

>
>
>> 1.  The highly decoupled nature of the codebase hides how the modules
>> should interact with each other. By should I mean you can't look at the
>> demo project and quickly get an idea of how one should architect a
>> greenfield RC application.
>>
> Not something I've particularly faced since as in (0) I had never thought
> of 'a greenfield RC application' before. However I think that the current
> codebase is currently very coupled in hidden ways, in which there is a lot
> of required functionality for the individual modules is expected to be
> supplied by the utilizing application and vice-versa. I talk more about
> this in (4)
>

[Niall] Agreed, we definitely need a green field guide for developers to
get up and running with a couple of our modules and possibly their own. I
have created an Epic to capture this work. I originally thought with better
code comments and documentation for the demo solution, it would be enough
for developers to get started with. But it is becoming clear to me that
even with good documentation and refactoring around the full solution, I
think it will always be too much of a slope for developers to get started
with.


>
>
>> 2.  Angular is a huge, opinionated framework with lots of gotchas, and
>> Angular went the route of "Let's add a bunch of custom tags and attributes
>> to html elements".  This has the effect of breaking lots of tools and
>> making learning Raincatcher even harder.
>>
> I agree that these frameworks adds to the learning curve, but I think we
> also fail on being idiomatic in the context of angular and other frameworks
> as in someone who knows angular would still have a bit of a hard time
> understanding how to use the modules.
>
> For angular some of our modules supply directives (i.e. custom tags) that
> take no arguments and do a bunch of stuff, being manipulated by their own
> controllers and interacting through the sparsely documented mediator
> topics. This is quite opaque.
> For express the modules grab the application and add a bunch of routes to
> it, as opposed to exporting routers and middleware that the client code can
> control and mount as it sees fit.
>

[Niall] I don't see any problem with being opinionated about we build a
project. What we are building is effectively micro services in a single
applications that communicate over a bus (mediator).

I do think we have some work to do around how we structure the module
functionality between business and display logic. I'm not sure the modules
should be providing Angular services to other modules that have  lot of the
business logic required for the applications. Ideally, all of the business
logic for the modules would be completely UI framework agnostic and the UI
code would just publish and subscribe to mediator topics. This needs some
spikes to flesh this out.

At the very least, each of the modules need to adhere to a common structure
or developers will get really confused when switching between modules.


>
>> 3.  RHMAP makes it very difficult to deploy applications which have
>> dependencies on auth services.
>>
> In addition to this the workflow for developing an application with
> depending modules is not particularly nice.
> If we're expecting users to extend the solution with their own modules for
> now they'd either have to come up with a folder structure to put them in
> the code of the application or setup a private npm instance.
> Also if they want to alter code in our modules they have to depend on
> their own github forks, publish their forks to private npm instances, or
> use bundledDependencies.
>

[Niall] This is probably a gap in the RHMAP platform rather than
Raincatcher itself. I see no reason why we wouldn't ask users to fork the
modules if they want some custom code that we don't have. This is the
benefit of having open sourced everything in the project. If I wanted
custom functionality in an npm module (And I have done several times) I
would fork the module, publish my own module and do a PR back to the
upstream to see if it would be accepted. Raincatcher should be no different
IMHO.


>
>>
>
>> 4.  Raincatcher uses message passing, but the APIs themselves don't make
>> discovering available namespaces easy or automatic.  Developers have to be
>> highly aware of the name spacing, what modules are available, and the RC
>> conventions.
>>
> We've had some trouble trying to establish a structure for the modules
> themselves, and as some others have pointed out it's not something the
> language or the libraries we use are supportive of this.
> I've been looking into structures from other frameworks and I think ducks
> <https://github.com/erikras/ducks-modular-redux> come very close to what
> we want to have for Raincatcher modules, i.e. formally exposing which
> mediator topics, http endpoints, angular modules, etc each module provides
> and consumes.
>

[Niall] Yes, it would be good to have topic discovery and better API
documentation around exactly what the modules expose. This should
definitely be done before exiting tech preview also.


>
>
>>
>
>> 5. Raincatcher lacks tutorials and simple sample applications. We have
>> the portal which is a kitchen sink project (great for excitement and
>> presentations, not for learning), and the demo application (an example of
>> how to add a custom module).
>>
> Not much to comment here. I think we should be looking into establishing a
> solid structure for the individual modules, reducing the glue and
> functionality in the demo applications until they can become clean examples
> themselves.
>

[Niall] Agreed, as above, we need a green-field example and much better
structure and documentation around how each individual Raincatcher module
works and how they combine to build a larger solution.


>
>> _______________________________________________
>> Feedhenry-raincatcher mailing list
>> Feedhenry-raincatcher at redhat.com
>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>>
>>
>
> _______________________________________________
> Feedhenry-raincatcher mailing list
> Feedhenry-raincatcher at redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-raincatcher/attachments/20170127/8a48197a/attachment.htm>