Hacker News Reader

Comment by nosefrog | Hacker News Reader

This is very useful. I'm in the middle of a Racket web project right now and I got hung up on parsing/processing form data. The Racket docs are very thorough, but they can be confusing if you don't know what you're looking for.

If anyone here has experience with web stuff in Racket, I've set up a small skeleton for Racket web projects: https://github.com/samertm/web-project-bootstrap.rkt

Right now it contains skeletons for talking to sqlite, setting up a router and handlers, and manipulating the web server from the command line. I need to add an ORM (I'm not sure if Racket has any up-to-date ORMs?) and static file handlers. I'd love help or feedback!

View on HN

How exactly are you hung up with form data? Its low level, so you certainly can't get validation out of box, but otherwise in my experience getting form data out is fairly straight forward. I recently wrote my first Racket web app. Its not pretty or following best practices but you can take a look.

https://github.com/vishesh/whalebin

Thank you! Your project was helpful to skim through. Do you have any additions to the web-project-bootstrap.rkt project?

BTW, this is what I mean by form bindings being confusing: according to the docs, request-bindings is dangerous and shouldn't be used http://docs.racket-lang.org/web-server/http.html#%28mod-path... . That's kind of confusing, because request-bindings is used in the tutorial docs: http://docs.racket-lang.org/continue/#%28def._%28%28lib._web...

And the function that Matt Might uses, request-post-data/raw, isn't even in the docs! Haha, so handling forms has been a bit of a pain for me :)

Good to know! I followed the tutorial and they were using it there, and didn't see the docs after that. I see that the Matt's blog handles the problem with request-binding himself, by doing ensuring encoding conversions, and gets over the file uploading problem. So I would replace my code with the way he does.

For your boilerplate, you may want to add bunch of options to serve/servlet such static files path, stateless? (to not use continuations) etc...

The problems are not really Racket specific. They arise from trying to validate, parse, and execute upon the arbitrary input that can be passed in request bindings. The fact that all values are turned into lower case bit my as I worked on my first web-app. Getting bit by a cross site scripting [XSS] attack would have been worse. There's just a lot of work that goes into producing production quality webb apps when the app is worth producing that can't be covered in a tutorial. The Continue tutorial is a high level overview of the tools Racket provides (e.g. interfacing with persistant storage). The More tutorial gets deeper under the hood and covers dispatching on URI's with a server. Dispatching is generally going to provide simpler contexts for dealing with user data.

The request-post-data/raw function is in the docs: http://docs.racket-lang.org/web-server/http.html?q=post-data...

request is a struct with the field post-data/raw, so this implies that request-post-data/raw can access the field.

http://docs.racket-lang.org/web-server/http.html?q=request#%...

From you experience, how is performance? what would you compare it too? The examples ae useful, thank you.

I haven't written any big projects in Racket, so I can't say how it fares on real-world projects with real-world data, but here are the results for a very minimal Racket project using ApacheBench:

~ $ ab -n 100 -c 10 "http://localhost:8888/"

This is ApacheBench, Version 2.3 <$Revision: 1638069 $>

Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient).....done

Server Software: Racket

Server Hostname: localhost

Server Port: 8888

Document Path: /

Document Length: 89 bytes

Concurrency Level: 10

Time taken for tests: 0.084 seconds

Complete requests: 100

Failed requests: 0

Total transferred: 26800 bytes

HTML transferred: 8900 bytes

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

Time per request: 8.387 [ms] (mean)

Time per request: 0.839 [ms] (mean, across all concurrent requests)

Transfer rate: 312.05 [Kbytes/sec] received

Without a baseline comparison against other servers with same functionality on the same computer, these results mean nothing.

For example here are benchmarks from Django's single-threaded debug webserver:

Benchmarking 127.0.0.1 (be patient).....done

Server Software: WSGIServer/0.1

Server Hostname: 127.0.0.1

Server Port: 8000

Document Path: /

Document Length: 2 bytes

Concurrency Level: 10

Time taken for tests: 0.100 seconds

Complete requests: 100

Failed requests: 0

Total transferred: 16400 bytes

HTML transferred: 200 bytes

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

Time per request: 10.011 [ms] (mean)

Time per request: 1.001 [ms] (mean, across all concurrent requests)

Transfer rate: 159.98 [Kbytes/sec] received

Or Nginx returning the same thing:

Benchmarking 127.0.0.1 (be patient).....done

Server Software: nginx/1.6.2 Server Hostname: 127.0.0.1 Server Port: 9080

Document Path: /gangam Document Length: 14 bytes

Concurrency Level: 10 Time taken for tests: 0.013 seconds Complete requests: 100 Failed requests: 0 Total transferred: 15600 bytes HTML transferred: 1400 bytes Requests per second: 7478.31 [#/sec] (mean) Time per request: 1.337 [ms] (mean) Time per request: 0.134 [ms] (mean, across all concurrent requests) Transfer rate: 1139.27 [Kbytes/sec] received

Reply on news.ycombinator.com