UPS: Admin UI

[Matthias Wessendorf]

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

[David Martin]

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.

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.

> --
> 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+u...@googlegroups.com.
> To post to this group, send email to aero...@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)

[Matthias Wessendorf]

Hi, Dave

thanks for the feedback

On Mon, Feb 5, 2018 at 6:16 PM, David Martin <davm...@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 <mat...@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@googlegroups.com.

> To post to this group, send email to aero...@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@googlegroups.com.

To post to this group, send email to aero...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/aerogear/CADvBQ45yhH_-%2BZ2gKsU-agjv2ucngsgUgo66-dQ7MdyoMuDinw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--