Live data from Hacker News

Sinatra::Synchrony - Evented, fast, concurrent Ruby web apps with no callbacks

kyledrake.net

21–30 of 32 posts

Re: Sinatra::Synchrony - Evented, fast, concurrent Ruby web apps with no callbacks

#21
post #16

Earlier quoted context omitted.

The beautiful thing about Sinatra is that it is ridiculously easy to pick up and go. With even a small amount of Ruby knowledge you're up and running in no time.

Good to know - I'll be starting from scratch. Any useful Sinatra resources I should use, aside from the canonical Sinatra book?

I like to start with a simple codebase: https://github.com/icco/basic

Re: Sinatra::Synchrony - Evented, fast, concurrent Ruby web apps with no callbacks

#22
post #3

this will save heroku users serious money.

If you're running on Heroku you probably don't care about saving money...

I don't understand what you're referring to here. If anything I'd think Heroku customers are the most price-sensitive, and usually start with a free plan.

Re: Sinatra::Synchrony - Evented, fast, concurrent Ruby web apps with no callbacks

#23
post #22

Earlier quoted context omitted.

If you're running on Heroku you probably don't care about saving money...

I don't understand what you're referring to here. If anything I'd think Heroku customers are the most price-sensitive, and usually start with a free plan.

Are you kidding? Heroku is incredibly expensive once you move off the free plan (although I'm sure there's some people who will say that they're happy to pay extra so they don't have to learn how servers work)

Re: Sinatra::Synchrony - Evented, fast, concurrent Ruby web apps with no callbacks

#24
post #16

Earlier quoted context omitted.

The beautiful thing about Sinatra is that it is ridiculously easy to pick up and go. With even a small amount of Ruby knowledge you're up and running in no time.

Good to know - I'll be starting from scratch. Any useful Sinatra resources I should use, aside from the canonical Sinatra book?

One of the things I love about Sinatra is that pretty much everything you need to know is in the README. Otherwise, understanding how Rack/your web server/your gems work is useful. From another angle, Paul Dix's Service-Oriented Design with Ruby and Rails has a lot of examples of using Sinatra in a variety of applications.

Re: Sinatra::Synchrony - Evented, fast, concurrent Ruby web apps with no callbacks

#25

performance benchmark using the same ab tests for node http://tjholowaychuk.com/post/543953703/express-vs-sinatra-b...

Those benchmarks are not leveraging the concurrency that Sinatra::Synchrony brings to Sinatra. All this benchmark shows is that a concurrent application can serve out more requests than a non-concurrent application when tested concurrently.

What rgbrgb said before you posted: you can roughly compare Express and Sinatra::Synchrony by reading the two webpages.

Re: Sinatra::Synchrony - Evented, fast, concurrent Ruby web apps with no callbacks

#26
post #22

Earlier quoted context omitted.

I don't understand what you're referring to here. If anything I'd think Heroku customers are the most price-sensitive, and usually start with a free plan.

Are you kidding? Heroku is incredibly expensive once you move off the free plan (although I'm sure there's some people who will say that they're happy to pay extra so they don't have to learn how servers work)

That's a pretty condenscending attitude. For very rapid deployments, small shops, and many other use cases deploying on Heroku would be much cheaper than paying for personnel, hardware, leasing, and myriad other costs associated with running your own servers.

Re: Sinatra::Synchrony - Evented, fast, concurrent Ruby web apps with no callbacks

#27

Earlier quoted context omitted.

Are you kidding? Heroku is incredibly expensive once you move off the free plan (although I'm sure there's some people who will say that they're happy to pay extra so they don't have to learn how servers work)

That's a pretty condenscending attitude. For very rapid deployments, small shops, and many other use cases deploying on Heroku would be much cheaper than paying for personnel, hardware, leasing, and myriad other costs associated with running your own servers.

There is a good middle ground between Heroku and setting up your own hardware: VPS hosting like Linode.

Re: Sinatra::Synchrony - Evented, fast, concurrent Ruby web apps with no callbacks

#28
post #27

Earlier quoted context omitted.

That's a pretty condenscending attitude. For very rapid deployments, small shops, and many other use cases deploying on Heroku would be much cheaper than paying for personnel, hardware, leasing, and myriad other costs associated with running your own servers.

There is a good middle ground between Heroku and setting up your own hardware: VPS hosting like Linode.

Heroku has very much to offer for shops that don't have much of an ops team. They solve a couple of problems quite nicely:

- Deployment (git push) - Backups - Database maintenance - Database Backups - Lots and lots of addons that are simple to install and provide consolidated billing. - No server-maintenance at all.

Especially the last point is something that gets underestimated a lot IMHO. Having a linode VPS implies that you have to take care of that box, which is a major pain if you're not an ops guy. It's simple for people that do ops, but sooner or later I always find myself tangled up in some special sort of (Linux/BSD/...) problem that takes me hours to solve, hours I could spend much more efficiently in building a new feature. Having a single VPS won't cut it if you're trying to have a load-balanced setup that scales out when needed. You need at least two. And maybe a database. And then, the moment your app takes off, you'll need to provision servers faster than you can manually, so you need scripting. Go learn puppet. More time gone.

So while it is expensive, there's a lot of teams that benefit tremendously from using an expensive service that solves that whole sort of problems. And it's not that expensive either. If your app is somewhat conservative in what it does, you probably can get 5-10req/sec on a single worker.

Post reply on HN