6 ms·

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

by beat 8y 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.

kgilpin 8y 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 8y 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.
  - ryanbrunner 8y ago
    The Ruby world at least seems to have settled on relatively simple Redis backed queues, where you directly request the job to be executed rather than use a more generic message broker. For sure there are more complex scenarios, but if you're just getting started you'll be well served by just reading the docs for sidekiq.
  - matthewmacleod 8y ago
    Not a direct answer, but Rails now includes ActiveJob which abstracts over the various jobs are available and is nice and simple to set up.
  - badosu 8y ago
    Unless you're building something with very specific requirements just use Sidekiq [0]. It's easy to install and performs very well. 0 - https://github.com/mperham/sidekiq https://github.com/mperham/sidekiq
sdegutis 8y 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 8y 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 8y 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'
- dreix 8y ago
  Why then don't you use the classic style without any initialization?
village-idiot 8y 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.
- LargeWu 8y 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.
  - village-idiot 8y ago
    I’m curious why you wouldn’t agree. Rails makes a ton of assumptions about how tables, models, controllers, and routes all line up together. Overriding that or removing part of it can get painful. I don’t think it’s a problem, nor do I think it’s specific to rails. All technologies work best for the cases they were designed for, that’s how design works. Rails was designed for CRUD apps, and it’s brilliant at that. The trick is knowning when you’re not making a CRUD app.
    - LargeWu 8y ago
      > Rails makes a ton of assumptions about how tables, models, controllers, and routes all line up together. Rails assumes some very basic, predictable, and consistent naming conventions by default. Beyond that, it has virtually no assumptions about what data feeds into a particular route or controller. For instance, if I have a controller named 'dashboard#index', at /dashboard, that controller doesn't care if I have a Dashboard model, or UserDashboard, or if I have a 'dashboards' table in my db, or a collection of 50 other random models that all combine to create a dashboard on the fly. If I have a 'people#update' route, it makes no assumptions that I have a Person or People model or db table. I can put whatever I want into that controller action with zero penalty. Generally speaking I am going to align my controller, model, and route names, but that's more for readability and maintainability concerns, not for the benefit of the framework.
whalesalad 8y 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 8y 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.
  - TomK32 8y ago
    "oranges" is a very narrow range of colours between 585 and 620 nm wavelength. I'm not surprised wikipedia has a page on that https://en.wikipedia.org/wiki/Shades_of_orange https://en.wikipedia.org/wiki/Shades_of_orange
- te_chris 8y ago
  No, that's Rack.
- beat 8y ago
  Sinatra is the DSL/object model. Rack is the http request mapper.
ken 8y 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".
- beat 8y 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?"
TomK32 8y ago
Let's not forget merb which Rails got merged into (or the other way round).

by beat 8y ago

kgilpin 8y 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 8y 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.
- ryanbrunner 8y ago
  The Ruby world at least seems to have settled on relatively simple Redis backed queues, where you directly request the job to be executed rather than use a more generic message broker. For sure there are more complex scenarios, but if you're just getting started you'll be well served by just reading the docs for sidekiq.
- matthewmacleod 8y ago
  Not a direct answer, but Rails now includes ActiveJob which abstracts over the various jobs are available and is nice and simple to set up.
- badosu 8y ago
  Unless you're building something with very specific requirements just use Sidekiq [0]. It's easy to install and performs very well. 0 - https://github.com/mperham/sidekiq https://github.com/mperham/sidekiq

sdegutis 8y 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 8y 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 8y 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'

dreix 8y ago
Why then don't you use the classic style without any initialization?

village-idiot 8y 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.

LargeWu 8y 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.
- village-idiot 8y ago
  I’m curious why you wouldn’t agree. Rails makes a ton of assumptions about how tables, models, controllers, and routes all line up together. Overriding that or removing part of it can get painful. I don’t think it’s a problem, nor do I think it’s specific to rails. All technologies work best for the cases they were designed for, that’s how design works. Rails was designed for CRUD apps, and it’s brilliant at that. The trick is knowning when you’re not making a CRUD app.
  - LargeWu 8y ago
    > Rails makes a ton of assumptions about how tables, models, controllers, and routes all line up together. Rails assumes some very basic, predictable, and consistent naming conventions by default. Beyond that, it has virtually no assumptions about what data feeds into a particular route or controller. For instance, if I have a controller named 'dashboard#index', at /dashboard, that controller doesn't care if I have a Dashboard model, or UserDashboard, or if I have a 'dashboards' table in my db, or a collection of 50 other random models that all combine to create a dashboard on the fly. If I have a 'people#update' route, it makes no assumptions that I have a Person or People model or db table. I can put whatever I want into that controller action with zero penalty. Generally speaking I am going to align my controller, model, and route names, but that's more for readability and maintainability concerns, not for the benefit of the framework.

whalesalad 8y 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 8y 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.
- TomK32 8y ago
  "oranges" is a very narrow range of colours between 585 and 620 nm wavelength. I'm not surprised wikipedia has a page on that https://en.wikipedia.org/wiki/Shades_of_orange https://en.wikipedia.org/wiki/Shades_of_orange
te_chris 8y ago
No, that's Rack.
beat 8y ago
Sinatra is the DSL/object model. Rack is the http request mapper.

ken 8y 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".

beat 8y 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?"

TomK32 8y ago

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