[Feedhenry-raincatcher] Raincatcher feedback from a newbie

[Paolo Haji]

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.


> 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)


> 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.

>
> 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.

>
>

> 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.


>

> 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.

>
> _______________________________________________
> 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/20170126/99b3a9aa/attachment.htm>