Where Ruby/Sinatra falls short

https://www.pc-kombo.com/blog/68/Where%20Ruby/Sinatra%20falls%20short

by onli • 8 years ago

59 68 8 years ago

lucisferre• 8 years ago

If people are looking for a lightweight Ruby webserver, I'd highly recommend checking out Roda https://github.com/jeremyevans/roda

More related to the article, the author mentions that routing order is a problem with Sinatra. Is this not common to all route matchers?

What different behaviour would make sense? Obviously once a route is matched it should be executed, so is the issue here the way route ordering is done? What order would make more sense than ordering in the way the routes are defined?

zdragnar• 8 years ago

Some routers- I think hapi in node might be one- match in order of specificity, not definition.

Edit: here we go- https://hapijs.com/api#path-matching-order

33degrees• 8 years ago

The author is claiming that the order ends up NOT being the order they're defined, but without examples it's hard to tell if the problem is that or that the regular expressions being defined are not working as intended

bhaak• 8 years ago

"Now imagine not having a classical style Sinatra app, but a modular one."

I think the author ran into an issue where files were loaded differently in development mode than in production mode. Likely in development mode only the required files were loaded and the file with the more important routes wasn't. I wonder why that didn't show up in their tests.

But I also wonder if they aren't using Sinatra for too large projects. If you have routes defined over several files, it's likely to get problematic. Maybe they should be using a more complete web framework like Padrino or go all the way with Rails.

coderobe• 8 years ago

And besides: If Sinatra starts a server listening for incoming traffic, why does it still seem common to run a regular webserver like nginx in front of that server?

This is a common technique used for tls-termination and management of 'virtual hosts', among other things.

The mentioned "issues" don't seem to be Sinatra-specific, but rather about the authors shallow understanding of the topic as a whole

mey• 8 years ago

Apache httpd mod_proxy -> a smattering of docker containers

badosu3• 8 years ago

This is a common technique used for tls-termination and management of 'virtual hosts', among other things.

Yes, usually you're not hosting only one application in a server, it's very useful to have the abstraction of a layer on top of many apps.

Also, to serve static content.

adambyrtek• 8 years ago

One of these "other things" is buffering of slow HTTP requests. Application servers are usually not designed to deal with that and are meant to be run behind a proper load balancer/reverse proxy. This is usually very explicitly mentioned in their documentation, for example in https://bogomips.org/unicorn/PHILOSOPHY.html

jrochkind12• 8 years ago

puma does pretty good at buffering slow HTTP requests though.

I honestly _don't know_ why we usually put apache or nginx in front of our ruby 'web servers'. But I keep doing it anyway, cause 'everyone else' does, and I don't want to take the time to be sure I don't need to, it works.

However, I believe rails deployments to Heroku generally _don't_ put another web server in front. Which, per your point, slow clients is quite exactly why they explained the switch from unicorn to puma as a default web server. https://devcenter.heroku.com/changelog-items/594

It is true that in 2018 web dev has gotten complicated (in a variety of different axes), and if there's a framework/platform that will allow you to not know it is, I don't know what it is! It would probably be one that made a lot more choices for you though (like, say, ruby web server, so you don't need to think about 'oh, unicorn can't handle slow clients but puma can') -- which is the opposite of Sinatra's philosophy -- but then again Rails approach to try to do that has not resulted in something people find easy either. shrug.

beat5• 8 years ago

I find it really interesting that the Ruby language led to two such wildly different, yet equally valid approaches to web apps - Sinatra and Rails.

Sinatra is the most minimal web framework I've ever used. It's fantastic for doing quick mockups and small apps. Yes, you will hit limitations. Bicycles are not good dump trucks. And even before you hit hard limits, you're going to find yourself inventing a lot of structure/convention to keep it from devolving into pretty PHP.

Rails, on the other hand, is fantastically complete. It does everything for you. Convention over configuration is a brilliant concept, and the self-discovery nature of the ActiveRecord ORM is something that is totally natural in Ruby and quite awkward in other languages. For writing basic CRUD apps (which is much of the software world), it's really hard to beat the efficiency of Rails.

And when people whinge about performance... well, so what? Horizontal scaling, friends. Developer performance is much more important than software performance in most cases (especially since networks and databases form the bulk of your performance cost out in the real world). But efficient developers, that's magical.

kgilpin2• 8 years ago

In my experience with web applications at non-Googley scale, most performance problems are occurring in places like SQL queries, rather than the raw speed of the web application stack itself.

Another really common mistake is tasks being performed inside the web request that should instead be offloaded to background job processing. If something is going to take more than milliseconds, it should be a job. If you see a PR where someone is bumping up the HTTP timeout in order to keep their slow processing request from being timed out by the webserver, they are doing something inline that should actually be a job.

zerkten• 8 years ago

Are there any good books or other resources on building out a system to do background processing? It seems that it's a common task, but there are different approaches.

sdegutis• 8 years ago

This split between micro and macro frameworks wasn't done in Ruby because of some intrinsic properties of the language. The same split was copied in many other languages, from JavaScript to Java. I think the reason it started in Ruby is because that language drew a lot of pioneers who said "the way things are right now isn't good enough, let's try something completely different" which mindset led to Rails in the first place, largely as a response to the Java web ecosystem, and then to Sinatra as a response to Rails. It's because this mindset is a sort of (admirable) perfectionism, seeking the holy grail of computer programming, and it's good that there are many people like that. A large number of these Ruby devs inevitably moved on from Ruby in this continual search, some seeking statically typed languages like Haskell or OCaml but most popularly Go, and some seeking dynamically typed languages like Clojure and Elixir but often settling on Node.js.

masklinn• 8 years ago

This split between micro and macro frameworks wasn't done in Ruby because of some intrinsic properties of the language. The same split was copied in many other languages, from JavaScript to Java. I think the reason it started in Ruby

web.py predates Sinatra (the 2005 rewrite of Reddit was on web.py), Django is about as old as RoR, Zope dates back to the late 90s, TwistedWeb is quoted in the 2003 WSGI PEP (333).

Stating that Ruby started µfw and the split between micro- and macro-frameworks seems like an incomplete and severely blinkered reading of history.

kawsper• 8 years ago

I do lots of experiments in Sinatra and some of those use Sequel (when I need a database). I think Sinatra has some rough edges, and it surprised me how I needed to initialise a Sinatra app:

    module MyApp
      class Web < Sinatra::Base
        def initialize(app = nil, params = {})
          super(app)
          # setup stuff
        end
      end
    end

Also, I also find it sad that people never seem to know that they can use mount command in Rails where you can mount random rack-apps in your routes, even though most people probably do use it with some of their gems, here it is with Sidekiq:

    mount Sidekiq::Web => '/sidekiq'

dreix3• 8 years ago

Why then don't you use the classic style without any initialization?

village-idiot4• 8 years ago

In my opinion, Rails is only really great if you have a very tight correspondence between your routes, your models, their JSON, and the database tables. When you start separating those apart, that's when you start to suffer a lot with rails.

LargeWu3• 8 years ago

Curious why you think that, or why that problem is specific to Rails. I've worked on some massive rails apps, and never experienced that pain. Or, at least not any more pain than any other large app.

beat5• 8 years ago

Why don't you have a tight correspondence, though? Is it something intrinsic in the problem space, or you just want to do it the way you think of it?

In a number of cases, I've found that the Rails Way was smarter than my original assumptions.

whalesalad2• 8 years ago

Sinatra is not an "approach to web apps" -- it's a single purpose tool that maps HTTP requests to Ruby. Like Flask or Web.py (Python) and Express (JS).

You are comparing apples to oranges.

menacingly• 8 years ago

And you're saying oranges aren't fruit because they aren't like apples.

It's actually a not-insignificant amount of code that creates an approach so cleverly transparent that you are able to interpret it as no approach at all.

te_chris• 8 years ago

No, that's Rack.

beat5• 8 years ago

Sinatra is the DSL/object model. Rack is the http request mapper.

ken• 8 years ago

And when people whinge about performance... well, so what? Horizontal scaling, friends.

I hear this a lot, but in my experience, it's not a workable solution to this particular problem. 100% of the systems I've worked on in the conventional 'slow' languages (Ruby, Python, Elisp, declaration-less Common Lisp, etc) hit significant performance bottlenecks in typical single-thread use cases. These languages enable me to work quickly when making a prototype, but then I spend a long time optimizing it to run fast enough for a single user.

Don't get me wrong. The speed of development for these HLLs is great. It's much better to be able to move continuously from the first prototype to a production system. (I don't want to write a prototype in C, nor do I want to throw out a working HLL prototype and rewrite it all in C.) The benefit, though, is that I can get a prototype running quickly, and iterate quickly. It doesn't obviate all performance requirements just because there's an HTTP server involved.

Horizontal scaling is a great solution to "my web app suddenly got very popular, and it works great for 1000 occasional users but today I need the capacity to deal with 10,000 simultaneous users".

beat5• 8 years ago

It really depends on the problem space, though. And for most reasonable applications, Rails/Sinatra scale just fine through well-understood horizontal methods. By the time you're getting to where they don't scale well, you're probably longing desperately for a rewrite anyway, because your core problem has shifted from "Does this solve an actual business case?" to "How do I make this support a heavy load?"

TomK322• 8 years ago

Let's not forget merb which Rails got merged into (or the other way round).

badosu3• 8 years ago

With micro web frameworks you're doomed to implement a subset of Rails, or have to dig around to find and configure one of the gems usually associated to it.

For those that are ok with this, or already have an understanding of the limited scope of your app, I strongly recommend Roda [0], it's a much more straightforward routing system with better memory/cpu usage.

I can't find a single instance for which Sinatra can be used where Roda is not a better choice.

[0] http://github.com/jeremyevans/roda

eropple• 8 years ago

Agreed. Until I wrote Modern[0] - and that was in many ways more of an exercise in OpenAPI/Swagger than anything else - there were few reasons I could find to not use Roda over Sinatra.

Grape's also pretty good, but I prefer Roda over it too. Something about writing it feels better.

[0] https://github.com/modern-project/modern-ruby

kgilpin2• 8 years ago

Sinatra is a great way to build test programs and demos. Once scaling up to a real application I have found that Rails is a better choice because it has a lot of the things built in that feel missing from Sinatra.

For example if you are trying to figure out how to add things like flexible initialization logic, security protections, clever MIME type handling, Cucumber testing, and better routing, you’ll find that Rails has these things built in.

What you can’t get from Rails is the “one file application” that’s the killer feature of Sinatra. But all those files and directories in Rails are doing stuff that you’ll eventually want.

always_good• 8 years ago

And a small issue on top of that: If you define /route, /route/ will still throw a 404. The right solution would be to serve the page on the two routes but set one as canonical source. But you have to do that manually.

In most cases you can get away with wholesale removing and redirecting all trailing slashes in middleware.

astrodust• 8 years ago

Rack gets you out of a lot of jams if you know how to use it effectively.

tcopeland• 8 years ago

That's the truth. I had a thing come up the other day where a client wasn't including a content type header and thus the body was being interpreted as application/x-www-form-urlencoded. Rack middleware to the rescue on that one.

stevekemp• 8 years ago

To be honest I always just define:

   get '/foo/?' ...

That will handle both, although I appreciate I should probably stick a redirect in place to make one the canonical link.

jillesvangurp• 8 years ago

Part of the issues are with the separation of responsibilities between rack, sinatra, and whatever you use to run rack (e.g. puma is just one of many options here). We had similar issues a few years ago when we still used sinatra (on top of jruby).

One of the assumptions baked into rack is that parameters can only occur once. It returns a dictionary of values instead of a dictionary of lists of values (like e.g. the servlet API does in java). So we had some issues with request parameters that could occur more than once because of that. Ultimately we had to grab the raw request and do our own parsing to get that working. Likewise headers are treated the same way.

Another issue that was annoying was that rack, sinatra, AND the rack server we used (something on top of jetty that I forgot the name of) each had their own wonky logging primitives and configuration that interfered with each other. So we were getting duplicate log messages with very inconsistent formatting from different frameworks that each assumed to be in control of stdout. In the end some monkey patching (mainly to make rack log calls do nothing) allowed us to log via jruby/java via a proper logging framework on Java so that we could send properly formatted json messages to our logging cluster instead of dealing with unparsable garbage emitted via puts. We even managed to use the MDC, which is a good reason to use Java logging frameworks if you are running on top of jruby anyway. I don't think MDC is a thing in the ruby world.

Then there were loads of fun issues with cross site scripting protection in sinatra breaking stuff in subtle ways, double session initialization (i.e. two frameworks trying to set the session cookie), and a few more such issues.

I'm assuming some of these things may have improved over the years.

onli2• 8 years ago

So we had some issues with request parameters that could occur more than once because of that. Ultimately we had to grab the raw request and do our own parsing to get that working.

I had to do the same multiple times. Not for this project, but for different ones. Thanks for mentioning it. I should've mentioned it in the article!

mirceal• 8 years ago

For me Sinatra is great. It’s the minimum you can get away with in a lot of situations. The whole thing is like 1-2000 lines of code (so totally feasible to actually read all of the code). The limits the author has run into are not necessarily Sinatra limits. The author also wants to do 120mph on a bike which most people will recognize it’s a bad idea. Use the right tool for the job.

abhchand• 8 years ago

Someone on HN previously mentioned that every project they've started with Sinatra, they've regretted down the road that they didn't use Rails.

I think the complaints about Sinatra are vaild, in that it needs to limit how params are accessed, better startup documentation, etc... But ultimately Sinatra is for building super simple crud apps. I don't even use it for anything that accesses something more than a SQLlite DB. I often use it for serving up basic front end assets and running single page applications that have some small server side component to them.

It's footprint is lighter than rails, but so is it's intended functionality.

nine_k• 8 years ago

I suppose it's a selection bias. You likely heard about projects that achieved some significance, which requires some sophistication which Rails provides.

I suppose there's a number of very small, non-public projects that have, say, 10-20 users doing a relatively trivial thing, and are just fine on Sinatra (or web.py, or maybe even a plain CGI script). But they never catch much attention.

dreix3• 8 years ago

For years I have never looked back. If I had a project that outgrew its purpose I wrote it again, and dropped half of its functionality without looking back.

ravenstine• 8 years ago

The answer to points 5 - 8 is basically to use Rails/ActiveSupport. If you're writing an API for a SPA, then Sinatra hardly falls short.

whalesalad2• 8 years ago

This post would be more appropriately named "Where my knowledge of building web applications falls short" - the title is kinda inflammatory and a lot of the commenters here likely haven't bothered to read it and are just throwing in their two cents on the technologies mentioned in the title.

None of the complaints here are the fault of Ruby or Sinatra. One exception could be the trailing slashes complaint. The issue exists in really any web framework, though. Flask, for example, will give you the same hiccup.

I tend to defeat it in Flask with `app.url_map.strict_slashes = False`

There are too many ways to access parameters

This is a bad thing? The framework gives you flexibility to build your program the way you want, and the way your specific problems might require.

You will need much more than included

Well... yeah. This is not a batteries included tool for building websites end-to-end ... it's a simple way to map an HTTP request to Ruby.

Rewriting www.yourpage.com to yourpage.com, or the other way around
Serving your site over https
Redirecting all http:// pages to https://
Running tasks in the background
Saving data in a database, and reading from it

These are definitely not responsibilities for an HTTP -> Ruby library and the first 3 are certainly responsibilities for your public-facing HTTP server (Nginx, etc...)

skedaddle2• 8 years ago

It's supposed to be more than that. Sinatra is described as "a DSL for quickly creating web applications in Ruby with minimal effort".

Entire web applications, with minimal effort. I have not found this to be the case with Sinatra.

dreix3• 8 years ago

The application is not the server.

faitswulff• 8 years ago

These complaints aren't even consistent. The author complains about being given too many options for accessing parameters but also complains about not having enough options for templating, internationalization, various devops things, ORM...

Sinatra is a minimalist framework. It even describes itself as being a domain specific language, not a framework. IMO author should have just gone with Rails if they wanted an easily extendable, batteries-included framework with a massive community.

hartator• 8 years ago

Biggest thing is something else. Performance of Ruby/Sinatra plus gems needed to make it workable is worse than actual Rails. Might as well directy work with Rails. Better support and more features on top of better performance.

kposehn• 8 years ago

I've been a long-time user of Sinatra as well as Rails. About 8 years ago or so I decided to move all of my sites onto Sinatra and made a simple file-backed CMS that has scaled quite well over the years.

The drawbacks of the approach have been having to write a lot of methods and classes from scratch to handle certain processing data (there is no actual database) but the end result has been something quite bulletproof and scalable to a point, and the experience implementing those features (like TLS, sessions, helpers, etc) has been quite valuable.

However, my needs are starting to grow and I think soon we will have to move off of the old framework onto something new as our business requirements grow more complex.

jdlyga• 8 years ago

Ruby/Sinatra is really nice. I wrote a little webapp 10 years ago using it. Faced with the alternative of doing everything in C++, it really made things easier.

esilverberg2• 8 years ago

My company runs its entire backend on Sinatra, and has since 2011. We do ~200K requests/min on AWS c5.4xlarges and r5.2xlarges, so we are a fairly significant deployment of Sinatra/ruby.

As the sole and still primary maintainer of our production infrastructure, I've been very happy with this choice of tech. I think our problem was made much simpler because, as a mobile app, we basically were building an API. We did integrate ActiveRecord/Support, and today have a massive suite of tests we run in rspec (it's pretty cool, Jenkins will spin up ~50 concurrent EC2 instances running docker, run the tests, and report back in about 15 min).

To this authors complaints, I suppose I feel that every framework has idiosyncrasies that you just accept and figure out, and many of the issues cited are felt only once and then not again. Today, running at scale, the main challenges have to do with building and supporting new tests, which rspec is amazing for, and handling application complexity, which we have been addressing using Service Objects.

jimbokun• 8 years ago

How does Elixir's Phoenix framework compare for the shortcomings of Sinatra noted here?

Give Elixir's commitment to immutability and functional programming, I'm thinking it might be more explicit in some of the places Sinatra has implicit or inconsistent behavior.

Where Ruby/Sinatra falls short

Related Stories