7 ms·

Anecdotal random story bits from my current company on why you should stick to Rails: - All of our "lightweight Sinatra(and similar) API" services eventually s

Anecdotal random story bits from my current company on why you should stick to Rails: - All of our "lightweight Sinatra(and similar) API" services eventually start to look more and more like Rails apps. Rails does many small developer convenience things well. Which you do not notice until you build this lightweight API yourself. E.g. console, logging, migrations, database connection pooling, rspec integration, i18n. - No one likes to work with your arbitrary personal project structure conventions. Where's the code? 'lib'? 'core'? 'app'? 'api'? Also, no one wants to learn your lightweight "data mapper" pattern written from scratch because you thought ActiveRecord is too bloated and "does not scale". That being said, there's quite a few things you can arbitrarily pick in Rails projects as well which others will find surprising. But the spectrum of those choices is little narrower. - Developers most of the time assume database connection pooling just magically happens. Sysadmins do have no desire to debug your apps. After couple weeks of back and forth you may realise that Rails does database connection pooling for you. And simply requiring 'activerecord' and establishing connection in your Sinatra app does not. - One day someone doing production maintenance wanted to remind themselves rake task name. And ran 'bundle exec rake' forgetting to add '-T'. Default task was rspec. It dropped production database. That day many learned that Rails has safeguards against things like this, while none of those "lightweight arbitrary structured APIs" had any. Though the lesson was clearly not very good, since we did this again couple years later.

rgoulter 6y ago
> It dropped production database. That day many learned that Rails has safeguards against things like this, while none of those "lightweight arbitrary structured APIs" had any. While having a depth of defense is a good idea (and so "+1 to rspec for its default rake command not performing destructive operations" is ok), I'd suggest the bigger takeaway should've been about permissions surrounding the production database. -- You can't accidentally do something you don't have permission to do, or can't do easily.
- yebyen 6y ago
  This is a great point, so how do you handle this? Rails doesn't have any separate facility for migration account vs production account, by default. Which because our deployment paradigm also doesn't have any such separation, resulted in an awkward conversation with our DBAs where we explained that our production login requires the DDL permissions they thought should be reserved for an admin user. I think they're right, but there's only one place for setting the value of DATABASE_USER in each environment. So do you handle migrations by hand, out of band with a different user than production uses? (How should a regular Heroku user handle this issue, I guess is where I'm looking for a straightforward answer to this common issue that I think you're absolutely right about...)
  - rgoulter 6y ago
    The problem came from fat-fingering a command for DB maintenance while running as an admin. This then ran scripts intended for a development environment. (Development environments don't need to be careful about destroying stuff). I suggest ideally all the maintenance tasks can be done automatically, without needing the command to be run manually. Such scripts can then run in staging before in prod; or if the scripts necessarily only apply to prod, they should be reviewed carefully. If prod admin must be done manually, then make you could make it harder to run the development scripts with such admin privileges.
    - yebyen 6y ago
      But there is a release phase in Heroku, and reasonably that's the only time you should expect to need DDL permissions... The principle of least required privilege seems to suggest that the production web server shouldn't have permission to perform DDL when it doesn't need it (so that fat-finger would have likely never happened, or never caused a problem, so long as it was only running in the context of the prod web service.) It's just a little bit surprising that there don't seem to be any concrete solutions for this, I find it hard to believe I'm the first to whine about this issue related to commonly understood DBA best-practices. I don't know how you solve it, (maybe add a production_migrations environment?)
  - vinceguidry 6y ago
elcapitan 6y ago
> Where's the code Honestly for anything of real-world size, that question is not well answered by rails either. Developers tend to stuff everything into either models or controllers until they learn about "service classes" and then they put all logic into service classes, with the same issues.
- lkrubner 6y ago
  This is a very good comment. Every complex Rails app I've worked on, we end up having the same debates: "Our models are too fat, let's refactor." "Where should the code go?" "Let's put them in a utility class." "No, a utility class is a code smell from the point of view of true Object Oriented theory." "Then let's put them in a service class." "No, a service class is just a utility class with a different name." "Then where should the code go?" A long debate ensues, and then we end up with some crazy solution that includes everything that jeff_vader just suggested as a problematic: " Where's the code? 'lib'? 'core'? 'app'? 'api'?"
  - malyk 6y ago
    We use the interactor gem with great success for this.
  - mhoad 6y ago
    I think one of the things I have started to realize is how rarely people in Rails-land tend to reach for more established patterns that are generally thought to be important to writing good object oriented code. There seems to be a real adversity among many to go ahead and create new classes as needed especially when that new class isn't obviously a model, view or a controller. I just went over a short YouTube series DHH (creator of Rails) did where he walked through the production code behind Basecamp and I was struck by how different it looked to almost any other Rails app I recalled looking at previously. But it seemed like there was not a whole lot that they were doing that would seem in any way out of place from a SOLID OO perspective. It's a very interesting set of videos to take a look at what a modern Rails app with a decent amount of complexity looks like as intended by the team who wrote the framework. You can find it here if you're interested https://www.youtube.com/playlist?list=PL3m89j0mV0pdNAg6x9oq6S8Qz_4C-yuwj https://www.youtube.com/playlist?list=PL3m89j0mV0pdNAg6x9oq6...
vbsteven 6y ago
This. There are so many things that are required in a modern web app that these "batteries included" frameworks provide for you that it just makes sense to use these for most standard projects. I personally use Spring Boot as my default stack because just setting up a basic boot starter project gets me: * Routing * Server side templates * i18n translation files * database connection pooling * database migrations * ORM * Logging * Json serialization * unit testing, integration testing, mocks * CSRF * Validation framework * Dependency injection * SMTP email sending and much more, all compatible with each other If I would start with a blank Sinatra/Express project I would have to piece together all of these myself from various libraries and my own code.
- bzb3 6y ago
  But those frameworks force you to do things the way they want you to. As soon as you need to deviate a little bit, and very often you'll have to, you'll have to rewrite the entire thing.
  - vbsteven 6y ago
    That's why they are called frameworks, they solve standard problems in a specific way and the good frameworks provide extension points so you can customize when you need to deviate a little bit. Can you give a specific example of when this poses a problem?
  - rco8786 6y ago
    This is not my experience. When you have to deviate, which has been quite rare for me, it’s all just ruby at the end of the day so you can do whatever the heck you want.
  - nthj 6y ago
    Every time I’ve seen an engineering organization run with rewriting the whole thing, they/we figured out 6 months later a more effective data model. That’s usually the root problem. Rails can do many things but no framework can design a product’s data model, and when you have an excellent one Rails will sing. Also sometimes you need some separate services for GPU/security/reasons. That’s fine.
wirrbel 6y ago
more of a Python person here, but in the python world its really similar. People feel like their service is too small / not a good fit for django and build Flask services. I like Flask, its really nice. But no 2 Flask services do look remotely similar, after 4-5 weeks the services have pulled in so many plugions that they might have just used Django or similar larger frameworks. Sometimes people don't like to use Django because they write fairly stateless services not involving a database, its understandable but that aspect "doesn't eat much hay" tbh. As a middle ground I often recommend https://trypyramid.com/ https://trypyramid.com/ which has more structure, a better plugin-integration infrastructure than flask but isn't so much bound to a SQL ORM (while you still can use sqlalchemy just fine).
- coffeemaniac 6y ago
  If you don't need a database at all I kinda understand not wanting to "sandblast a soupcracker" as the saying goes.. but I've definitely seen a very similar trend with Flask apps! To be frank django has been my go-to for almost every app I've built or prototyped which required a db, sometimes if exposing a REST API is more of the main goal I'll use DRF and then build a minimal frontend SPA using React (served by a separate app within the project). Not sure why it's not taught/used more tbh.
neya 6y ago
Spot on. Very well said.
eggsnbacon1 6y ago
to me, this sounds more like "Ruby tools don't have sane defaults unless you use Rails" Some examples from crufty Java world. You magically get connection pooling with any JPA provider. If you import a logging library, it magically works. Flyway and Liquibase db migration tools have built-in failsafes, and "just work" with defaults. I think Ruby suffers immeasurably from most things being built for Rails. In Java and Python, there's so many options that everything is forced to be modular when running standalone and play nice with various frameworks. Ruby is loved for Rails, but Rails is slowly killing the langauge by making it hard to do anything without it. For most purposes, Ruby is Rails. To me this is a good reason to use a different language where I have flexible options
- joelbluminator 6y ago
  But most Ruby devs don't want flexible, they want Rails. And this article makes a good case for why that's a good thing. It's also happening in php world where it seems 90% of projects now go with Laravel.
  - eggsnbacon1 6y ago
    IMO its happening to languages that are no longer popular enough to maintain multiple frameworks. The difference with Ruby is that it was always mostly rails. I'm worried Ruby will descend into a Rails death spiral. Depending so heavily on one framework stops innovation
    - doteka 6y ago
      I think you’re right to worry, I wouldn’t be able to think of any reason to use Ruby instead of something else if Rails is off the table (in terms of ecosystem, not talking about personal preference here). Which is a shame because I like it the most of all the scripting languages, but Rails just sucks all the air out of Ruby.
      - halostatue 6y ago
        I recently used Ruby, Roda, and soap4r for a JSON-to-SOAP gateway project. We didn’t need all of the ceremony of Rails (no database), and needed more velocity than Java could give us, and none of the Elixir/Erlang SOAP libraries actually worked with the WSDLs (plural) we had. There’s a _lot_ of reasons to use Ruby if Rails is off the table.
beh9540 6y ago
I ran into a great "where's the code" on a "lightweight API" ruby project once. Opened up the codebase to fix an issue, and there were no .rb files at all. After opening every file in the repo, it turned out the developer of the code base had the entire service in the Rakefile.
gregors 6y ago
Regarding dropping the prod db. I remember when Github dropped their production database because they had prod in their test env setting. https://github.blog/2010-11-15-today-s-outage/ https://github.blog/2010-11-15-today-s-outage/
maxencecornet 6y ago
>All of our "lightweight Sinatra(and similar) API" services eventually start to look more and more like Rails apps Oh man, I've been working as a freelance/agency with a a team of 3 experts in nodejs for 5 years now - we've built API & products for many many clients Our nodejs/express "lightweight" framework is looking exactly like a rails app now (migrations, controllers and models generator, some scaffolding generators)
robomc 6y ago
yeah the claim that Rails is somehow "too much" for an API-only application smuggles in a lot of assumptions about what you might be using instead (and how good your team is at designing their own patchwork of libraries and how desirable that is).

rgoulter 6y ago

> It dropped production database. That day many learned that Rails has safeguards against things like this, while none of those "lightweight arbitrary structured APIs" had any. While having a depth of defense is a good idea (and so "+1 to rspec for its default rake command not performing destructive operations" is ok), I'd suggest the bigger takeaway should've been about permissions surrounding the production database. -- You can't accidentally do something you don't have permission to do, or can't do easily.

yebyen 6y ago
This is a great point, so how do you handle this? Rails doesn't have any separate facility for migration account vs production account, by default. Which because our deployment paradigm also doesn't have any such separation, resulted in an awkward conversation with our DBAs where we explained that our production login requires the DDL permissions they thought should be reserved for an admin user. I think they're right, but there's only one place for setting the value of DATABASE_USER in each environment. So do you handle migrations by hand, out of band with a different user than production uses? (How should a regular Heroku user handle this issue, I guess is where I'm looking for a straightforward answer to this common issue that I think you're absolutely right about...)
- rgoulter 6y ago
  The problem came from fat-fingering a command for DB maintenance while running as an admin. This then ran scripts intended for a development environment. (Development environments don't need to be careful about destroying stuff). I suggest ideally all the maintenance tasks can be done automatically, without needing the command to be run manually. Such scripts can then run in staging before in prod; or if the scripts necessarily only apply to prod, they should be reviewed carefully. If prod admin must be done manually, then make you could make it harder to run the development scripts with such admin privileges.
  - yebyen 6y ago
    But there is a release phase in Heroku, and reasonably that's the only time you should expect to need DDL permissions... The principle of least required privilege seems to suggest that the production web server shouldn't have permission to perform DDL when it doesn't need it (so that fat-finger would have likely never happened, or never caused a problem, so long as it was only running in the context of the prod web service.) It's just a little bit surprising that there don't seem to be any concrete solutions for this, I find it hard to believe I'm the first to whine about this issue related to commonly understood DBA best-practices. I don't know how you solve it, (maybe add a production_migrations environment?)
- vinceguidry 6y ago

elcapitan 6y ago

> Where's the code Honestly for anything of real-world size, that question is not well answered by rails either. Developers tend to stuff everything into either models or controllers until they learn about "service classes" and then they put all logic into service classes, with the same issues.

lkrubner 6y ago
This is a very good comment. Every complex Rails app I've worked on, we end up having the same debates: "Our models are too fat, let's refactor." "Where should the code go?" "Let's put them in a utility class." "No, a utility class is a code smell from the point of view of true Object Oriented theory." "Then let's put them in a service class." "No, a service class is just a utility class with a different name." "Then where should the code go?" A long debate ensues, and then we end up with some crazy solution that includes everything that jeff_vader just suggested as a problematic: " Where's the code? 'lib'? 'core'? 'app'? 'api'?"
- malyk 6y ago
  We use the interactor gem with great success for this.
- mhoad 6y ago
  I think one of the things I have started to realize is how rarely people in Rails-land tend to reach for more established patterns that are generally thought to be important to writing good object oriented code. There seems to be a real adversity among many to go ahead and create new classes as needed especially when that new class isn't obviously a model, view or a controller. I just went over a short YouTube series DHH (creator of Rails) did where he walked through the production code behind Basecamp and I was struck by how different it looked to almost any other Rails app I recalled looking at previously. But it seemed like there was not a whole lot that they were doing that would seem in any way out of place from a SOLID OO perspective. It's a very interesting set of videos to take a look at what a modern Rails app with a decent amount of complexity looks like as intended by the team who wrote the framework. You can find it here if you're interested https://www.youtube.com/playlist?list=PL3m89j0mV0pdNAg6x9oq6S8Qz_4C-yuwj https://www.youtube.com/playlist?list=PL3m89j0mV0pdNAg6x9oq6...

vbsteven 6y ago

This. There are so many things that are required in a modern web app that these "batteries included" frameworks provide for you that it just makes sense to use these for most standard projects. I personally use Spring Boot as my default stack because just setting up a basic boot starter project gets me: * Routing * Server side templates * i18n translation files * database connection pooling * database migrations * ORM * Logging * Json serialization * unit testing, integration testing, mocks * CSRF * Validation framework * Dependency injection * SMTP email sending and much more, all compatible with each other If I would start with a blank Sinatra/Express project I would have to piece together all of these myself from various libraries and my own code.

bzb3 6y ago
But those frameworks force you to do things the way they want you to. As soon as you need to deviate a little bit, and very often you'll have to, you'll have to rewrite the entire thing.
- vbsteven 6y ago
  That's why they are called frameworks, they solve standard problems in a specific way and the good frameworks provide extension points so you can customize when you need to deviate a little bit. Can you give a specific example of when this poses a problem?
- rco8786 6y ago
  This is not my experience. When you have to deviate, which has been quite rare for me, it’s all just ruby at the end of the day so you can do whatever the heck you want.
- nthj 6y ago
  Every time I’ve seen an engineering organization run with rewriting the whole thing, they/we figured out 6 months later a more effective data model. That’s usually the root problem. Rails can do many things but no framework can design a product’s data model, and when you have an excellent one Rails will sing. Also sometimes you need some separate services for GPU/security/reasons. That’s fine.

wirrbel 6y ago

more of a Python person here, but in the python world its really similar. People feel like their service is too small / not a good fit for django and build Flask services. I like Flask, its really nice. But no 2 Flask services do look remotely similar, after 4-5 weeks the services have pulled in so many plugions that they might have just used Django or similar larger frameworks. Sometimes people don't like to use Django because they write fairly stateless services not involving a database, its understandable but that aspect "doesn't eat much hay" tbh. As a middle ground I often recommend https://trypyramid.com/ https://trypyramid.com/ which has more structure, a better plugin-integration infrastructure than flask but isn't so much bound to a SQL ORM (while you still can use sqlalchemy just fine).

coffeemaniac 6y ago
If you don't need a database at all I kinda understand not wanting to "sandblast a soupcracker" as the saying goes.. but I've definitely seen a very similar trend with Flask apps! To be frank django has been my go-to for almost every app I've built or prototyped which required a db, sometimes if exposing a REST API is more of the main goal I'll use DRF and then build a minimal frontend SPA using React (served by a separate app within the project). Not sure why it's not taught/used more tbh.

neya 6y ago

Spot on. Very well said.

eggsnbacon1 6y ago

to me, this sounds more like "Ruby tools don't have sane defaults unless you use Rails" Some examples from crufty Java world. You magically get connection pooling with any JPA provider. If you import a logging library, it magically works. Flyway and Liquibase db migration tools have built-in failsafes, and "just work" with defaults. I think Ruby suffers immeasurably from most things being built for Rails. In Java and Python, there's so many options that everything is forced to be modular when running standalone and play nice with various frameworks. Ruby is loved for Rails, but Rails is slowly killing the langauge by making it hard to do anything without it. For most purposes, Ruby is Rails. To me this is a good reason to use a different language where I have flexible options

joelbluminator 6y ago
But most Ruby devs don't want flexible, they want Rails. And this article makes a good case for why that's a good thing. It's also happening in php world where it seems 90% of projects now go with Laravel.
- eggsnbacon1 6y ago
  IMO its happening to languages that are no longer popular enough to maintain multiple frameworks. The difference with Ruby is that it was always mostly rails. I'm worried Ruby will descend into a Rails death spiral. Depending so heavily on one framework stops innovation
  - doteka 6y ago
    I think you’re right to worry, I wouldn’t be able to think of any reason to use Ruby instead of something else if Rails is off the table (in terms of ecosystem, not talking about personal preference here). Which is a shame because I like it the most of all the scripting languages, but Rails just sucks all the air out of Ruby.
    - halostatue 6y ago
      I recently used Ruby, Roda, and soap4r for a JSON-to-SOAP gateway project. We didn’t need all of the ceremony of Rails (no database), and needed more velocity than Java could give us, and none of the Elixir/Erlang SOAP libraries actually worked with the WSDLs (plural) we had. There’s a _lot_ of reasons to use Ruby if Rails is off the table.

beh9540 6y ago

I ran into a great "where's the code" on a "lightweight API" ruby project once. Opened up the codebase to fix an issue, and there were no .rb files at all. After opening every file in the repo, it turned out the developer of the code base had the entire service in the Rakefile.

gregors 6y ago

Regarding dropping the prod db. I remember when Github dropped their production database because they had prod in their test env setting. https://github.blog/2010-11-15-today-s-outage/ https://github.blog/2010-11-15-today-s-outage/

maxencecornet 6y ago

>All of our "lightweight Sinatra(and similar) API" services eventually start to look more and more like Rails apps Oh man, I've been working as a freelance/agency with a a team of 3 experts in nodejs for 5 years now - we've built API & products for many many clients Our nodejs/express "lightweight" framework is looking exactly like a rails app now (migrations, controllers and models generator, some scaffolding generators)

robomc 6y ago

yeah the claim that Rails is somehow "too much" for an API-only application smuggles in a lot of assumptions about what you might be using instead (and how good your team is at designing their own patchwork of libraries and how desirable that is).