Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A fast and static web server for serving web apps

shortfin.io

Post reply on HN
Print view View original

91–100 of 135 posts

Re: A fast and static web server for serving web apps

#91

Post by WhitneyLand »

ds9 wrote: post #20

What's a "static web server"? I haven't seen this term. A webserver for only static pages, i.e. it won't talk to a runtime? But it's "for serving web apps", this means all the dynamic content is pulled from client side JS? Then you would still need programs on the server to answer AJAX requests. I did not find an explanation on the page or by Googling.

One big thing with this is to develop a web app consisting solely of static files.

The trick is that most of the dynamic stuff you get from REST services on OTHER servers.

For example, people maintain static blogs with Jekyll and can enable commenting with an HTML widget.

Or your app can use MongoLab for it's back end data which again is a separate server.

It turns out you can do almost anything just developing with your own static files.

This is one of the reasons hosting prototype web apps on DropBox is popular.

Re: A fast and static web server for serving web apps

#92

Post by WhitneyLand »

Isofarro wrote: post #69
ds9 wrote: post #54

Earlier quoted context omitted.

Still not much of an app unless the JS does AJAX, but then it's talking to a server that's running some dynamic process, maybe with DB access etc. - right?

Not necessarily. You can make an ajax request to a static resource. The server doesn't have to be a dynamic process. Static resources are just files. A client-side JavaScript Twitter could be done this way. Every tweet, or timeline can be pre-baked into a static json file, and ajaxed in. Twitter can then be simplified to a backend application that updates these files. Granted, tweeting is a separate matter; that requ…

Cross-domain REST is the big win. MongoLab, APIs, Widgets, etc.

Re: A fast and static web server for serving web apps

#93

Post by ChuckMcM »

skrebbel wrote: post #58
ChuckMcM wrote: post #49

Earlier quoted context omitted.

Yes, "static CGI" if such a thing was a thing :-). I've got a thttpd tree that I do this sort of hack in (these are great for monitoring large numbers of servers for example).

I don't understand (and am interested). What's "static" about it? With Apache and mod_rewrite and CGI, I could make the functionality you want (which is, of course, completely not low footprint, but I don't understand how what you want is different from CGI).

Static in the sense that it always executes the one function (doesn't load it from disk, its part of the executable) and so there is never any risk that some other path might get you 'out' of the docs directory and into the cgi_bin directory. So in this case static is code for 'compiled in' versus 'dynamically loaded.'

Re: A fast and static web server for serving web apps

#94

Post by kingatomic »

ChuckMcM wrote: post #36

Close. Can add this to the list like thttpd. Something I keep thinking I'll build is a fast, high connection count, limited HTTP server, something that is essentially a wrapper around a program that works like 'regular' and emits HTML. It is a corner case in a custom corner, but the target it something which is essentially a 'transponder.' In the 'Internet of Things' I want to build a wrapper/environment such that my…

I've used Snorkel[1] for a few C/C++ projects in the past, you may want to check it out; it sounds like it could be what you're looking for (or quite close). Link it with your code, pass it a few config parameters and let it serve static files -- or you can overload GET/POST functions to provide dynamic functionality.

1: http://snorkelembedded.webs.com/

Re: A fast and static web server for serving web apps

#95

Post by rarestblog »

joeblau wrote: post #47

I just ran two speed tests since there aren't any benchmarks provided 1. First Test is using http://www.webpagetest.org/ Results shortfin.io:88 - http://www.webpagetest.org/result/130806_71_13HK/ First View: 1.945s Repeat View: 1.632s Results shortfin.io - http://www.webpagetest.org/result/130806_QV_13F7/ First View 2.099s Repeat View 0.084s 2. Second Test is using Apache Bench Results (Best results of 3 runs): ab -n…

You need some better hardware

$ ab -n 100 -c 100 http://shortfin.io/

Requests per second: 1363.85 [#/sec] (mean)

Re: A fast and static web server for serving web apps

#96

Post by acqq »

timothy89 wrote: post #90
acqq wrote: post #87

Earlier quoted context omitted.

But why do you need reverse proxy at all if your server is as good as Nginx? And if the speed is comparable and Nginx has more features why did you write your server then?

I've never stated that it was as good as nginx? The answer to "why" is answered in these comments: https://news.ycombinator.com/item?id=6168052 https://news.ycombinator.com/item?id=6168541

If I understand, it's "lighter" than Nginx. Why not writing how much lighter and in which aspects? Of course I can compare the code bases, but you know exactly as you wrote yours, so it would be really nice if you'd write what you know. Thanks.

Re: A fast and static web server for serving web apps

#97

Post by rorrr2 »

rarestblog wrote: post #95
joeblau wrote: post #47

I just ran two speed tests since there aren't any benchmarks provided 1. First Test is using http://www.webpagetest.org/ Results shortfin.io:88 - http://www.webpagetest.org/result/130806_71_13HK/ First View: 1.945s Repeat View: 1.632s Results shortfin.io - http://www.webpagetest.org/result/130806_QV_13F7/ First View 2.099s Repeat View 0.084s 2. Second Test is using Apache Bench Results (Best results of 3 runs): ab -n…

You need some better hardware $ ab -n 100 -c 100 http://shortfin.io/ Requests per second: 1363.85 [#/sec] (mean)

Benchmarking a fast remote static server is pointless.

You're basically benchmarking your internet connection.

Re: A fast and static web server for serving web apps

#98

Post by mbreese »

ChuckMcM wrote: post #93
skrebbel wrote: post #58

Earlier quoted context omitted.

I don't understand (and am interested). What's "static" about it? With Apache and mod_rewrite and CGI, I could make the functionality you want (which is, of course, completely not low footprint, but I don't understand how what you want is different from CGI).

Static in the sense that it always executes the one function (doesn't load it from disk, its part of the executable) and so there is never any risk that some other path might get you 'out' of the docs directory and into the cgi_bin directory. So in this case static is code for 'compiled in' versus 'dynamically loaded.'

Like a statically linked HTML document? I know you're talking C code, but I could imagine some kind of HTML to C "compiler" that could you then statically link into an executable. Then you could have a full website that ran as a single static executable, including CGI-esque calls.

Re: A fast and static web server for serving web apps

#99

Post by donutz »

Arnor wrote: post #85
skrebbel wrote: post #56

Earlier quoted context omitted.

Hm, I see your point. How would you then recommend installing non open source software on a production system? E.g. a freeware (but proprietary) FTP server or a database engine.

1. Don't install software from untrusted sources. 2. The trusted sources should provide checksums so you can verify the package before installing it. This protects you from a compromised package so long as the page you accessed the package from has not been compromised (if that page is compromised, the checksum could be changed to the new one). I have no idea how you would verify closed source software if the checksu…

"2. The trusted sources should provide checksums so you can verify the package before installing it."

If the checksum is published to another trusted location, in addition to where you download the files, that would help in the case that an attacker compromises both the checksum and the package on the download site.

The developer could post the checksum to Twitter at the same time as making the package available for download. An attacker would need to compromise both Twitter and the download site.

Post reply on HN