[aerogear-dev] Feedback for aerogear-unifiedpush-server - personalized push notifications case

Sebastien Blanc scm.blanc at gmail.com
Fri Sep 27 04:38:20 EDT 2013


On Fri, Sep 27, 2013 at 10:35 AM, Apostolos Emmanouilidis <
aemmanou at redhat.com> wrote:

> **
> On Fri, 2013-09-27 at 09:49 +0200, Sebastien Blanc wrote:
>
> On Fri, Sep 27, 2013 at 9:12 AM, Apostolos Emmanouilidis <
> aemmanou at redhat.com> wrote:
>
>   I received some feedback for the aerogear-unifiedpush-server.
>
> The case is:
>
> Company X would like to create a personalized push notifications campaign
> for Y hundred thousands customers/clients. Personalized means that each
> client/device should receive a unique message. The messages are
> automatically produced from rules defined in a CRM system, but this is
> something which doesn't affect our implementation.
>
> Currently, our selective send method is able to send one message to a
> selected list of clients. In cases like the above one, this translates into
> Y hundred thousands calls of the aerogear-unifiedpush-server selective send
> method. The question is whether we could change the signature of the
> selective send method and allow to pass an array of messages or not.
>
> In my understanding, the advantages/disadvantages of a such change are
> similar to the advantages/disadvantages of a service according its level of
> granularity.
>
>
>
>  This is indeed an interesting use case ! And as you said we should
> really consider the impact of sending an huge message ( + UPS refactoring)
> Vs Sending hundred thousands messages.
>
>
>
>  But considering "the big send" option and thinking aloud, even if it the
> messages are personalized, probably most of the message will be identical
> with just some variables changing. We could have a message template, and
> the map of clients (alias in UPS terminology) would contain values for
> variables, pseudo code :
>
>
>
>  {"message":"You won <amount> with this
> <stock>","alias":{["bob":{"amount"=50,"stock"="Shell"}
> , "john":{"amount"=120,"stock"="Esso"}]}
>
>
>
>  This will limit the size of the "big send" but implies some logic
> processing on the UPS side which is maybe not the best idea (even if this
> templating is generic and not related to any business logic).
>
>
>
>
> *Fine Grained*
> + simplicity and less business logic on server side
> + less amount of data exchanged between client/server
> - a lot of interactions between client/server
> - more interactions = more network overhead
> - complex client side
>
>  Why ?
>
> If the question goes to the "complex client side" point, I guess that a
> more sophisticated solution is required on the client side than creating a
> loop and "firing" the ag-ups :)
>
> Ah ok :) you mean the "backend" client sending the messages to the UPS.
Sorry was confused , I was thinking about the "device" clients.

>
>
> *Coarse Grained*
> + less interactions between client/server
> + less network overhead & possibility of re-using the same network
> connection to send messages to the Push Networks (at least for APN)
> + simple client side
> - much data exchanged in each interaction between client/server
> - complex server side
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>  _______________________________________________
> aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130927/3d400a75/attachment.html 


More information about the aerogear-dev mailing list