[SP-pm] Resumo do Evento Técnico

[Renato Santos]

Tendo um backend esperto da sim para ter um backend só, por exemplo, um
sistema async e ter na frente uma opção de http que conversa com esse
sistema async.
On Jan 31, 2015 7:44 PM, "Kojo" <rbsnkjmr at gmail.com> wrote:

>
> Em 31 de janeiro de 2015 18:09, Leonardo Ruoso <leonardo at ruoso.com>
> escreveu:
>
>> Em 31 de janeiro de 2015 17:48, Renato Santos <renato.cron at gmail.com>
>> escreveu:
>>
>> Nem todo mundo que conheço gostam de AngularJS, algumas, inclusive, tem
>>> um forte ódio (quase como o Eden vs Mojolicious).
>>>
>>
>> Há algumas alternativas ao AngularJS. Pessoalmente eu conheço o
>> AngularJS. Agora, AngularJS está muito mais para Catalyst que para
>> Mojolicious. A tendência seria de que o Eden gostasse do AngularJS. De
>> fato, não conheci ninguém que eu respeite como designer de software que não
>> respeite considerável o AngularJS.
>>
>
> O AngularJS está para o Catalyst pq são dois MVCs, um trabalha no back e
> um no front. O Mojo pelo pouco que eu sei é um framework, http/websocket
> server assíncrono. Então acho que AngularJS e o Mojo trabalhariam bem
> juntos.
> Eu fiz uma implementação de AngularJS com Websocket, não usei Mojo pq o
> back não era Perl, mas o AngularJS tem uma biblioteca para trabalhar com o
> protocolo Websocket que vai tranquilo.
>
>
>
>>
>>
>>> A unica parte que não entendi até agora foi essa:
>>>
>>>    - A REST API should not be dependent on any single communication
>>>    protocol, though its successful mapping to a given protocol may be
>>>    dependent on the availability of metadata, choice of methods, etc. In
>>>    general, any protocol element that uses a URI for identification must allow
>>>    any URI scheme to be used for the sake of that identification. *[Failure
>>>    here implies that identification is not separated from interaction.]*
>>>
>>> Como fazer uma API comunicável por diversos protocolos? HTTP e HTTPS não
>>> bastam? Os outros protocolos não podem ser "tunelados" por HTTP?
>>>
>>
>> Se chegarmos a montar nosso grupo de estudo eu realmente gostaria de
>> chegar num ponte de termos ao menos um software com uma API de referência
>> funcionando simultaneamente em cima de HTTP(S) e AMQP (incluindo AMQP
>> tunelado em WebSocket). Suportando HTML, JSON e XML, mesmo que seja uma
>> aplicação bem simples como uma nova versão do ACT.
>>
>
>
> Já que vc considera a possibilidade de implementar algo REST-like em
> Websocket, segue abaixo umaa pequena tabela que mapeia diferentes
> características de cada protocolo.
> O zero é qdo não tem a característica e o um é qdo tem a característica.
>
>
> HTTP    Websocket
> Stateless (Só o Client mantém estado)           1            0
> Stateful (Client e Server mantém estado)       0            1
> Synchronous (Blocante)                                   1            0
> Assynchronous (Não Blocante)                       0            1
> HalfDuplex
> 1            0
> FullDuplex (Real Time)                                      0            1
>
> Algumas observações.
> 1. O Websocket é não blocante, não dá para querê-lo sincronizado. O
> cliente precisa trabalhar com callback, promisses, etc.
> 2. Para o Websocket ser assíncrono ele precisa ser stateful.
> 3. Para o Websocket ser RealTime, ele precisa ser stateful.
>
> Me arrisco dizer que seria complicado implementar uma API única para os
> dois.
>
>
>
>
>
>
>
>
>>
>>
>> --
>> Saravá,
>> Renato CRON
>> http://www.renatocron.com/blog/
>> @renato_cron <http://twitter.com/#!/renato_cron>
>>
>>>
>>> =begin disclaimer
>>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>>> =end disclaimer
>>>
>>>
>>
>>
>> --
>> Leonardo Ruoso
>> Journalist, Perl developer and business consultant
>> Media, UFC/2006; Telecom, IFCE/1998
>>
>> =begin disclaimer
>>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
>> =end disclaimer
>>
>>
>
> =begin disclaimer
>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20150131/7c98ba22/attachment-0001.html>