On peut comparer facilement Goliath à node.js car c'est aussi un framework asynchrone (event driven).
L'avantage de Goliath (hormis qu'il est écrit en Ruby pour ceux qui préfèrent ce langage au Javascript), c'est qu'il évite le "spaghetti de code" qu'on retrouve souvent lorsqu'on utilise un framework asynchrone (les développeurs de node.js sauront de quoi je parle), on peut effectivement coder en pensant "synchrone" et le framework et surtout les drivers s'occupent du reste en background.
L’inconvénient, c'est que contrairement à node.js où il faut absolument écrire en asynchrone sinon ca ne marche pas, il faudra que le développeur fasse attention aux drivers qu'il utilise et l'architecture de son programme (aucun appel ne doit être bloquant).
Ilya Grigorik, un des créateurs de Goliath, explique que le use case principal de Goliath est de fournir le "datasource" d'applications Rails ou Sinatra (popuplaires frameworks Ruby), en offrant l'abstraction de ressources externes de type API, Rails ayant plus comme vocation d'être user facing. Pour ceux qui connaissent l'architecture Rack (interface standard entre les servers web et les frameworks ruby), Goliath peut se placer comme endpoint et servir du XML, du JSON, ... et peut donc s'intégrer facilement avec une application Rails.
Au rayon performance, pour le moment Ruby MRI (runtime officiel) 1.9.2 fait tourner Goliath le plus rapidement. Mais JRuby qui n'a pas de GIL (global Interpretation Lock) devrait pouvoir sous peu battre MRI car il mappe les fibers Ruby (coroutines) en Java threads, sans lock au milieu.
Goliath devrait démocratiser le code asynchrone dans l'écosystème Ruby, car EventMachine n'a rien à prouver au niveau performances mais pouvait être rebutant pour des gros projets car le code asynchrone est plus difficilement lisible, maintenable et surtout debuggable.
# Goliath
Posté par EppO . En réponse à la dépêche En vrac spécial Ruby : JRuby, Sinatra et Goliath. Évalué à 6.
On peut comparer facilement Goliath à node.js car c'est aussi un framework asynchrone (event driven).
L'avantage de Goliath (hormis qu'il est écrit en Ruby pour ceux qui préfèrent ce langage au Javascript), c'est qu'il évite le "spaghetti de code" qu'on retrouve souvent lorsqu'on utilise un framework asynchrone (les développeurs de node.js sauront de quoi je parle), on peut effectivement coder en pensant "synchrone" et le framework et surtout les drivers s'occupent du reste en background.
L’inconvénient, c'est que contrairement à node.js où il faut absolument écrire en asynchrone sinon ca ne marche pas, il faudra que le développeur fasse attention aux drivers qu'il utilise et l'architecture de son programme (aucun appel ne doit être bloquant).
Ilya Grigorik, un des créateurs de Goliath, explique que le use case principal de Goliath est de fournir le "datasource" d'applications Rails ou Sinatra (popuplaires frameworks Ruby), en offrant l'abstraction de ressources externes de type API, Rails ayant plus comme vocation d'être user facing. Pour ceux qui connaissent l'architecture Rack (interface standard entre les servers web et les frameworks ruby), Goliath peut se placer comme endpoint et servir du XML, du JSON, ... et peut donc s'intégrer facilement avec une application Rails.
Au rayon performance, pour le moment Ruby MRI (runtime officiel) 1.9.2 fait tourner Goliath le plus rapidement. Mais JRuby qui n'a pas de GIL (global Interpretation Lock) devrait pouvoir sous peu battre MRI car il mappe les fibers Ruby (coroutines) en Java threads, sans lock au milieu.
Goliath devrait démocratiser le code asynchrone dans l'écosystème Ruby, car EventMachine n'a rien à prouver au niveau performances mais pouvait être rebutant pour des gros projets car le code asynchrone est plus difficilement lisible, maintenable et surtout debuggable.