Wahl der CGI-Sprache

Question

Ok, ich habe hier ein paar verwandte Fragen gestellt und bin nur mit noch mehr Fragen gelandet, und ich merke jetzt, dass es daran liegt, dass ich nicht genug Hintergrundinformationen habe. Also werde ich es allgemeiner machen:

Ich muss eine einfache Webanwendung erstellen. Statische HTML/JQuery-Seiten senden AJAX POST-Anfragen an einige Server-Seite-Code, der wird:

• Lesen Sie die in POST übergebenen Variablen
• Führen Sie einige sehr einfache Logik
• Zugriff auf eine MySQL-Datenbank für einfache CRUD-Operationen
• Rückgabe einer einfachen Zeichenkette von Daten, die vom Javascript auf der Seite verbraucht werden

Ich bin davon ausgegangen, dass Ruby eine gute Wahl dafür ist, da jeder davon schwärmt, wie gut es konzipiert ist, und ich habe damit gespielt - nicht RoR, nur Ruby für einfache Skriptaufgaben - und ich mag es irgendwie.

Meine Frage ist, ich bin hoffnungslos verwirrt durch die Trillion helper Bibliotheken und Frameworks da draußen. Ich weiß nicht, was diese sind und daher, wenn ich einige / alle von ihnen benötigen: Rack, Sinatra, Camping, mod_ruby, FastCGI, etc.

Wäre es einfacher, einfach PHP zu lernen und das zu benutzen? Oder kann ich weg mit nur fallen meine .rb-Dateien in den cgi-bin-Ordner (ich bin mit Apache für Hosting) und verwenden Sie die Ruby cgi-Bibliothek, um meine Variablen zu erhalten?

EDIT: Was Rails betrifft, so nehme ich einfach an, dass es für das, was ich will, zu viel ist, aber ich könnte mich irren. Ich sah es, und es schien cool für die Erstellung von datenbasierten Websites schnell, aber das ist nicht das, was ich zu tun versuche. Ich will keine Formularseiten für den Benutzer. Ich will nicht, dass er Daten eingibt oder Datensätze anzeigt. Ich möchte nicht einmal HTML zurückgeben. Ich möchte nur, dass ein Ruby-Skript auf dem Server sitzt, ein paar Variablen in einer Post-Anfrage übergeben bekommt und einen JSON-String als Antwort zurückgibt. Ich werde einige grundlegende Cookie/Session/Status-Management benötigen

Dies ist in C# und ASP.NET mit Webservices wirklich einfach zu bewerkstelligen, aber mit den Open-Source-Technologien scheint es sehr verwirrend zu sein.

Answer 1

Verwenden Sie jQuery und PHP.

Beide Technologien sind gut dokumentiert, und Sie sollten in der Lage sein, eine Anwendung innerhalb weniger Stunden zum Laufen zu bringen. Sie klingen, als wüssten Sie schon einiges - Sie sprechen von CRUD-Operationen und so weiter - also werde ich Sie nicht mit Beispielen langweilen. Und was JSON betrifft, so gibt es wahrscheinlich eine Million PHP-Bibliotheken, die JSON-Objekte ausgeben können.

Answer 2

Sie wollen keine Funktion eines ausgewachsenen Frameworks verwenden, also verwenden Sie keins. Weniger Code = weniger Bugs = weniger Sicherheitsalpträume.

CGI

CGI hat im Vergleich zu anderen Methoden einige Leistungsnachteile, ist aber (meiner Meinung nach) immer noch die einfachste und am leichtesten zu verwendende Methode. So verwenden Sie die eingebaute cgi-Bibliothek:

require "cgi"
cgi= CGI.new

answer= evaluate(cgi.params)

cgi.out do
    answer
end

Gestell

Eine weitere einfach zu handhabende Variante wäre ein Regal. Rack ist eine Abstraktionsschicht, die für viele Webserver-Schnittstellen (cgi, fastcgi, webrick, ) funktioniert. Die Einfachheit ist vergleichbar mit der, nur cgi zu verwenden. Fügen Sie das Folgende in eine Datei, die mit .ru endet, in Ihr cgi-Verzeichnis ein.

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

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

  anwser= evaluate(request.params)

  return [200, {}, answer]
end)

Das scheint sich nicht sehr von CGI zu unterscheiden, aber es bietet viel mehr Möglichkeiten. Wenn Sie diese Datei auf Ihrem lokalen Rechner ausführen, startet Rackup den Webrick-Webserver. Dieser Webserver wird die Webseiten ausliefern, die Sie in Ihrer .ru-Datei beschrieben haben.

Andere Schnittstellen

fast-cgi

Fast-Cgi funktioniert fast wie CGI. Der Unterschied besteht darin, dass bei CGI Ihr Skript bei jeder Anfrage, die es zu bearbeiten hat, gestartet wird. Mit fast-cgi wird Ihr Skript nur einmal für alle Anfragen gestartet. Es gibt eine Bibliothek, um fast-cgi-Skripte in Ruby zu schreiben.

mod_ruby

mod_ruby ist ein eingebauter Ruby-Interpreter für Apache. Er arbeitet analog zu mod_php in Apache.

Mischling

mongrel ist ein eigenständiger Webserver für Ruby-Anwendungen. Dies ist ein einfaches Hallo-Welt-Beispiel mit ihm.

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 wird häufig für Rails und andere Ruby-Frameworks verwendet. Die meisten Leute verwenden einen Apache oder etwas anderes auf Port 80. Dieser Webserver verteilt dann die Anfragen an mehrere Mongrel-Server, die auf anderen Ports laufen. Ich denke, dass dies für Ihre Bedürfnisse völlig überzogen ist.

Phusion-Passagier

passenger wird auch mod_rails oder mod_rack genannt. Es ist ein Modul für Apache und Nginx zum Hosten von Rails- und Rack-Anwendungen. Laut deren Webseiten benötigt Rails mit passenger 1/3 weniger Ram als Rails alleine. Wenn Sie Ihre Software für Rack schreiben, können Sie sie ein wenig schneller machen, indem Sie passenger anstelle von cgi oder fast-cgi verwenden.

Answer 3

Sinatra ist sehr einfach zu erlernen und zu benutzen. Es ist auch einfach, mit der Verwendung von Phusion Passenger (das ist wie mod_php für Ruby-Frameworks wie Rails und Sinatra) bereitzustellen. Anweisungen hier: http://blog.squarefour.net/2009/03/06/deploying-sinatra-on-passenger/

Wenn Sie mehr brauchen als das, was Sinatra Ihnen bietet, empfehle ich Rails. Die Einrichtung mit Passenger ist sogar noch einfacher, da kaum eine Konfiguration erforderlich ist. (siehe modrails.com).

Answer 4

PHP ist sehr einfach zu benutzen, da es speziell für diese Art von Aufgaben entwickelt wurde. Sie möchten POST-Variablen lesen? Sie befinden sich in $_POST. Wollen Sie MySQL abfragen? mysql_query("SELECT `irgendwas` FROM `Tabelle`");. Und wenn Sie jemals Hilfe brauchen, liefert eine Google-Suche nach "php what_you_need_to_do" fast immer Ergebnisse auf php.net, was sehr hilfreich ist.

Und für das, was Sie tun, brauchen Sie keine zusätzlichen Frameworks.

Answer 5

Ich bin neugierig auf das, was ich als Ihren Widerstand gegen das Ausprobieren von Rails empfinde. Sie sagen, dass Sie "mehr Zeit auf die Skripterstellung selbst und weniger auf die Konfiguration verbringen wollen", und doch scheinen Sie Rails aus der Hand zu verwerfen. Bei Rails geht es mehr um Konventionen als um Konfiguration. Wenn Sie sich die Zeit nehmen, um zu lernen, wie Rails Dinge tut, können Sie eine unglaubliche Menge an Funktionalität "kostenlos" nur durch die Einhaltung der Konventionen des Rahmens erhalten.

Wenn Sie eine einfache Webanwendung erstellen möchten, ist Rails ein sehr einfacher und guter Weg, damit zu beginnen. Sie können eine Sqlite-Datenbank verwenden und müssen sich nicht einmal mit MySQL herumschlagen (wird nicht skalieren, aber zum Lernen oder für einfache Anwendungen ist es in Ordnung). Es ist wahr, dass es einfachere Frameworks gibt, aber da Sie neu in der Webprogrammierung zu sein scheinen, würde ich empfehlen, dass Sie mit dem beginnen, was Ihnen die meiste Unterstützung in Form von Dokumentation und sachkundigen Leuten bietet. Befolgen Sie das alte Sprichwort: Bringen Sie es zuerst zum Laufen, dann optimieren Sie später.

Der einzige Knackpunkt, den ich sehe, ist die Apache-Integration... Der Konsens über den Einsatz von Rails in diesen Tagen scheint auf die Verwendung von leichtgewichtigen httpds anstelle von Apache konzentriert werden. Es gibt ein mod_fcgid, das der beste Weg zu sein scheint, es mit Apache zu tun (mod_ruby ist veraltet, fehlerhaft und langsam, zuletzt habe ich gelesen), wenn Sie benutzerdefinierte Mods tun können. Oder es gibt Phusion Passenger, das der neueste und beste Weg zu sein scheint, dies zu tun. Wenn man Rails in einer Standard-CGI-Umgebung betreibt, ist die Leistung miserabel (aber das gilt eigentlich für jedes CGI-Framework), da der Interpreter und das Framework bei jeder Anfrage ausgeführt werden müssen. Sie erhalten eine viel bessere Leistung, wenn Sie mit etwas, das den Interpreter + Rahmen im Speicher hält gehen.