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

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(a)apache.org&gt; wrote: > Question :-) > > On Wed, Feb 7, 2018 at 8:15 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > 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(a)apache.org&gt; >> wrote: >> >>> here is the proposal: >>> https://github.com/aerogear/proposals/pull/21 >>> >>> >>> On Mon, Feb 5, 2018 at 8:05 PM, Matthias Wessendorf <matzew(a)apache.org&gt; >>> wrote: >>> >>>> Hi, Dave >>>> >>>> thanks for the feedback >>>> >>>> On Mon, Feb 5, 2018 at 6:16 PM, David Martin <davmarti(a)redhat.com&gt; >>>> 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(a)apache.org&gt; >>>>> 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(a)googlegroups.com. >>>>> > To post to this group, send email to aerogear(a)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(a)googlegroups.com. >>>>> To post to this group, send email to aerogear(a)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 -- 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(a)googlegroups.com. To post to this group, send email to aerogear(a)googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/ msgid/aerogear/CAAg5f2QF2AiZVK%2BQyYB0mDL5G58LXmUPVNySjrcpgJv 58Z012A%40mail.gmail.com <https://groups.google.com/d/msgid/aerogear/CAAg5f2QF2AiZVK%2BQyYB0mDL5G58... . For more options, visit https://groups.google.com/d/optout.