I'm looking to make some relatively simple pages with some relatively small pieces of dynamic content inside.
I have looked into embedded Ruby as a potential alternative to php in this situation, and it looks rather interesting. Which implementation should I use, and how should I integrate this with a web server such as Apache? In other words, what is analogous to something like mod_php or php through CGI?
My primary goal here is convenience. I would like this to require less effort to implement and maintain. Also, I am looking to have access to things like HTTP request parameters and other such goodies in a convenient format (i.e. if I use CGI, I don't want to be parsing argv manually).
Thanks.
Probably the easiest solution would be to run an application server via Thin and have Apache proxy to it. Your application can use whatever HTTP and templating libraries you like. Take a look at Sinatra if you're not familiar. It's very lightweight and flexible.
Related
I was trying to create my website using CGI and ERB, but when I search on the web, I see people saying I should always avoid using CGI, and always use Rack.
I understand CGI will fork a lot of Ruby processes, but if I use FastCGI, only one persistent process will be created, and it is adopted by PHP websites too. Plus FastCGI interface only create one object for one request and has very good performance, as opposed to Rack which creates 7 objects at once.
Is there any specific reason I should not use CGI? Or it is just false assumption and it is entirely ok to use CGI/FastCGI?
CGI, by which I mean both the interface and the common programming libraries and practices around it, was written in a different time. It has a view of request handlers as distinct processes connected to the webserver via environment variables and standard I/O streams.
This was state-of-the-art in its day, when there were not really "web frameworks" and "embedded server modules" as we think of them today. Thus...
CGI tends to be slow
Again, the CGI model spawns one new process per connection. While spawning processes per se is cheap these days, heavy web app initialization — reading and parsing scores of modules, making database connections, etc. — makes this quite expensive.
CGI tends toward too-low-level (IMHO) design
Again, the CGI model explicitly mentions environment variables and standard input as the interface between request and handler. But ... who cares? That's much lower level than the app designer should generally be thinking about. If you look at libraries and code based on CGI, you'll see that the bulk of it encourages "business logic" right alongside form parsing and HTML generation, which is now widely seen as a dangerous mixing of concerns.
Contrast with something like Rack::Builder, where right away the coder is thinking of mapping a namespace to an action, and what that means for the broader web application. (Suddenly we are free to argue about the semantic web and the virtues of REST and this and that, because we're not thinking about generating radio buttons based off user-supplied input.)
Yes, something like Rack::Builder could be implemented on top of CGI, but, that's the point. It'd have to be a layer of abstraction built on top of CGI.
CGI tends to be sneeringly dismissed
Despite CGI working perfectly well within its limitations, despite it being simple and widely understood, CGI is often dismissed out of hand. You, too, might be dismissed out of hand if CGI is all you know.
Don't use CGI. Please. It's not worth it. Back in the 1990s when nobody knew better it seemed like a good idea, but that was when scripts were infrequent, used for special cases like handling form submissions, not driving entire sites.
FastCGI is an attempt at a "better CGI" but it's still deficient in a large number of ways, especially because you have to manage your FastCGI worker processes.
Rack is a much better system, and it works very well. If you use Rack, you have a wide variety of hosting systems to choose from, even Passenger which is really simple and reliable.
I don't know what mean when you say Rack creates "7 objects at once" unless you mean there are 7 different Rack processes running somehow or you've made a mistake in your implementation.
I can't think of a single instance where CGI would be better than a Rack equivalent.
There exists a lot of confusion about what CGI, Rack etc. really are. As I describe here, Rack is an API, and FastCGI is a protocol. CGI is also a protocol, but in its narrow sense also an implementation, and for what you're speaking of is not at all the same thing as FastCGI. So let's start with the background.
Back in the early 90s, web servers simply read files (HTML, images, whatever) off the disk and sent them to the client. People started to want to do some processing at the time of the request, and the early solution that came out was to run a program that would produce the result sent back to the client, rather than just reading the file. The "protocol" for this was for the web server to be given a URL that it was configured to execute as a program (e.g., /cgi-bin/my-script), where the web server would then set up a set of environment variables with various information about the request and run the program with the body of the request on the standard input. This was referred to as the "Common Gateway Interface."
Given that this forks off a new process for every request, it's clearly inefficient, and you almost certainly don't want to use this style of dynamic request handling on high-volume web sites. (Starting a whole new process is relatively expensive in computational resources.)
One solution to making this more efficient is to, rather than starting a new process, send the request information to an existing process that's already running. This is what FastCGI is all about; it maintains a very similar interface to CGI (you have a set of variables with most of the request information, and a stream of data for the body of the request). But instead of setting actual Unix environment variables and starting a new process with the body on stdin, it sends a request similar to an HTTP request to an FCGI server already running on the machine where it specifies the values of these variables and the request body contents.
If the web server can have the program code embedded in it somehow, this becomes even more efficient because it just runs the code itself. Two classic examples of how you might do this would be:
Have PHP embedded in Apache, so that the "Apache server code" just calls the "PHP server code" that's part of the same process; and
Not run Apache at all, but have the web server be written in Ruby (or Python, or whatever) and load and run more Ruby code that's been custom-written to handle the request.
So where does Rack come in to this? Rack is an API that lets code that handles web requests receive it in a common way, regardless of the web server. So given some Ruby code to process a request that uses the Rack API, the web server might:
Be a Ruby web server that simply makes function calls in its own process to the Rack-compliant code that it loaded;
Be a web server (written in any language) that uses the FastCGI protocol to talk to another process with FastCGI server code that, again, makes function calls to the Rack-compliant code that handles the request; or
Be a server that starts a brand new process that interprets the CGI environment variables and standard input passed to it and then calls the Rack-compliant code.
So whether you're using CGI, FastCGI, another inter-process protocol, or an intra-process protocol, makes no difference; you can do any of those using Rack so long as the server knows about it or is talking to a process that can understand CGI, FastCGI or whatever and call Rack-compliant code based on that request.
So:
For performance scaling, you definitely don't want to be using CGI; you want to be using FastCGI, a similar protocol (such as the Tomcat one), or direct in-process calling of the code.
If you use the Rack API, you don't need to worry at the early stages which protocol you're using between your web server and your program because the whole point of APIs like Rack is that you can change it later.
I am trying to see if I can create a simple website, like a blog, using only Ruby. No Rails or a database or outside web servers. I plan to store the data in a file for persistence.
I wanted to use TCPServer, CGI, and Net::HTTP.
Is there an easier way I can use?
There are a lot of moving parts when designing a website.
Depending on the purpose of the exercise, you might want to consider using a very simple web framework like Camping, Sinatra, or Ramaze. This is probably the best solution if you're trying to get a top level understanding of web programming because it only has exactly what you need (Camping is less than 4k!) and handles stuff like routing.
Building a web server is more an exercise in HTTP parsing. You might want to omit the framework and try to build something on top of Rake (an API for lots of popular web servers) and a simple web server like Webrick or Thin.
You could also try Espresso
It is easy to learn and fast to run.
And offers all the liberty you need for creation process.
Also it has no hidden "fees", everything is transparent.
WEBrick as the HTTPProxyServer class that makes it easy to set up a simple HTTP proxy server. But I've been running into some issues with this library. Are there any other Ruby alternatives that are equally easy to set up?
You can try EM-Proxy. I haven't worked with it, but from the docs it certainly looks like a simple solution. In fact, there is an example script in the repo.
I can't find this on Google (so maybe it doesn't exist), but I basically'd like to install something on a web server such that I can run a site on Scheme, PHP is starting to annoy me, I want to get rid off it, what I want is:
Run Scheme sources towards UTF-8 output (duh)
Support for SXML, SXLT et cetera, I plan to compose the damned thing in SXML and -> to normal representation on at the end.
Ability to read other files from the server, write them, set permissions et cetera
Also some things to for instance determine the filesize of files, height of images, mime-types and all that mumbo-jumbo
(optionally) connect to a database, but for what I want to do storing the entire database in S-expressions itself is feasible enough
I don't need any fancy libraries and other things that come with it like CMS'es and what-not, except the support for SXML but I'm sure I can just find a lib for that anyway that I can load.
Spark-Scheme has a full web server. If you don't need that, it also has a FastCGI interface so that you can serve Scheme scripts from a web servers like Apache, Lighttpd etc. Spark-Scheme also seem to meet your requirements for database support, UTF-8, file handling and SXML. See the Spark-Scheme Programming Guide (pdf) for more information.
mod_lisp and FastCGI are the only two Apache modules I'm aware of that might work at this time. mod_lisp provides Scheme support because it's architecture is similar to FastCGI, where CGI like parameters are sent over a socket to a second process which remains running as the Scheme backend to the web server. Basically you use one or the other to send CGI like parameters across a socket to a running Scheme backend.
You can find some information about these solutions here. There was another FastCGI like effort called SCGI which demoed a simple SCGI receiver in Scheme called gambit. That code is probably not maintained anymore, but the scheme receiver might be useful.
Back in the Apache 2.0 days, there were more projects playing with scheme and clisp bindings. I don't believe that mod_scheme ever released anything, but if they did, odds are it is not compatible with the modern releases of Apache.
Did you come across Fermion (http://vijaymathew.wordpress.com/2009/08/19/fermion-the-scheme-web-server/)?
If you're looking for a lispy language to develop web applications in, I'd recommend looking into Clojure. Clojure is a lisp variant that's fairly close to scheme; here is a list of some of the differences.
Clojure runs on the Java virtual machine and integrates well with Java libraries, and there's a great webapp framework available called Compojure.
Check out Chicken Scheme's Eggs Unlimited. I think what you want is a combination of the sxml- packages coupled with the fastcgi package.
PLT Scheme has a web application server here: http://docs.plt-scheme.org/web-server/index.html
Is Ruby a client- or server-side language?
Both?
After all, there are Ruby programs which are not used as part of a client-server architecture.
If you are talking about Ruby on Rails, then it's typically only used on the server side.
Ruby is an all-purpose script/programming language which can be executed on both client and server environments.
As client-side, you can use it to create a GUI application (or CLI one) to interact with data, communicate with a server, play with media/game, etc. Some framework examples on this level would beShoes, MacRuby, etc.
As server-side, you can use it to store and save data, validate and execute transactions, etc. It's where frameworks like Rails, Merb, Sinatra and others take place, and its -arguably- it's most known mode of operation.
As the previous poster said, on the context of a server/client web application arquitecture, Ruby would be run on the server side. If I'm not mistaken, there have been some advances for running Ruby through the browser (like JS does), but probably not something to be considered for production ready needs.
Ruby does not (typically) execute in the browser, so if you are asking this in the context of a web server/client browser, then Ruby is server-side.
You can of course also execute stand-alone Ruby code on any machine with a Ruby interpreter. It is not confined to web applications.