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

[Matthias Wessendorf]

On Fri, Sep 27, 2013 at 9:49 AM, Sebastien Blanc <scm.blanc at gmail.com>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"}]}
>


templating is an interesting thought, but....




>
> 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).
>


Right, we (the server) have than to figure out all that, and submit a bunch
of messages... I guess unless we have no real requirement for that, let's
not do that; Also I don't like the closer tie to the business app. The
UnifiedPush Server is not an ESB ;)


-M



>
>
>> *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 ?
>
>>
>> *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 list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130930/9b70d2b8/attachment-0001.html