Hacker News new | past | comments | ask | show | jobs | submit login
Ran: a simple static web server written in Go (github.com/m3ng9i)
46 points by m3ng9i on Oct 3, 2015 | hide | past | favorite | 41 comments



If in need of serving current dir over HTTP I use

    python -m SimpleHTTPServer
works everywhere I need it to work.

Anyway, kudos for making a Go project shipped, which I fail to accomplish for several months now ;-)


I love SimpleHTTPServer. I use it 80% of the time. One downside is that it's single-threaded, so if you have multiple people who need to fetch stuff from your server it can get pretty painful.

I was helping run a programming workshop last week and I wrote my own tiny concurrent server in Go but in the future I think I'll just use Caddy (https://github.com/mholt/caddy).


For python 3

    python -m http.server


I don't know why but it often takes a really long time for me to reload the web page using Python 2 and 3 on Linux. Anybody has similar experience?


It can only serve one connection at a time, so if you're using it to serve a file download or have multiple users accessing it simultaneously it'll hang for all other clients.


The Go server is likely faster, and it's certainly faster to type "ran" than "python -m SimpleHTTPServer".


> The Go server is likely faster

Which is not usually relevant if you just want to share a file over local HTTP. If you need a production-level HTTP server, you're not using either.

> it's certainly faster to type "ran" than "python -m SimpleHTTPServer".

If you're smart enough to compile ran and put it on your PATH, you're probably smart enough to create an alias for `python -m SimpleHTTPServer`.


> ... faster ... faster

It is faster to use an existing tool (python or another one) than rewriting a 2K LOC one. This is great for learning Go but the compounded time "lost" with a "slow" python server is nothing compared to the time this tool will require in development, debugging and maintenance over the years. As anyone else, I am subject to NIH and I can understand why writing one's own library is interesting by itself. Please don't invent weak excuses like "ran is faster to type".


If you're looking for a quick tool to serve static files from a directory, darkhttpd[1] is also pretty good.

[1]: https://www.unix4lyfe.org/darkhttpd/


This is great. I had a similar need for some work that I did and created a project that does something similar, albeit with less functionality ( https://github.com/spurin/gowebserver )

I took advantage of the cross os compilation and also provide prebuilt binaries for the various os's. Might be worthwhile doing.

I'll add a stub to the readme to see your project.


Something like this would be especially helpful if it added live reload support. Currently I use https://www.npmjs.com/package/live-server for this, but it requires node, NPM, and including its dependencies amounts to ~1000 files. This is decidedly inconvenient in the context where I use it, which is starting out a class by talking all of the students through installing all of the above.

It would be great to have that functionality bundled into a single file executable, or rather three executables for Windows, Mac, Linux.


I use Google's App Engine which has live reload on the development server. My main page is static but I've got one page that's a bit more complicated:

http://www.h4labs.com

http://www.h4labs.com/dev/ios/swift.html


Can someone explain to me the advantages of this over using nginx?


In a lot of cases, nginx is overkill. It's also more focused on being a reverse proxy, while ran is more for simply serving static files. Ran also comes with a cli and some other neat features that would be useless in most cases when working with nginx.


What's the disadvantage to being "overkill" that this remedies? nginx is very easy to install, and a static web server configuration is pretty much the default one. Is this faster? Does it use less memory?


I think the main advantage here is that it's a one-binary-file webserver. Very simple to install and ideal for file sharing among coworkers or similar situations. A modern equivalent of "python -m SimpleHTTPServer".


Yes, "python -m SimpleHTTPServer" is too slow.


Too slow for what?


'python -m SimpleHTTPServer' is actually fairly terrible if you try to use it to share a file amongst coworkers. Try it and you'll see, downloads will actually fail.

It also freaks out if the root dir is blown away, which can be quite common if you're trying to use it with a static site generator.

'python -m SimpleHTTPServer' is great for serving files to yourself but that's about it.


Plug: https://github.com/kidoman/serve

Gets the job done!


Have you had a look at caddy?


Yes, I've heard caddy during the development of Ran. Caddy is a great web server and has more functionalities than Ran. But I enjoy making things, so Ran is born.


Thought you might be interested in it as it is similar, though more focussed on being a reverse proxy in front of other processes. Good luck with Ran.


+1 to Caddy, here's a handy link: https://github.com/mholt/caddy

Very configurable but also very easy to get started.

   $ caddy browse
and off you go.


Related, but requires no command-line to run or setup. https://chrome.google.com/webstore/detail/web-server-for-chr... (MIT License)


Looks interesting for the niche purpose! I certainly can think of a couple of use cases.

But I don't understand why the build script is written in Python? I think that either you should use a simple shell script or stick to Go.


Because I like Python more than Bash script, maybe I'll consider using a more gopher way to do the build.


Go comes with a built in web server that can serve static web pages easily. What's the point of this?


It's handy to have a program, easily compiled for multiple platforms, that can be told to simply serve a given directory, with optional HTTPS support, and no config files or dependencies—just cross-compile to the target arch/OS, scp it over, and run.

Without, you know, having to write it, even if Go's libraries make it fairly easy to do so.

My go-to (haha) for this is Goserve[1]. I'm not sure why I'd switch to this, except that it may now have more eyes on it after today's publicity (it's already got more stars than Goserve—a little advertising goes a long way)

[1] https://github.com/johnsto/goserve


Static file serving is a great tutorial project in Go. I wrote mine (https://github.com/biorisk/httpfolder) to include a file upload option too, but did not add some of the nicer features, e.g., https, in your project.


So 20 or so lines of code is too tough? How much work is involved integrating this server into an app?


Not sure why you think this server was written to integrate into apps. If you can't think of a use for it, that's fine. But lots of other people do have uses for simple static web servers. Including people who don't have the knowledge, time, or patience to hand code a 20 line Go program every time they want to use one.


By integrate I meant interacting with your program, whatever that may be. With the go server, you get everything this program has without the concern of the code going stale or dying should the author abandon it.



I was wandering the same thing. It takes only few lines to set this one up: https://golang.org/pkg/net/http/#FileServer


As I understand, the point is: a simple and practical bash command to http-serve the current directory (implemented in Go).


So everything Go already does but in bash.


Maybe because you don't have to write it yourself?

    $ go get github.com/m3ng9i/ran && ran


How much work is involved integrating this server into your application versus writing 20 lines of Go code? Or less. Maybe more.


Not necessarily. In addition, this kind of program can be really useful for development.

I use "python3 -m http.server" a lot when I'm just testing a bit of HTML/JS and don't want to setup a whole virtual host within Nginx/Apache. It just starts a static file server, on any platform.


So just like go except with benefits.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: