13 ms·
When Should You Not Use Rails?
- JoelMcCracken 6y agoCurious, what does the author mean here: When It’s ‘Just’ an API Server: Rails has less to offer an API server that speaks JSON over the wire. A lot of its HTTP security doesn’t matter for that case (e.g. SQL injection safeguards, XSS prevention.) It seems to me that SQL injection safeguards would still be needed in an API service. OFC XSS isn't relevant though. (I word it like this to be charitable in case I misunderstand what the author was trying to say, but if they are trying to say what I think they are, I think they are wrong.)
- adamors 6y agoHonestly, this article reads like blogspam.
- jholman 6y agoI have no idea what TFA meant, but if they meant what you assume they meant (and I tend to agree with you) then the whole premise is broken. I'm not aware of "preventing SQL injection" as any particular advantage of Rails (nor even of ActiveRecord). Obviously if you write sufficiently bad ActiveRecord method calls, you can trick it into doing SQL Injection. So it's not magic. (Indeed, I view that as a strength of AR; it has robust escape hatches. I hate ORMs, but I hate AR less than any other ORM.) And equally obviously, every credible database driver written in at least the last 15 years has robust support for prepared statements and tolerable documentation on how to use it that can be understood in literally a few minutes. Which, of course, is exactly how AR gets it right in the first place. (And I only have to say "in the last 15 years" because of the dumpster fire that was turn-of-the-century MySQL.)
- going_to_800 6y agoJust another critical article without substance to steer up rails community and get some readers. That API part in particular is dead wrong. Gives the feeling Rails is not good for anything.
- jakuboboza 6y agoThe scaling factor for each app is really the way it interact with slowest part of the API. If it is Database than no matter how optimal your Rust code is, you might fare in the end not that much better than Rails just because you hinged everything on eg. Postgres.
- spockz 6y agoThe assumption here is that you will spend more CPU cycles in your rails app to hit the ceiling of the DB than you will with a performing rust app. So even though you will have the same upper ceiling of scale, reaching it will require less compute and therefore money in your api layer. Whether the difference is significant enough to balance developer FTE depends on the org.
- throwaway189262 6y agoDb is slow anyways is the default excuse when using slow web backends. The one I'm currently working on is blazing fast and were truly hitting postgres limits... At nearly 50k requests a second. The DB is rarely a bottleneck if you have sane structure and indexes. Ironically the slowest frameworks also tend to generate terrible queries (ActiveRecord, SQLAlchemy), so you end up with a slow database and web framework
- dimgl 6y agoI agree with you. I don't think anyone can convince me to use these bloated frameworks on any project ever again in my life.
- bdcravens 6y agoYou should probably listen to the podcast referenced. The hot take that this is trollish or clickbait really isn't accurate.
- jakuboboza 6y agoWell if you need full package of migrations, html rendering etc... Rails is still a good choice. It is 2020 not 1996 we have choice now and picking up framework/solution based on our needs is standard. Ruby/Rails and Elixir/Phoenix has one big thing, REPL. No matter what you choose. C++, Go, Rust, Node etc... getting solid easy to use REPL is effort and not built in feature. in Rails/Phoenix you get it for free. That is a great perk!
- rubber_duck 6y agoHow is REPL not a built-in feature of node ? Adding a REPL to any interpreted dynamic language should be trivial.
- p_l 6y agoSemantics of execution can vary wildly. Node is somewhat usable except for the "REPL is not async context" which leads to annoying tricks, but for example Python is very non interactive due to code reload behaviour
- pletnes 6y agoPip install ipython and enable autoreload. Problem solved!
- p_l 6y agoTried that, didn't work. Maybe I'm just too used to Lisps (and Ruby, which also handled it better)
- rubber_duck 6y ago>Node is somewhat usable except for the "REPL is not async context" which leads to annoying tricks What do you mean by this ? It's been a while since I was able to use await in REPL, maybe you are referring to something else ?
- 6y ago
- vvillena 6y agoThe article points out a nice pivotal moment where Rails stops being as useful: when the server costs are higher than the engineering costs. I'd add that this shouldn't be a comparison based on a prediction, but on an actual monthly report. Until then, I find Rails to be a perfect tool that enables devs and companies to keep working on what matters.
- AlchemistCamp 6y agoI totally agree with the thrust of this. There is one other concern, though. I actually just submitted my own blog post on how infra costs can break a business. https://questinglog.com/costs-are-part-of-scalability/ https://questinglog.com/costs-are-part-of-scalability/ If your business model brings in $X per unit of usage your hosting costs need to be < $X per unit of usage or else no amount of engineering will make your business profitable. One of the founders of Twitch recently tweeted about how using Amazon's new service for Twitch-like video streaming simply wouldn't be feasible for building your own Twitch.
- nurettin 6y ago> I’d still start out in Rails, personally. If you’re building something quickly to see if anybody cares, I know of no framework that comes close to its productivity. I've used RoR for 5 years, spring boot/kotlin for 2 years and Django for a year. Once you've set up the workflow, there isn't much difference in terms of productivity. The pain point is setting up the base project and keeping it updated as library versions change. What django and spring boot are missing are the commandline generators for entities, controllers and views and a quick setup. Django and spring boot need a little bit of careful setup. Django needs its settings, applications array, middleware declarations, etc. Once you get over this and start adding your entities, views and routes it goes fine. Spring boot requires a rigid folder structure, application property files, a careful setup for migrations and logging. Liquibase setup, etc. It doesn't get off the ground easily. Once you start writing your entities, repositories, controllers, services, views it goes smoothly thanks to lazy initializers.
- ageitgey 6y agoIf you are building something new with Django where Rails' generators would have been helpful, check out https://djangobuilder.io/ https://djangobuilder.io/ - it lets you quickly list out the data model and then it generates the whole code skeleton for the site. It's not a perfect replacement, but it can save time if you are starting a new project with a lot of boilerplate code.
- evnix 6y agospringboot? it cannot get easier than this: https://start.spring.io/ https://start.spring.io/ I personally choose Java/SpringBoot, it has a steep learning curve, but has strong typing, runs as fast as most C++ code out there, plus you can do async. and if you want something fast but that is as easy as Rails and runs on Java/Groovy/JVM, use Grails.
- _AzMoo 6y agoGreat news. Django 3.1 was released today which includes support for async views. The ORM is still not async, but it's a big step.
- 6y ago
- renewiltord 6y agoFunny, I never bothered to not use Rails because I can go from zero to everything running on Heroku in 15 mins now with SSL on a domain and all the shit. Being incredibly lazy I do this even for non-DB stubs, using the free Heroku Postgres add-on. So I don't even know if it's possible to run Rails without a DB. I did try `nulldb` last time but migrations broke, which is odd. Honestly, even if doing JSON API -> React frontend, I'd still do it. It's too easy to get it right with Rails.
- davedx 6y agoYep, I built a salary calculation app with Rails and React, using it as an API and it still saved me tons of time, and the business logic was well suited to Ruby with some nice unit tests
- yakshaving_jgt 6y ago> Ruby isn’t designed for a team of 200 programmers where you don’t trust some of them. Never mind a team of 200, even on a team of one person I don't trust myself! That's why I'm using typed FP. I don't trust myself not to make clumsy errors. I don't trust myself to be disciplined and write all the tests. I don't trust myself to not design a naïve architecture which I'll have to do a huge — and dangerous — refactoring on later. This is why I'm not using Ruby/Rails any longer.
- aliante 6y ago“I can’t be bothered to do anything properly. It must be a problem with Rails.”
- AndrewDucker 6y ago"I recognize that no human is fallible, so I use tools that don't assume infallibility"
- tluyben2 6y agoI think that's really the answer. We all mess up and using tools that make it easy to mess up is a problem... It will happen and it can happen in very bizarre ways.
- spanhandler 6y agoSafety aside, I find going back to “guess the source of the meta magical pattern-named method” intolerable these days. Onboarding to, taking over, or pinch-hitting in a Rails codebase is miserable unless it’s tiny and perfectly maintained by developers with excellent judgement and taste—and of course this is almost never the case.
- yakshaving_jgt 6y agoWhat does "properly" mean in this context? All of my income is from my own software businesses. I used to try to do this with Ruby, and there were lots of problems. Now I do it with Haskell, and there are fewer problems. This ended up being a very good business decision for me. What is the return on investment for me as a businessman on bothering to "do anything properly" when the resulting product is both cheaper to write and is more stable if I just use a better tool? What do I actually gain? Some kind of nerd-honour?
- tluyben2 6y agoIs Rails still (I have not used it since 2016) incredibly hard to migrate after a couple of years? I have java/spring, asp.net (core) and php (no framework) in production and I can upgrade after a decade not touching and everything still works. I had Rails upgrades after 1-2 years that were absolute nightmares. I'm not sure about other people here but I really don't want to suffer through that 'for fun' while I don't have to. Speed of developing is not so much faster that I would take this for granted. But maybe things changed. Edit; it was a question, what's with the downvotes? It used to be bad; I'm not the only one saying that. It's normal (Laravel, Node etc have it as well; it's fast moving).
- Ecco 6y agoI don’t get why you’re being downvoted. You’re right, a while ago that was a major headache. The good news is that it’s now much better! - Bundler makes keeping track of gems trivial - Rails defaults are explicitly version-bound. E.g. you can update to Rails 6 and keep using Rails 5 defaults. - There are now extensive official guides on how to update.
- tluyben2 6y agoGood to hear, thanks! Maybe i'll try it again as it was quite nice outside updating/upgrading.
- bdcravens 6y agoThe upgrades prior to 2016 were definitely painful, especially 3.2 -> 4.0. In recent years, there's been less changing the underlying framework; new versions tend to just add new features.
- donmb 6y agoI agree with the article. For instance, I was using Rails a lot in the past when I was bootstrapping small shitty projects to get a "taste of the user" and validating my ideas. For more complex projects I am using Ruby business oriented frameworks (trailblazer is a great choice here!) but I flavour it up with some ActiveRecord and ActionMailer as its very convenient. In general, the whole Rails framework became too much for my projects and to blown up.
- jeff_vader 6y agoAnecdotal 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 agoThis 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...)
- jholman 6y agoI think this is a pretty reasonable and balanced article, actually, and I think it straight-up admits what many instructors lie about: If you already can write a Hello World back-end in some other language/framework, and you're now learning Rails just so you can do Rails+React, that's a dumb waste of time. (I'd say the same thing about most frameworks for most purposes, but it's especially true with Rails. But doing Rails+React when you're already fast and competent with Rails, that's a very sensible choice in most situations.)
- lukecameron 6y agoHas anyone heard of good resources that teach you "when to use X" instead of "why you should use X"? It's somewhat understandable that the official websites of frameworks/tools/libraries/languages/services tend towards espousing the advantages of the thing and leaving out most of the drawbacks. That's just how the incentives are aligned. But even the average blog article about a tool posted on HN rarely talks about what situations it is most effective, and what situations it should potentially be avoided. I suppose it's a natural consequence of blog authors only knowing so many tools, no single person knows them all. I'm not saying this information isn't out there – just that it seems like the exception rather than the rule.
- nickjj 6y ago> Has anyone heard of good resources that teach you "when to use X" instead of "why you should use X"? One of the goals of a podcast I started last year was to answer that type of question and more. It's mainly a podcast where I talk to someone new every week to get a better understanding of why they chose a specific tech stack to build their app but it also goes into the "how" since we talk about how they build and deploy their app, lessons learned along the way, etc.. A list of episodes can be found here: https://runninginproduction.com/podcast/ https://runninginproduction.com/podcast/ Each episode has a "Motivation for using ..." time stamp so you can jump to that part of the discussion. It's usually within the first 5 or 10 minutes. The goal here is to have a bunch of real world examples of why and when someone used X and they usually spend a few minutes talking about why they chose that instead of something else too. There's episodes ranging from solo developers working on a side project to high traffic services handling billions of requests per month. The idea is to have loads of practical examples instead of trying to theory craft hypothetical scenarios.
- lukecameron 6y agoThanks for that! Coincidentally I’ve had that podcast on my list for a while, guess it’s time to give it a listen.
- nickjj 6y ago
- lovetocode 6y agoI love Rails and it has done a lot for my career. However, after 6 years of Rails development I find myself far more likely to be reaching for ‘dotnet new’ rather than ‘rails new’.
- karmakaze 6y agoWhat language/framework does that use? I played with F# and liked it enough but didn't use much of a framework (Giraffe). Biggest hurdle was there wasn't a good up-to-date setup guide I could find for macOS.
- cutler 6y agoASP.Net Core 3.1 is perfectly usable on OS X and by the end of the year .Net 5 promises to be truly cross-platform.
- pmarreck 6y agoAnswer: When Elixir/Phoenix exists
- AlchemistCamp 6y agoThat's sure the answer I arrived at.
- pmarreck 6y agoDid Rails for at least a decade, but won’t go back after doing elixir/phoenix for a couple years now
- jonnycat 6y agoI've used Rails for various products for 10+ years (and plenty of other tools for comparison) and really appreciate it for the productivity, conventions, philosophy, etc. But after spending most of this year with Elixir/Phoenix, I don't think I'll ever go back. In my opinion, Phoenix competes well with most of the strong points of Rails, and avoids many of the downsides - including the ones discussed in this article. It's also built on a more performant and robust foundation (Erlang/OTP). You may not truly "need" some of those advanced foundation features at first, but at just the same point where a Rails project starts to struggle, Phoenix really shines. Phoenix is not the solution for every app, but for every app where I would have used Rails in the past, it's looking like Phoenix from now on.
- spion 6y agoPersonally once I started working with TypeScript, I don't want to go back to an untyped dynamic language. Its just too painful, even for personal projects, and tests don't fix the pain (at least not at the expense of not doing test-induced design damage which is also painful)
- slowmovintarget 6y agoI can't imagine developing an application this way anymore. From the article: "Rails has less to offer an API server that speaks JSON over the wire." Everything we do works this way now (JSON over the wire). Everything is a RESTful API first. We build a UI that uses the API, but the business function is served completely from the API. Why? Because if the function is valuable, then some other program will likely want to exercise it programmatically. All of our capabilities are built to be composed programmatically by default. The additional effects this has on our organization is that we can often turn around new integrations in hours. They're all API calls. Other developers can kick the tires through fully secured Swagger UIs before a pretty application ties it together. And everything we build can be combined into multiple different UIs anywhere in our suite of applications. Every API is built with the assumption that it is out on the public internet, subject to all the security and scaling problems that entails. What it has driven us to do is get very good at standing up hardened, simple services that host a consistent API-style. We build UIs, but we assume the real value is in the functionality and the data, not in one specific form of its presentation.
- lostcolony 6y agoLess doesn't mean none. Rails (and frameworks like it) serve multiple purposes - One is serving server side rendered pages. One is providing non-functional requirements such as security (including browser based security, some of which is tied to the pages served, i.e., CSRF tokens). One is providing CRUD functionalities. The first one, and some of the conveniences of the second, you'd not benefit from. The last one, and some of the core functionalities of the second, you would. So, less to offer, but not 'nothing'.
- out_of_protocol 6y agoPhoenix as a Rails successor does fix most of these issues, in a right way.
- diehunde 6y agoYou can build "API only" apps with Rails using rails-api[1]. It removes all the bloating that comes with a typical html rails app. [1]https://guides.rubyonrails.org/api_app.html https://guides.rubyonrails.org/api_app.html
- effnorwood 6y agoWhen you’re not a train.
- silviogutierrez 6y agoYou can pretty much substitute "Django" for any case where Rails is not appropriate. That is, they go hand in hand and both have similar uses. But there are very few cases. Fewer I'd say than this article lists. Low level programming, and yes perhaps event-based systems. [1] I find people just like rewriting their own batteries and conventions. Fun, no doubt, and a good learning experience. I challenge any microframework / library user to surpass the productivity of a mature framework like Rails or Django. I argue nothing comes close. And I don't mean "for the 5 second MVP". Perhaps your app won't need some of the batteries, but your app will need logging. It will need database migrations. It will need forms and inputs. It will need media uploads. It will need to send email. And so on. Future proofing too much is an issue in the industry. YAGNI after all. But this is the opposite case. I deem it: YAEGNI. You are eventually going to need it. [1] Django 3.1, just released yesterday, begins treating async as a first class citizen. I was initially opposed to this, given 99% of the time you don't need async. But I suppose it's nice to have and drop down to.
- darkhorse13 6y agoIt is very difficult to explain to someone who has not used Django/Rails just how productive they are, especially Node.js devs. I started off with Django, so when I moved to Express for a project, I was immediately slapped with the reality that I needed to write my own forms and admin site. These are some of the things that you simply do not have to worry about with the aforementioned batteries included approach of Django/Rails.
- silviogutierrez 6y agoExactly. Every NodeJS tutorial starts with: "look how easy it is to write a server and listen on port 3000". Yea it's easy. But why are you writing a server? That should be the least of your concerns.
- doteka 6y agoWell, I need to write a server if my requirements don’t fit a server side rendered application and/or my usecase does not fit the absolutely anemic performance of Rails, which also applies when using it only for an API (it’s not Ruby’s fault btw). The classic response is “zomg premature optimization bad”, but some of us work on more complex applications than simple database CRUD.
- rm_-rf_slash 6y agoSomething not touched on in this post but I’d like to know is the preference for using Rails with a Single Page App built in a framework like React. When our team determined React to be the way to go for the front end, I looked at all of the parallel dependency management and the backend complexity (one might call “sophistication”) of Rails, and ultimately decided to make the backend in Node instead. Has anyone here experienced pleasant success with RoR+SPA?
- greatjack613 6y ago>>When It’s ‘Just’ an API Server: Rails has less to offer an API server that speaks JSON over the wire. A lot of its HTTP security doesn’t matter for that case (e.g. SQL injection safeguards, XSS prevention.) I disagree on the SQL injection part, Api calls can contain user input which in turn can be used to perform SQL injection, I am not sure what the difference between a website and an api server is in regard to this concern.
- musaffa 6y agoI use Ruby to create API servers these days. For a couple of APIs, I used Rails API. Now I use a combination of dry-rb, rom-rb, roda and other pure ruby libraries to create APIs. There's a growing movement within the community to move Ruby off Rails. Before the API thing, I also developed websites with fullstack Rails. The experience with fullstack Rails and Rails API have helped me a lot to understand the requirement of a backend framework. I'm forever endebted to Rails for this.