I did not see that answer in the documentation, https://golang.org/pkg/net/http/.
It seems pretty complete, but typically I find the built in web servers are never recommended, such as Python, PHP, etc., for anything but development.
Yes. It is a 'production' server if you use it as such. There is no reason why you would not. It is was made with the intent of you using it for real production applications, not just for testing and playing around with the language.
Related
Web applications frameworks such as sinatra (ruby), play (scala), lift (scala) produces a web server listening to a specific port.
I know there are some reasons like security, clustering and, in some cases, performance, that may lead me to use an apache web server in front of my web application one.
Do you have any reasons for this from your experience?
Part of any web application is fully standardized and commoditized functionality. The mature web servers like nginx or apache can do the following things. They can do the following things in a way that is very likely more correct, more efficient, more stable, more secure, more familiar to sysadmins, and more easy to configure than anything you could rewrite in your application server.
Serve static files such as HTML, images, CSS, javascript, fonts, etc
Handle virtual hosting (multiple domains on a single IP address)
URL rewriting
hostname rewriting/redirecting
TLS termination (thanks #emt14)
compression (thanks #JacobusR)
A separate web server provides the ability to serve a "down for maintenance" page while your application server restarts or crashes
Reverse proxies can provide load balancing and fault tolerance for you application framework
Web servers have built-in and tested mechanisms for binding to privileged ports (below 1024) as root and then executing as a non-privileged user. Most web application frameworks do not do this by default.
Mature web servers are battle hardened and stable. By stable, I mean that they quite literally almost never crash. Your web application is almost certainly far less stable. This gives you the ability to at least serve a pretty error page to the user saying your application is down instead of the web browser just displaying a generic "could not connect" error.
Anecdotal case in point: nginx handles attack that would otherwise DoS node.js: http://blog.nodejs.org/2013/10/22/cve-2013-4450-http-server-pipeline-flood-dos/
And just in case you want the semi-official answer from Isaac Schluetter at the Airbnb tech talk on January 30, 2013 around 40 minutes in he addresses the question of whether node is stable & secure enough to serve connections directly to the Internet. His answer is essentially "yes" it is fine. So you can do it and you will probably be fine from a stability and security standpoint (assuming you are using cluster to handle unexpected termination of an app server process), but as detailed above the reality of current operations is that still almost everybody runs node behind a separate web server or reverse proxy/cache.
I would add:
ssl handling
for some servers like apache lots of modules (i.e.
ntml/kerberos authentication)
Web servers are much better for some things compared to your application, like serving static.
Quite often the frameworks do everything you need, but sometimes, adding a layer on top of that can give you seemingly free functionality like compression, security, session management, load balancing, etc. Still, adding a web server may also introduce security issues, for example, chances are your web server security may be compromised easier than Lift by itself. Also, some of the web frameworks are extremely scalable and may even be hampered by an ill chosen web server.
In summary, if you require web server like functionality that is not provided by the framework, then a web server may be a very good option, but keep in mind that it's one more thing to configure properly and update regularly with security patches, etc.
If for example, you just need encryption, or compression, then you may find that adding the correct library or plug-in to your framework may do just that (and only that)
With a proxy http server, the framework doesn't need to keep an http connection open for giving the computed content and can then start serving some other request. It acts as a buffer.
It's an issue of reinventing the wheel. Most frameworks will give you a development environment but for production it's usually good practice to use a commercial/open source project that is able to deal with all issues that arise during production.
Guys building a Framework will have the framework to concentrate on whilst guys building a server are doing just the same(perfecting).
How does one go about testing the server-side performance of a web application?
I'm working on a small web application (specifically, it will solely be responding to AJAX requests with database rows). I want to see how it performs under load. However, I cannot upload it to an internet host right away. The development environment is, however, part of the local intranet, so I can use as many machines as I want to hammer the development server, presumably using Python in conjunction with urllib2.
My question is, is such an approach really accurate for determining the high-load performance of a server-side script? Is there a better way to do this? Am I missing something here?
Have you tried a tool like Apache JMeter? http://jmeter.apache.org/
Is Node.js quicker and more scalable than Apache? Are there any performance figures to back up Node.js's performance for a web application over Apache?
UPDATE: Ok maybe my question (above) is confusing because I am a little confused as to how Node.js sits within a web stack. Under what circumstances should I consider using Node.js instead of a more traditional stack like PHP, MySQL and Apache - or does Node.js play it's part in this stack?
Node.js is a framework particularly well suited for writing high performance web applications without having to understand how to implement concurrency at a low level. It is a framework for writing server-side JavaScript apps using non-blocking IO: passing continuations to IO calls rather than waiting on results. Node.js provides a system API (filesystem access, network access, etc.) where all of the API calls take a continuation which the runtime will execute later with the result, rather than block and return the result to the original caller.
You can use by itself, if you like. But you might want a dedicated reverse proxy in front of Node.js: something like Apache, Nginx, LigHTTPD, etc. Or, for clustering a bigger app, you might want something like HAProxy in front of multiple running Node.js app servers.
There is a recent (July 28th, published 30th) Google Tech Talk about Node.js where there are a few performance numbers and where he also talks about scaling.
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.