5 ms·

Hi guys, I'm the author of this framework, and it seems that someone shared it here because I started this blog post series this weekend: https://rgm.io/post/ba

Hi guys, I'm the author of this framework, and it seems that someone shared it here because I started this blog post series this weekend: https://rgm.io/post/balde-internals-part1-foundations/ https://rgm.io/post/balde-internals-part1-foundations/ This is why most of the documentation is marked as TODO, but the API docs are reasonably up-to-date. If someone has interest on it or is willing to help, please let me know :) EDIT: simple url shortener example, using redis: https://gist.github.com/rafaelmartins/9f8392a8909e62820ae0 https://gist.github.com/rafaelmartins/9f8392a8909e62820ae0 "complete" app, with templates and stuff: https://github.com/rafaelmartins/bluster https://github.com/rafaelmartins/bluster

35bge57dtjku 10y ago
Is it supposed to do more than hundreds of requests per second??
- rafaelmartins 10y ago
  of course. I'll just get some benchmark results published before doing such claim on the website. :)
  - chmike 10y ago
    Could you please compare it with kore [https://github.com/jorisvink/kore https://github.com/jorisvink/kore] which is another C web server that seam quite efficient when tested with the benchmarking tool wrk [https://github.com/wg/wrk https://github.com/wg/wrk]. Result are bad with the benchmark tool Siege for kore because of its particular request pattern. You might find this set of benchmarks inspirational [https://github.com/nanoant/WebFrameworkBenchmark https://github.com/nanoant/WebFrameworkBenchmark]. The Java web server seam faster because it returns less data. kore is faster in fact. Note: vibe.d has improved its performance with more recent versions. The author of the benchmarks ignore requests to update the benchmarks.
bencollier49 10y ago
Is this meant to be pronounced "baldy"? Are you bald? Excellent name, especially if one or more of the above questions are true!
- rafaelmartins 10y ago
  haha, no, it is a joke with "bucket" in brazilian portuguese, but its not the first time I see someone relating it with bald people ;)
znpy 10y ago
Unless you're going to reference your blog-posts in the documentation and you're willing to keep such documentation updated, I'd strongly recommend you to focus on improving the documentation instead of writing long walls of text on the internals. If I imagine myself using your framework, well, I would be very angry at you if I had to stop writing code, leave my editor and go read your shilly-shally. I would focus on: 1) Topics like "Application structure", "Application Deployment", "Application command-line interface" (which at the moment of writing are all just a "TODO"). 2) Sample code. A 30 lines example is worth a thousand word blog post 3) More sample code. Ideally, one for every crucial part (cookies? session? middlewares?) By the way: I see there are some examples, great! But add some more comments to your examples. 4) Blog post on internals. I'd delay the blog post upon internals because I guess that since you'll be receiving a lot of feedback you might want to change things in the internals thus "invalidating" your blog posts. P.s: congratulations on using doxygen so well! I wish more project had such a well done documentation! p.p.s: I hope you won't find my comment rude or anything, I actually like this project.
- rafaelmartins 10y ago
  hey, thanks for the comment, it is far away from being rude :) blog posts were never the focus, they are mostly for myself, to remember how things work, as I don't work on the framework for some time, and need to have it fresh in mind to write proper docs. it may also help other people willing to help writing docs. also, whoever published balde website here in HN found it due to these blog posts, then they were worth already. :) and to be honest, I'd not publish the framework here in hacker news right now, I'd wait for documentation to be ready, but someone else couldn't wait, so... but you're right. the focus now is writing documentation. thanks
  - ejanus 10y ago
    Great job! But Balde first appeared on HN about 2 years ago, https://news.ycombinator.com/item?id=7765301 https://news.ycombinator.com/item?id=7765301.
- eka808 10y ago
  There is something fantastic with the world of open source : you can enhance the bad parts of a project with your own skills to make it awesome. Basically, if you like the framework and there is no doc, Make a pain to yourself and contribute. p.p.s: I hope you won't find my comment rude or anything
cleeus 10y ago
Using SCGI as the sole backend protocol is a bad idea. I have implemented a C++ SCGI stack myself. The problem with SCGI that I found (of course very late in the game) is that it requires a TCP connection on localhost for every request on the HTTP frontend. This will leave you with a TCP socket in TIME_WAIT state for every logical request. While it is very simple to implement, it's missing pipelining an keep-alive. I think it's a better idea to implement a very minimalistic HTTP backend that can do pipelining and keep-alive with the upstream HTTP server. You don't need to support the full HTTP protocol, just enough to function with nginx/lighttpd/Apache.
- rafaelmartins 10y ago
  thanks for sharing your experience. I appreciate it
- bontoJR 10y ago
  Totally agree with that, I have implemented it as learning project FastCGI and SCGI in Swift few months ago and SCGI seems really weak for a real world project right now, even an easier one. I would also give an extra +1 in recommending to consider interfacing with nginx/lighttpd/Apache.

35bge57dtjku 10y ago

Is it supposed to do more than hundreds of requests per second??

rafaelmartins 10y ago
of course. I'll just get some benchmark results published before doing such claim on the website. :)
- chmike 10y ago
  Could you please compare it with kore [https://github.com/jorisvink/kore https://github.com/jorisvink/kore] which is another C web server that seam quite efficient when tested with the benchmarking tool wrk [https://github.com/wg/wrk https://github.com/wg/wrk]. Result are bad with the benchmark tool Siege for kore because of its particular request pattern. You might find this set of benchmarks inspirational [https://github.com/nanoant/WebFrameworkBenchmark https://github.com/nanoant/WebFrameworkBenchmark]. The Java web server seam faster because it returns less data. kore is faster in fact. Note: vibe.d has improved its performance with more recent versions. The author of the benchmarks ignore requests to update the benchmarks.

bencollier49 10y ago

Is this meant to be pronounced "baldy"? Are you bald? Excellent name, especially if one or more of the above questions are true!

rafaelmartins 10y ago
haha, no, it is a joke with "bucket" in brazilian portuguese, but its not the first time I see someone relating it with bald people ;)

znpy 10y ago

Unless you're going to reference your blog-posts in the documentation and you're willing to keep such documentation updated, I'd strongly recommend you to focus on improving the documentation instead of writing long walls of text on the internals. If I imagine myself using your framework, well, I would be very angry at you if I had to stop writing code, leave my editor and go read your shilly-shally. I would focus on: 1) Topics like "Application structure", "Application Deployment", "Application command-line interface" (which at the moment of writing are all just a "TODO"). 2) Sample code. A 30 lines example is worth a thousand word blog post 3) More sample code. Ideally, one for every crucial part (cookies? session? middlewares?) By the way: I see there are some examples, great! But add some more comments to your examples. 4) Blog post on internals. I'd delay the blog post upon internals because I guess that since you'll be receiving a lot of feedback you might want to change things in the internals thus "invalidating" your blog posts. P.s: congratulations on using doxygen so well! I wish more project had such a well done documentation! p.p.s: I hope you won't find my comment rude or anything, I actually like this project.

rafaelmartins 10y ago
hey, thanks for the comment, it is far away from being rude :) blog posts were never the focus, they are mostly for myself, to remember how things work, as I don't work on the framework for some time, and need to have it fresh in mind to write proper docs. it may also help other people willing to help writing docs. also, whoever published balde website here in HN found it due to these blog posts, then they were worth already. :) and to be honest, I'd not publish the framework here in hacker news right now, I'd wait for documentation to be ready, but someone else couldn't wait, so... but you're right. the focus now is writing documentation. thanks
- ejanus 10y ago
  Great job! But Balde first appeared on HN about 2 years ago, https://news.ycombinator.com/item?id=7765301 https://news.ycombinator.com/item?id=7765301.
eka808 10y ago
There is something fantastic with the world of open source : you can enhance the bad parts of a project with your own skills to make it awesome. Basically, if you like the framework and there is no doc, Make a pain to yourself and contribute. p.p.s: I hope you won't find my comment rude or anything

cleeus 10y ago

Using SCGI as the sole backend protocol is a bad idea. I have implemented a C++ SCGI stack myself. The problem with SCGI that I found (of course very late in the game) is that it requires a TCP connection on localhost for every request on the HTTP frontend. This will leave you with a TCP socket in TIME_WAIT state for every logical request. While it is very simple to implement, it's missing pipelining an keep-alive. I think it's a better idea to implement a very minimalistic HTTP backend that can do pipelining and keep-alive with the upstream HTTP server. You don't need to support the full HTTP protocol, just enough to function with nginx/lighttpd/Apache.

rafaelmartins 10y ago
thanks for sharing your experience. I appreciate it
bontoJR 10y ago
Totally agree with that, I have implemented it as learning project FastCGI and SCGI in Swift few months ago and SCGI seems really weak for a real world project right now, even an easier one. I would also give an extra +1 in recommending to consider interfacing with nginx/lighttpd/Apache.