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

Matthias Wessendorf matzew at apache.org
Wed Feb 7 13:54:55 EST 2018


That said, the HTTP API for device registration and sending should stay
compatible

On Wed, Feb 7, 2018 at 7:43 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Question :-)
>
> On Wed, Feb 7, 2018 at 8:15 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> with the POC for agents done (APNs), I will continue the work, to shrink
>> the "CORE" part of the UPS, using Swarm, JPA, CDI and JAX-RS fractions
>>
>
> speaking of the "CORE" part ... I think... the simplified push models will
> allow us, to also come up w/ a different and simpler data model.
>
> So... Let's say the UPS2 would be a bit different (POC in progress), I
> think the really important bit is that the "important" data (e.g
> PushApps/Variants and, of course, devices) can be exported from old DB and
> 'transformed' to new DB.
> Sounds good?
>
> Our current analytics, is something, I'd like to revisit. But not 100%
> sure yet, but I do see some option, based on lessons learned.
> If these data bits are not portable, I'd not cry a river - compared to a
> case where "device metadata" would be lost (which is IMO a no-go)
>
> Thoughts ?
> -M
>
>
>
>>
>> On Tue, Feb 6, 2018 at 4:18 PM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> 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-93
>>>> 93ec6c-0a86-11e8-9b6f-f138fe0a5691.png
>>>>
>>>> code is located here:
>>>> https://github.com/matzew/aerogear-unifiedpush-server/tree/8
>>>> d01c771a0a89d1243534adef3a924ad284b3c41/push-agents/apns-age
>>>> nt/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/msgid/aerogear/CADvBQ45yhH_-%2BZ
>>>>> 2gKsU-agjv2ucngsgUgo66-dQ7MdyoMuDinw%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
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> github: https://github.com/matzew
>> twitter: http://twitter.com/mwessendorf
>>
>
>
>
> --
> 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/20180207/2c1d2d56/attachment.html 


More information about the aerogear-dev mailing list