[Feedhenry-raincatcher] Raincatcher feedback from a newbie

[Niall Donnelly]

On Fri, Jan 27, 2017 at 2:16 PM, Summers Pittman <supittma at redhat.com>
wrote:

>
>>
>>>> 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.
>>
>
> [image: Inline image 1]
>
> Users don't behave this way.  If they did I have a developer conference
> that would be in serious trouble.  Expecting users to fork and edit the
> libraries we are supporting is an incorrect expectation.  At best we
> provide consistent APIs to inject behavior into the code.  These apis
> should be versioned and supported so that our user's do not have to always
> be rebasing and forward porting their changes to our updates.
>

[Niall] Sorry, I should probably clarify that the functionality implemented
by developers is very likely to be their own modules to deal with their own
business logic (e.g. instead of using our storage module, they implement
their own to expose the same topics but with a mysql store / custom backend
store API etc.). These modules will subscribe to the same topics published
by our supported modules. The only time a developer would need to consider
forking one of our libraries would be if there is something specific in our
library implementation that they would like to change (E.g. An Angular
directive template for a work-order to display additional data).

>
>
>
>> 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.
>>
>
> You are an exception rather than the rule.  I would be thrilled if our
> users contributed code this way, but we don't want the goto experience to
> be "clone our repository and figure it out".  The goal should be having
> well document behaviors and ways to extend and compose those behaviors
> using a supported API.
>

[Niall] I accept that we need well-documented behaviours and topics for
each of the modules to allow developers to see what is being subscribed to
and what is being published by the module. I also agree that we need a more
accessible way for developers to get started with Raincatcher other than
the full demo solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-raincatcher/attachments/20170130/ba0df358/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 102718 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/feedhenry-raincatcher/attachments/20170130/ba0df358/attachment.png>