<p dir="ltr">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. </p>
<div class="gmail_quote">On Jan 31, 2015 7:44 PM, "Kojo" <<a href="mailto:rbsnkjmr@gmail.com">rbsnkjmr@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">Em 31 de janeiro de 2015 18:09, Leonardo Ruoso <span dir="ltr"><<a href="mailto:leonardo@ruoso.com" target="_blank">leonardo@ruoso.com</a>></span> escreveu:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Em 31 de janeiro de 2015 17:48, Renato Santos <span dir="ltr"><<a href="mailto:renato.cron@gmail.com" target="_blank">renato.cron@gmail.com</a>></span> escreveu:<br><div class="gmail_extra"><div class="gmail_quote"><span></span><div> <br></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Nem todo mundo que conheço gostam de AngularJS, algumas, inclusive, tem um forte ódio (quase como o Eden vs Mojolicious). </div></div></div></blockquote><div><br></div></span><div>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.<br></div></div></div></div></blockquote><div><br></div><div>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.<br>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.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>A unica parte que não entendi até agora foi essa:</div><div><ul style="margin:1em;padding:0px;color:rgb(0,0,0);font-family:Georgia,Verdana,Arial,serif;font-size:medium"><li style="padding:0.5em">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. <i>[Failure here implies that identification is not separated from interaction.]</i></li></ul></div><div>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?</div></div></div></blockquote></span><div class="gmail_extra"><br></div><div class="gmail_extra">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.<br></div></div></div></div></blockquote><div><br><br>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.<br>O zero é qdo não tem a característica e o um é qdo tem a característica. <br><br>                                                                             HTTP    Websocket<br>Stateless (Só o Client mantém estado)           1            0<br>Stateful (Client e Server mantém estado)       0            1<br>Synchronous (Blocante)                                   1            0<br>Assynchronous (Não Blocante)                       0            1<br>HalfDuplex                                                          1            0<br>FullDuplex (Real Time)                                      0            1<br><br>Algumas observações. <br>1. O Websocket é não blocante, não dá para querê-lo sincronizado. O cliente precisa trabalhar com callback, promisses, etc. <br>2. Para o Websocket ser assíncrono ele precisa ser stateful.<br></div><div>3. Para o Websocket ser RealTime, ele precisa ser stateful.<br></div><div><br>Me arrisco dizer que seria complicado implementar uma API única para os dois. <br></div><div><br><br><br><br> </div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="gmail_extra"><br><br></div><span><div class="gmail_extra">-- <br><div><div><span style="color:rgb(51,51,51);font-size:x-small">Saravá,</span></div><div><span style="color:rgb(51,51,51);font-size:x-small">Renato CRON</span></div><div><div style="text-align:right"><font size="1" color="#333333"><a href="http://www.renatocron.com/blog/" target="_blank">http://www.renatocron.com/blog/</a></font></div></div><div style="text-align:right"><font size="1" color="#333333"><a href="http://twitter.com/#!/renato_cron" target="_blank">@renato_cron</a></font></div></div>
</div></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span></span></div></div>
<br><span>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></span></blockquote></div><span><br><br clear="all"><br>-- <br><div>Leonardo Ruoso<div>Journalist, Perl developer and business consultant<br><div>Media, UFC/2006; Telecom, IFCE/1998</div></div></div>
</span></div></div>
<br>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org" target="_blank">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div><br></div></div>
<br>=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div>