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

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