[aerogear-dev] Push modules (was Re: UPS: Admin UI)

[Matthias Wessendorf]

here is the proposal:
https://github.com/aerogear/proposals/pull/21


On Mon, Feb 5, 2018 at 8:05 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hi, Dave
>
> thanks for the feedback
>
> On Mon, Feb 5, 2018 at 6:16 PM, David Martin <davmarti at redhat.com> wrote:
>
>> For RHMAP 3/4, the Studio was originally part of a single jar/war
>> (millicore). It did have a jsp for delivering the index.html (which
>> wrote a bunch of inline javascript)
>>
>> The studio was then decoupled from the war file as a separate war
>> (fh-studio). However, it still had an index.jsp, but called back to
>> the 'core' to get some of the info needed for that.
>>
>> This was eventually refactored into a node.js express app (fh-ngui)
>> and deployed completely separately. It still made calls back to the
>> core to get some config/user info.
>>
>> The main benefit I found was the UI could be progressed at a faster
>> pace as the local development tooling could be tailored better. (just
>> run the UI server & hook up to an existing core somewhere)
>> However, it introduced overhead with the addition of a new deployable
>> component.
>>
>
> that's also some of the points. We already have the development moved over
> to a different repo.
> We currently just stick it's JAR (which might be silly) into the WAR.
>
>
>>
>> This was all in a pre-containers world, but it was migrated to a
>> container world (on openshift).
>> We never went as far as nginx serving static content, but I could see
>> that as a logical progression.
>> It would probably mean a smaller footprint overall.
>>
>
> cool. It's something I will include in the proposal (not done any
> testings).
>
>
> Currently I look removing some good parts of the WAR file for the push
> delivery itself.
>
> current approach, which I do like so far, is having each "network" run as
> a java process, that wires the "send bits" (e.g. for iOS) togehter via
> messaging (kafka).
> Here is a metrics screenshot:
> https://user-images.githubusercontent.com/157646/
> 35808591-9393ec6c-0a86-11e8-9b6f-f138fe0a5691.png
>
> code is located here:
> https://github.com/matzew/aerogear-unifiedpush-server/tree/
> 8d01c771a0a89d1243534adef3a924ad284b3c41/push-agents/apns-
> agent/src/main/java/org/aerogear/push/apns
>
> It's borrowing some concenpts/code from core UPS. but is really no http
> server - just a standard Main, which has a kafka consumer, plugged via ENVs.
>
> I currently deploy to Openshift using the fabric8-maven-plugin (fmp), that
> generates all all (docker file, k8s/oc yamls).
>
> I will do the same for FCM.
>
> Once that all is done, we have no "sending" code in the UPS, and we can
> move than the UPS itself to WF-Swarm, for a migration to a simpler
> develipment/deployment model (and perhaps some more modules in the longer
> run)
>
> Proposing:
> * fcm-sender.jar (in container)
> * apns-sender.jar (in container)
> * UPS move to Swarm
> * UI in nginx
>
>
>
>>
>> On 30 January 2018 at 19:40, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>> > Hi,
>> >
>> > right now, we have the static resources of the admin ui build to a JAR
>> file
>> > and a "node tgz". Currently, in the community, we use the bundled JAR
>> and
>> > deployed to the UPS WAR file. So far, so good
>> >
>> > For our modularization I was thinking at different options:
>> >
>> > * WildFly Swarm w/ just static (WAR) resources
>> > * Node.js/Express app
>> > * Ngnix container, just serviing the content
>> >
>> > I've tested 1) I was wondering if we might - for some better resource
>> > utilization might just go w/ Ngnix, and deploy the static resources of
>> the
>> > admin UI to there?
>> >
>> > How do other think about breaking the UPS down to different
>> technologies and
>> > aspects?
>> >
>> > -Matthias
>> >
>> > [1] https://github.com/aerogear/unifiedpush-admin-ui
>> >
>> > --
>> > Matthias Wessendorf
>> >
>> > github: https://github.com/matzew
>> > twitter: http://twitter.com/mwessendorf
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "Aerogear" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to aerogear+unsubscribe at googlegroups.com.
>> > To post to this group, send email to aerogear at googlegroups.com.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msgid/aerogear/CAAg5f2Qi6Fwj5FPq
>> -VdBEw3Ro_pq4FwqJpPiyGbmj0cEJrfv7Q%40mail.gmail.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> David Martin
>> Red Hat Mobile
>> Twitter: @irldavem
>> IRC: @irldavem (#aerogear)
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Aerogear" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to aerogear+unsubscribe at googlegroups.com.
>> To post to this group, send email to aerogear at googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/aerogear/CADvBQ45yhH_-%2BZ2gKsU-agjv2ucngsgUgo66-dQ7Mdyo
>> MuDinw%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Matthias Wessendorf
>
> github: https://github.com/matzew
> twitter: http://twitter.com/mwessendorf
>



-- 
Matthias Wessendorf

github: https://github.com/matzew
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180206/dafa3e90/attachment.html