Choix du langage CGI

Question

Ok, j'ai posé quelques questions sur le même sujet ici et j'ai fini par en poser d'autres. Je réalise maintenant que c'est parce que je n'ai pas assez d'informations de base. Je vais donc rendre la question plus générale :

J'ai besoin de créer une application web simple. Des pages statiques HTML/JQuery enverront des requêtes POST AJAX à un code côté serveur, qui.. :

• Lire les variables POST passées dans
• Exécuter quelques très simple logique
• Lancez une base de données MySQL pour des opérations CRUD simples.
• Retourne une chaîne de données en clair qui sera utilisée par le javascript de la page.

J'ai supposé que Ruby était un bon choix pour cela, car tout le monde s'extasie sur la qualité de sa conception, et j'ai joué avec - pas RoR, juste Ruby pour les tâches de script simples - et je l'aime bien.

Ma question est la suivante : je suis désespérément confus par les trillions de bibliothèques d'aide et de frameworks qui existent. Je ne sais pas ce qu'ils sont et, par conséquent, si j'ai besoin d'un ou de plusieurs d'entre eux : Rack, Sinatra, Camping, mod_ruby, FastCGI, etc.

Serait-il plus facile d'apprendre le PHP et de l'utiliser ? Ou puis-je m'en sortir en plaçant mes fichiers .rb dans le dossier cgi-bin (j'utilise Apache pour l'hébergement) et en utilisant la bibliothèque ruby cgi pour obtenir mes variables ?

EDIT : En ce qui concerne Rails, je suppose que c'est trop pour ce que je veux, mais je peux me tromper. Je l'ai regardé, et il semblait cool pour générer rapidement des sites web basés sur des données, mais ce n'est pas ce que j'essaie de faire. Je ne veux pas de pages de formulaires pour l'utilisateur. Je ne veux pas qu'il entre des données ou qu'il consulte des enregistrements. Je ne veux même pas retourner du HTML. Je veux juste un ruby script qui s'installe sur le serveur, se fait passer quelques variables dans une requête post, et renvoie une chaîne JSON en réponse. J'aurai besoin d'une gestion de base des cookies, des sessions et des états.

C'est une chose très facile à faire en C# et ASP.NET avec les webservices, mais cela semble très déroutant avec les technologies open source.

Answer 1

Utilisez jQuery et PHP.

Les deux technologies sont bien documentées et vous devriez être en mesure de mettre en place une application en quelques heures. Vous semblez connaître une chose ou deux - parler des opérations CRUD et ainsi de suite - donc je ne vous ennuierai pas avec des exemples. Et pour ce qui est de JSON, il existe probablement un million de bibliothèques PHP permettant de générer des objets JSON.

Answer 2

Vous ne voulez pas utiliser les fonctionnalités d'un framework complet, alors n'en utilisez pas. Moins de code = moins de bogues = moins de cauchemars en matière de sécurité.

CGI

Le CGI présente quelques inconvénients en termes de performances par rapport aux autres méthodes, mais reste (à mon avis) la plus simple et la plus facile à utiliser. C'est ainsi que vous utilisez la bibliothèque cgi intégrée :

require "cgi"
cgi= CGI.new

answer= evaluate(cgi.params)

cgi.out do
    answer
end

rack

Une autre variante de faible technicité et facile à utiliser serait le rack. Rack est une couche d'abstraction qui fonctionne pour de nombreuses interfaces de serveur web (cgi, fastcgi, webrick, ). Sa simplicité peut être comparée à celle de l'utilisation de cgi. Mettez ce qui suit dans un fichier qui se termine par .ru dans votre répertoire cgi.

#!/usr/bin/rackup
require "rack/request"

run (lambda do |env|
  request= Rack::Request(env)

  anwser= evaluate(request.params)

  return [200, {}, answer]
end)

Cela ne semble pas très différent du CGI, mais cela vous donne beaucoup plus de possibilités. Si vous exécutez ce fichier sur votre machine locale, rackup démarrera le serveur webrick. Ce serveur fournira les pages web que vous avez décrites dans votre fichier .ru.

Autres interfaces

fast-cgi

Le fast-cgi fonctionne presque comme le CGI. La différence est que, dans CGI, votre script est lancé pour chaque requête sur laquelle il doit travailler. Avec fast-cgi, votre script ne démarre qu'une fois pour toutes les requêtes. Il existe une bibliothèque pour écrire des script fast-cgi en ruby.

mod_ruby

mod_ruby est un interpréteur ruby intégré pour apache. Il fonctionne de manière analogue à mod_php dans apache.

bâtard

mongrel est un serveur web autonome pour les applications ruby. Voici un exemple simple de hello world avec lui.

require 'mongrel'

class SimpleHandler < Mongrel::HttpHandler
   def process(request, response)
     response.start(200) do |head,out|
       head["Content-Type"] = "text/plain"
       out.write("hello world!\n")
     end
   end
end

h = Mongrel::HttpServer.new("0.0.0.0", "3000")
h.register("/hello", SimpleHandler.new)
h.run.join

Mongrel est souvent utilisé pour rails et autres frameworks ruby. La plupart des gens utilisent un apache ou autre sur le port 80. Ce serveur web distribue ensuite les demandes à plusieurs serveurs Mongrel fonctionnant sur d'autres ports. Je pense que c'est totalement excessif pour vos besoins.

passager de phusion

passenger est également appelé mod_rails ou mod_rack. Il s'agit d'un module pour apache et nginx permettant d'héberger des applications rails et rack. Selon leurs sites web, rails avec passenger utilise 1/3 de ram en moins que rails seul. Si vous écrivez votre logiciel pour rack, vous pouvez le rendre un peu plus rapide en utilisant passenger, au lieu de cgi ou fast-cgi.

Answer 3

Sinatra est très simple à apprendre et à utiliser. Il est également facile à déployer avec l'utilisation de Phusion Passenger (qui est comme mod_php pour les frameworks ruby comme Rails et Sinatra). Instructions ici : http://blog.squarefour.net/2009/03/06/deploying-sinatra-on-passenger/

Si vous trouvez que vous avez besoin de plus que ce que Sinatra peut vous donner, je vous recommande Rails. Le mettre en place avec Passenger est encore plus facile puisque presque aucune configuration n'est requise. (voir modrails.com).

Answer 4

PHP est très facile à utiliser car il a été conçu spécifiquement pour ce genre de choses. Vous voulez lire les variables POST ? Elles sont dans $_POST. Vous voulez interroger MySQL ? mysql_query("SELECT `something` FROM `table`") ;. Et si vous avez besoin d'aide, une recherche Google sur "php what_you_need_to_do" renvoie presque toujours des résultats sur php.net, ce qui est très utile.

Et pour ce que vous faites, vous n'avez pas besoin de cadres supplémentaires.

Answer 5

Je suis curieux de ce que je perçois comme étant votre résistance à essayer Rails. Vous dites que vous voulez "passer plus de temps sur les scripts eux-mêmes et moins sur la configuration", et pourtant vous semblez rejeter Rails d'emblée. Rails privilégie les conventions à la configuration. Si vous prenez le temps d'apprendre comment Rails fait les choses, vous pouvez obtenir une quantité incroyable de fonctionnalités "gratuitement" en suivant simplement les conventions du framework.

Si vous souhaitez créer une application web simple, Rails est vraiment un moyen très simple et efficace de commencer. Vous pouvez utiliser une base de données sqlite sans même avoir à vous soucier de MySQL (ce n'est pas évolutif, mais pour l'apprentissage ou les applications simples, c'est très bien). Il est vrai qu'il existe des frameworks plus simples, mais comme vous semblez débuter dans la programmation web, je vous recommande de commencer par ce qui vous apportera le plus de soutien en termes de documentation et de personnes compétentes. Suivez le vieil adage : commencez par le faire fonctionner, puis optimisez-le plus tard.

Le seul point de friction que je vois est l'intégration d'Apache... Le consensus sur le déploiement de Rails ces jours-ci semble se concentrer sur l'utilisation de httpds légers à la place d'Apache. Il existe un mod_fcgid qui semble être la meilleure façon de le faire avec Apache (mod_ruby est déprécié, bogué et lent, aux dernières nouvelles) si vous pouvez faire des mods personnalisés. Ou bien il y a Phusion Passenger, qui semble être le dernier et le meilleur moyen de le faire. L'exécution de Rails dans un environnement CGI standard donnera des performances épouvantables (mais cela vaut pour n'importe quel framework CGI, vraiment) en raison de la surcharge que représente l'exécution de l'interpréteur + le framework pour chaque requête. Vous obtiendrez de bien meilleures performances si vous optez pour quelque chose qui garde l'interpréteur et le framework en mémoire.