Gema para realizar requests

[Mariano Matayoshi]

Gente, como les va?

Les escribo para contarles que en Casapick hicimos una gema hace un tiempo y me gustaría compartirlas con ustedes, se llama PaperCup, la hicimos con la idea de realizar request sin usar ninguna otra herramienta que Curl o Ruby. La mayoría de las gemas usan a su vez otra gema para realizar request, nosotros utilizamos el método Open3 de Ruby junto al famoso Curl.

Cualquier feedback es bienvenido.

Saludos!! 

[Pablo Astigarraga]

Hola Mariano, felicidades por la publicación! 

Pregunta: hicieron benchmarks de casualidad para ver como se compara en performance con otras alternativas? Creo que usar Open3 va a ser un poco lento considerando que lanza un proceso nuevo, quizás usar los bindings de libcurl como hace Curb les funcione mejor en ese sentido.

Entiendo las ganas de sacar dependencias, pero personalmente prefiero gemas que no dependan de curl, lamentablemente Net::HTTP es horrible, pero hay gemas como Requests que se las arreglan para dar una API linda manteniendose sencilla y sin dependencias fuera de la standard library, esa última es la que uso yo. :)

Saludos!

--
Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a rubysur+u...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Mariano Matayoshi]

Hola Pablo!

No, no hicimos benchmarks pero con lo que me dijiste lo voy a hacer, nosotros veníamos usando RestClient y Blanket, pero nos cansamos e hicimos PaperCup.

Gracias por los tips!

[Damian Janowski]

2015-10-22 16:26 GMT-03:00 Mariano Matayoshi <matayosh...@gmail.com>:
> [...]
>
> Cualquier feedback es bienvenido.

- Qué cosas son las que no les gustaban de las librerías que venían
usando? Sería bueno explicarlo en el README, en el contexto de la
motivación que los lleva a introducir esta nueva gema al mundo.

- Como dice Pote, abrir un nuevo proceso por request ya va a tener un
overhead bastante importante, entonces las ventajas de esto tendrían
que ser muy evidentes. (Además de ser más lento de por sí, no permite
hacer cosas que ayudan a la performance como mantener conexiones
persistentes.)

- El comando a ejecutar lo están armando con sprintf (!). Si insisten
en disparar un subproceso, miren Shellwords [1] para escapar todo lo
que hace falta. O directamente pasen los parámetros en un array como
permite Process.spawn [2].

- En general, la forma de detectar si una respuesta de HTTP es JSON es
mirar el header Content-Type. Sniffearlo [3] no me parece una buena
idea para tus usuarios. (Y si insisten en sniffear, por lo menos no
parseen dos veces.)

- Usar OpenStruct para representar cualquier response no es una buena
práctica y puede exponerte a un ataque de DoS (por lo menos en la
mayoría de las versiones de Ruby). No conocía recursive-open-struct,
es bastante atroz, te recomiendo leer sobre el Global Method Cache [4]
(aunque hay cambios en Ruby 2, sigue siendo un problema si usás cosas
como class_eval dinámicamente). Y, sobre todo, YAGNI.



[1] http://ruby-doc.org/stdlib-2.2.0/libdoc/shellwords/rdoc/Shellwords.html
[2] http://ruby-doc.org/core-2.2.0/Process.html#method-c-spawn
[3] https://github.com/casapick/paper-cup/blob/master/lib/paper_cup/utils.rb
[4] https://github.com/charliesome/charlie.bz/blob/master/posts/things-that-clear-rubys-method-cache.md

[Mariano Matayoshi]

Damian, 

Gracias por todos los insights que me diste, no tenía idea de muchos de ellos.

Abrazo!!

--
Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a rubysur+u...@googlegroups.com.

Para obtener más opciones, visita https://groups.google.com/d/optout.