[SP-pm] Resumo do Evento Técnico

[Kojo]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20150131/24555551/attachment-0001.html>