[SP-pm] Resumo do Evento Técnico

Sun Feb 1 04:57:10 PST 2015

Em 1 de fevereiro de 2015 10:07, Blabos de Blebe <blabos em gmail.com>
escreveu:

> Gente vocês estão fazendo eu me sentir velho!
>

> A solução pra indexar aplicações em AngularJS existe desde 1999.
>

Formas "criativas" para indexar softwares cujos clientes são implementados
em AngularJS existem desde o HTTP 1.0/HTML 1.0, quando não havia sequer CSS.

Solução formal para indexar aplicações cujo cliente é AngularJS existe
formalmente desde 2000 (Rest é uma inovação tecnológica quando propõe
aplicar o conceito Web a Comunicação Interprocessual). Essa solução
chama-se REST!

> Ninguém lembra dela porque ela foi criada "antes" do Google indexar
> páginas. Confesso que eu mesmo não me lembrava até pouco tempo atrás.
> Nunca usei. É genial de tão boba. KISS.
>
Pago uma cerveja pra quem fizer o dever de casa (Ruoso, vc não).
>

Até pelo fato de que você sabe que eu tenho aplicações JSON-RPC (com
implementação parcial de Rest) feitas com AngularJS e Catalyst e que são
indexadas pelo Google, compartilhadas no Facebook e etc... Então você sabe
que eu aprendi a fazer a gambiarra antes de saber fazer direito.

> ***
>
> Se por um lado, o Ruoso parece um arrogante sabedor da verdade, por
> outro, pelo fato de cada um de nós já ter implementado com sucesso,
> aplicações que contrariam o que ele diz (eu me incluo), também somos
> resistentes a aceitar que a nossa solução é "errada". É errada mesmo?
>

Minha experiência vem de SOAP/WSDL e por conta disso a primeira vez que eu
tive de fazer um aplicação Rest eu implementei, com a ajuda de colegas,
JSON-RPC. Fiz isso e descobri magicamente que a aplicação não era indexada
(todos com que eu trabalhava na época assumiram que o Google seria super
legal com a gente e eu fui absolutamente humilhado na frente dos meus
sócios --lição aprendida: implementamos uma gambiarra para fazer a
aplicação) e conseguimos corrigir isso com um hack cujo suporte é
totalmente formal e totalmente KISS. Agora, depois disso, estou
experimentando e orientando pessoas que estão desenvolvendo aplicações em
AngularJS e estamos sofrendo com todos os velhos problemas de
desenvolvimento de componentes fortemente acoplados, quando o cliente
solicitou que fosse uma aplicação Rest e nós fizemos JSON-RPC uma vez mais.
Isso, necessidade prática, levou-me a buscar saber o que estávamos fazendo
de errado.

Felizmente, em meu projeto atual, eu tenho um substituto para o Eden
(saudades do baiano), e por isso tinha uma pessoa com quem conversar e com
a qual estou aprendendo bastante. Ele é Arquiteto Java e sabe, tem
consciência, de que não está conseguindo fazer as coisas direito no
projeto, que ele ainda não conseguiu estabelecer os componentes corretos de
arquitetura, mas está COMPROMETIDO em melhorar a cada projeto. Isso é algo
que me parece não existir muitas vezes sob a desculpa de que dá muito
trabalho fazer as coisas direito.

> Notem, certo e errado são palavras fortes e podem ser relativas.
>

Certo e errado existem, nem sempre conseguimos fazer o certo, só que nós
não somos padeiros falando de engenharia de software, nós temos obrigação
formal de tratar as coisas pelos nomes certos. Eu não disse em nenhum
momento que ninguém deveria fazer JSON-RPC ou XML-RPC. Eu disse que era
irresponsável apenas adotar uma terminologia sem se preocupar em entender o
que ela significa e os motivos pelos quais é festejada. Mesmo tentando
entender e tentando implementar ainda podemos falhar, mas é nossa
responsabilidade estarmos conscientes disso, não do nosso cliente.

> Muitas vezes estamos lidando com constrains de negócio, como tempo por
> exemplo, motivo pelo qual nem sempre podemos ler a tese do fielding de
> ponta a ponta, o que também não é uma desculpa pra não buscar entender
> melhor as nossas escolhas.
>

Pera, não temos que ler a dissertação dele todos os dias, basta ler uma
vez, duas dependendo da sua dificuldade em apreender conceitos técnicos.

> Essa divergência toda acontece porque o HTTP é um protocolo tão
> simples e tão genial, que ele permite os mais variados usos, ou seja,
> há uma gama enorme de formas de usá-lo. Boas, ruins, mais ou menos,
> ótimas, etc.
>
> HTTP tem tudo a ver com Perl, há mais de uma forma de fazer, algumas
> melhores que as outras. Por que A é melhor que B? Bom, aí depende de
> um monte de fatores e entendê-los bem é (ou deveria ser) o foco dessa
> conversa.
>
> Não é porque eu vou estudar RESTful que eu vou ter que fazer tudo como
> o fielding diz, mas saber por que eu não estou fazendo me dá
> confiança.
>

É certo, inclusive é importante saber quais são as ressalvas que sua
aplicação tem em relação à arquitetura que toma como base. Eu não disse
jamais que não podemos dizer que nossa aplicação é baseada em Rest, mas que
foi feita antes da recomendação JSON-LD sair e por isso usamos JSON-HAL,
que deve ser depreciado agora, por exemplo.

> Coisas que eu gostaria de discutir:
>
> 1) RESTful é a solução pro meu problema? Ou um REST based é melhor?

Eu tenho uma dificuldade grande co Restful e Rest. Temos de entender onde
traçamos a fronteira. Isso é uma dúvida minha.

> Ou um levemente REST inspired?

Considerando que o aspecto mais importante do Rest é o HyperDocument, o que
consideramos Rest based vs o que é simplesmente JSON-RPC?

> Ou seria melhor fazer SOAP? Ou RPC binário? Por quê?
>

RPC binário requer compatibilidade binária.

SOAP é uma especificação bastante madura, que permite manejar documentos e
fazer RPC.

> 2) Existem várias formas de fazer autenticação. Qual a melhor pro meu
> caso? Por que a forma A é melhor que a B?
>

> 3) Como eu versiono? Na URI? No header? Por quê?
>

Eu entendo que ter a versão na URI é equivocada, exceto no caso da versão
ser do objeto em si.

Se a versão é do protocolo, então não deve participar da versão do
documento. Ë a mesma coisa que você ter a versão do HTML (1..5) na URI,
isso seria equivocado.

> 4) Como eu desacoplo os componentes? Eu preciso mesmo ter
> baixo acoplamento? Por quê?
>

Rest engloba uma proposta madura para desacoplar componentes, mas SOAP
também dispõe de soluções viáveis para isso.

Sempre que seu cliente dispuser de informações out-of-band específicas da
aplicação ou do recurso você tem forte acoplamento.

A desvantagem de forte acoplamento é que qualquer mudança em qualquer
recurso/objeto requer uma atualização do cliente e isso é uma desvantagem
até quando estamos falando de ThickClient com Swing, por exemplo. O Swing
já foi feito para que fosse possível desenvolver ThickClient desacoplado ou
menos acoplado aos serviços.

Se falarmos de múltiplos clientes diferentes, integração entre aplicação, é
quase imoral propormos interfaces fortemente acopladas, pois o custo de
manutenção passa a ser algo como (O(n!)) e isso é insustentável
economicamente.

5) E a performance? E o cache?
>

Opa, performance e cache estão no amalgama das vantagens do Rest.

> 6) Como faço upgrades? Como extendo? Como mantenho a compatibilidade?
> Preciso disso? Por quê?
>

Com fraco acomplamento você continua tendo upgrades, exceto que são menos
frequentes e sua aplicação pode continuar funcionando, ao menos com suporte
parcial, à medida em que fica obsoleta. Isso é especialmente importante
falando de IoT.

> 7) Que outras perguntas eu deveria estar fazendo?
>

Eu entendo que autorização é um problema bem mais complexo que
autenticação, por exemplo.

> Eu gostaria muito de nos reunirmos pessoalmente, ao menos uma vez por
> semana, discutir o assunto, eventualmente implementar alguma coisa e
> depois a gente podia escrever a respeito. Pra esse equinócio? Talvez
> sim, talvez esteja muito em cima pra digerir tudo.
>

É minha proposta!

> Dá pra sair até um curso disso.
>

Dá para sair um livro mesmo.

> O que acham?
>

Eu QUERO, como diria o Eduardo Jorge.

>
> []'s
>
> 2015-02-01 7:39 GMT-02:00 Leonardo Ruoso <leonardo em ruoso.com>:
> > Em 31 de janeiro de 2015 22:30, Lucas Mateus
> > <lucasmateus.oliveira em gmail.com> escreveu:
> >>
> >> Indexar uma app AngularJS ? Como se faz isso ?
> >
> >
> > A resposta canônica é, ironicamente considerando esta thread,
> implementando
> > um serviço Rest by the book.
> >
> > Se sua App AngularJS for cliente de um ou mais serviços Rest, você terá
> tudo
> > indexado. De fato, pouco importa seu cliente, pois, a rigor, seu cliente
> é
> > apenas obtido do server, mas ele roda no computador do usuário e poderia
> > mesmo ser distribuído como uma WebApp ou Android App ou iOS App.
> >
> > É nessa ora, ironicamente, que compreender a arquitetura com que se
> pretende
> > trabalhar faz toda a diferença.
> >
> > Enim, se você implementa AngularJS como aplicação cliente de um ou mais
> > serviços Rest, e faz seu Rest de acordo com todos os bons conhecimentos
> > acumulados em SEO, você terá sua aplicação indexada, compartilhada em
> redes
> > sociais, embebida em outros sites, etc… com todos os mesmos conhecimentos
> > que foram acumulados para isso nos últimos 30 anos.
> >
> > Nada muda, pois Rest nada mais é do que: Olha como a WEB é legal e
> funciona,
> > vamos fazer componentes de rede EXATAMENTE como fizemos a WEB, apenas com
> > conteúdo machine readableb.
> >
> > De fato, vocês só levantaram mais um ponto e mostraram ou provaram que
> mesmo
> > um comércio de flores local se beneficia de contratar uma empresa ou
> > consultor atualizado para desenhar seus softwares e que você não precisa
> > trabalhar para Google, Facebook ou Twitter para precisar se preocupar em
> > adquirir conhecimento formal sobre as tecnologias que emprega.
> >
> >>
> >> Enviado pelo meu Windows Phone
> >> ________________________________
> >> De: Leonardo Ruoso
> >> Enviada em: ‎31/‎01/‎2015 21:50
> >> Para: saopaulo-pm em mail.pm.org
> >> Assunto: Re: [SP-pm] Resumo do Evento Técnico
> >>
> >> Em 31 de janeiro de 2015 21:42, Leonardo Ruoso <leonardo em ruoso.com>
> >> escreveu:
> >>>
> >>> Em 31 de janeiro de 2015 19:45, Lucas Mateus
> >>> <lucasmateus.oliveira em gmail.com> escreveu:
> >>>>
> >>>> Cautela em usar AngularJS parece a febre do "vamos fazer tudo em
> mongo"
> >>
> >>
> >> Tem uma única diferença, que é o perfil profissional de quem está
> >> recomendando AngularJS em comparação com o perfil de quem recomenda
> MongoDB.
> >>
> >>
> >>
> >> =begin disclaimer
> >>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
> >>  SaoPaulo-pm mailing list: SaoPaulo-pm em 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 em 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 em 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
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20150201/bee3e007/attachment-0001.html>