AMF3 vs JSON

[Hugo Ferreira]

Bom dia,

Estava a ponderar passar de AMF3 para JSON.

Ambos os formatos são compactos (ao contrário do SOAP).

Este benchamark já tem uma década mas dúvido que se tenha alterado muito: http://www.jamesward.com/2007/04/30/ajax-and-flex-data-loading-benchmarks/

A performance para mim está acima de utilizar um protocolo que se tenha tornado padrão.

Fazer este tipo de teste requer ainda bastante trabalho (basicamente é fazer a transição para perceber se vale a pena).

Alguém que tenha tido contacto com esta comparação digamos nos últimos 3/4 anos ?

[João Fernandes]

AMF será sermpre mais compacto que JSON out of the box, no entanto, podes sempre implementar um sistema de compressão de input/output para reduzir o tamanho dos dados. 

Nós acabamos por usar gzip directamente nos dados (JSON) e tivemos alguns ganhos mas podes sempre tentar compactar com algo do género https://msgpack.org/index.html que tem várias implementações. Este formato tem uma pequena vantagem relativamente ao AMF que é o tamanho da informação ser dinâmica enquanto que no AMF, a spec obriga a que o "excedente" seja complementado com padding para preencher o resto do espaço reservado para a definição.

--
Recebeu esta mensagem porque subscreveu ao grupo "Mailing List da Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" do Grupos do Google.
Para anular a subscrição deste grupo e parar de receber emails do mesmo, envie um email para riapt+unsubscribe@googlegroups.com.
Para publicar uma mensagem neste grupo, envie um email para ri...@googlegroups.com.
Visite este grupo em https://groups.google.com/group/riapt.
Para mais opções, visite https://groups.google.com/d/optout.

--

João Fernandes

[Hugo Ferreira]

Excelente.

Realmente têm um suporte muito vasto.

AS3 e C# que são as que preciso.

Pelo que dizes, então em teoria, até poderá ter melhor performance (pouca certamente) em relação AMF3 mas tenho literalmente centenas de serviços e no total o ganho poderá ser notório.

Vale a pena experimentar.

A desvantagem a meu ver é que tornará os serviços menos "standard" mas como suportam basicamente o top 50 das linguagens de programação mais utilizadas, acaba-se por colmatar essa desvantagem (melhor que AMF3).

[João Fernandes]

Vai partilhando os resultados obtidos.

2017-11-07 14:58 GMT+00:00 Hugo Ferreira <hferre...@gmail.com>:

Excelente.

Realmente têm um suporte muito vasto.

AS3 e C# que são as que preciso.

Pelo que dizes, então em teoria, até poderá ter melhor performance (pouca certamente) em relação AMF3 mas tenho literalmente centenas de serviços e no total o ganho poderá ser notório.

Vale a pena experimentar.

A desvantagem a meu ver é que tornará os serviços menos "standard" mas como suportam basicamente o top 50 das linguagens de programação mais utilizadas, acaba-se por colmatar essa desvantagem (melhor que AMF3).

--

João Fernandes

[Hugo Ferreira]

Claro que sim.

Vai dar um gráfico bastante interessante, até porque o caso de uso utiliza centenas de serviços AMF3 versus JSON com compressão.

No entanto vai ser uma transição que vai demorar ainda algum tempo.

Sou muito exigente nos meus refactorings.

Acho que são essenciais para continuar a evoluir no sentido tecnológico mas muito conservador no sentido de não quebrar nada.

Prefiro ter de dar um passo atrás para depois poder dar 2 à frente.

Que se faça uma coisa mas que se faça bem feita :)

Um abraço e vou dar novidades daqui a uns tempos assim que as tiver :)

[João Fernandes]

Podes sempre criar uma gateway única que vá consumir os serviços já existentes. Foi o que fizemos quando avançamos para uma aplicação HTML, criei uma gateway única server side que permitia consumir qualquer serviço existente mas via JSON em vez de amf ou webservice. 

On Nov 9, 2017 10:22 PM, "Hugo Ferreira" <hferre...@gmail.com> wrote:

Claro que sim.

Vai dar um gráfico bastante interessante, até porque o caso de uso utiliza centenas de serviços AMF3 versus JSON com compressão.

No entanto vai ser uma transição que vai demorar ainda algum tempo.

Sou muito exigente nos meus refactorings.

Acho que são essenciais para continuar a evoluir no sentido tecnológico mas muito conservador no sentido de não quebrar nada.

Prefiro ter de dar um passo atrás para depois poder dar 2 à frente.

Que se faça uma coisa mas que se faça bem feita :)

Um abraço e vou dar novidades daqui a uns tempos assim que as tiver :)

[Rui Cruz]

Se estiveres a usar amfPhp basta no fim do url colocar "https://api.yourdomain.com/amfService.php?contentType=application/json"

Abraço!

[Hugo Ferreira]

Neste caso não.

Por acaso este projeto já utilizou o amfPHP, pois nasceu de um backend magro em PHP.

Há cerca de 2 anos a metodologia alterou-se para um backend mais gordo e como tal, rescrevi na integra para C# (ASP .NET 4.6), usando para o efeito FluorineFx (uma versão bastante alterada para corrigir diversos erros).

Tenciono em 2018 mudar para .NET Core 2.0 (ou 2.1 se já for o caso na altura).

Pelos meus testes de compatibilidade, o FluorineFx até é compatível mas seria interessante (apesar de não prioritário para mim) mudar para um protocolo mais standard.

Por aquilo que me apercebi, esta é uma tarefa ainda um pouco pesada e que vai demorar semanas a ser desenvolvido num branch à parte e muito mais em testes beta, pelo que vou ter de fazer na altura certa.

No dia 13 de novembro de 2017 às 11:21, Rui Cruz <info.r...@gmail.com> escreveu:

Se estiveres a usar amfPhp basta no fim do url colocar "https://api.yourdomain.com/amfService.php?contentType=application/json"

Abraço!

[Hugo Ferreira]

João,

Queres dizer que tens um serviço genérico e esse sabe "falar" com a compressão definida, recebe o pedido comprimido e já internamente redirecciona para o serviço certo.

Algo género:

GenericService/ServiceName/Data em que o primeiro parâmetro é uma string que definido o serviço e o segundo o parâmetro único comprimido, descomprimes internamente e via reflection sabes o serviço de destino.

Internamente este serviço principal iria ter um switch com centenas de opções (serviços).

É isto que queres dizer ?

No dia 11 de novembro de 2017 às 09:15, João Fernandes <joaopedromar...@gmail.com> escreveu:

[João Fernandes]

No nosso caso não há switch nenhum. Imagina /REST/somewebserviceName/someMethod os parâmetros poderão ser via query string out post a time de fazer a inspeção necessária. No nosso caso se someServiceName não existe ou falta lhe a metadata de exposição, e o mesmo para a função, devolvemos uma mensagem de erro. Podes inclusive armazenar o serviço em cache para não estares sempre a recriar o objecto. 

São algumas das pequenas coisas que fiz para "poupar" tempo na transição para HTML. Agora que o trabalho está feito, é tempo de seguir uma nova rota 😉

On Nov 14, 2017 10:03 AM, "Hugo Ferreira" <hferre...@gmail.com> wrote:

João,

Queres dizer que tens um serviço genérico e esse sabe "falar" com a compressão definida, recebe o pedido comprimido e já internamente redirecciona para o serviço certo.

Algo género:

GenericService/ServiceName/Data em que o primeiro parâmetro é uma string que definido o serviço e o segundo o parâmetro único comprimido, descomprimes internamente e via reflection sabes o serviço de destino.

Internamente este serviço principal iria ter um switch com centenas de opções (serviços).

É isto que queres dizer ?

[Hugo Ferreira]

Confesso que não entendi bem o que disseste.

O que conheço é a WebApi do .NET onde programo os serviços no controller.