commit d18165f4b22ee6636103d5fed2b4a411b1cc3550
parent 4324f4e21e03f94c29e73fc50cfcf27130f31732
Author: David Eisinger <[email protected]>
Date: Sat, 4 Nov 2023 13:38:46 -0400
Edit ruby post
Diffstat:
3 files changed, 383 insertions(+), 2 deletions(-)
diff --git a/content/elsewhere/why-i-still-like-ruby-and-a-few-things-i-dont-like/index.md b/content/elsewhere/why-i-still-like-ruby-and-a-few-things-i-dont-like/index.md
@@ -3,6 +3,12 @@ title: "Why I Still Like Ruby (and a Few Things I Don’t Like)"
date: 2020-08-06T00:00:00+00:00
draft: false
canonical_url: https://www.viget.com/articles/why-i-still-like-ruby-and-a-few-things-i-dont-like/
+featured: true
+references:
+- title: "When Should You NOT Use Rails?"
+ url: https://codefol.io/posts/when-should-you-not-use-rails/
+ date: 2023-11-04T17:36:55Z
+ file: codefol-io-bskabg.txt
---
The Stack Overflow [2020 Developer
@@ -49,7 +55,7 @@ from and contributes to, and with a few notable
exceptions[^2], it's all made available without the
expectation of direct profit. This means that you can pull a library
into your codebase and not have to worry about the funding status of the
-company that built it (thinking specifically of things like
+company that built it (contrast with ventured-funded open-source like
[Gatsby](https://www.gatsbyjs.org/) and [Strapi](https://strapi.io/)).
Granted, with time, money, and a dedicated staff, the potential is there
to build better open source products than what small teams can do in
@@ -151,7 +157,7 @@ thread](https://www.reddit.com/r/ruby/comments/hpta1o/i_am_tired_of_hearing_that
(and [this
comment](https://www.reddit.com/r/ruby/comments/hpta1o/i_am_tired_of_hearing_that_ruby_is_fine/fxvfzgo/)
in particular) or [this blog
-post](http://codefol.io/posts/when-should-you-not-use-rails/), but what
+post](https://codefol.io/posts/when-should-you-not-use-rails/), but what
really matters is whether or not Ruby is suitable for your needs and
tastes, not what bloggers/commenters/survey-takers think.
diff --git a/static/archive/codefol-io-bskabg.txt b/static/archive/codefol-io-bskabg.txt
@@ -0,0 +1,374 @@
+ [1]Codefol.io book logo
+
+[2]Codefol.io
+
+ * [3]All Articles
+ * [4]Articles by Topic
+ * [5]Favourite Articles
+ * [6]RSS
+ * [7]About
+
+When Should You NOT Use Rails?
+
+ A chimpanzee in a white coat types at a keyboard lit by glowing LEDs.
+ He's gorgeous, yes. But is his talent natural… or is it Ruby on Rails?
+
+ I was [8]recently on Jason Swett’s podcast again. He’s a great
+ interviewer and I always have fun with him.
+
+ By Twitter request we talked about… When would you not use Rails? It’s
+ a great question.
+
+ For the entertaining version, [9]listen to the podcast. For the
+ just-the-facts extra-complete version, I’m writing this post.
+
+When Is Rails the Wrong Choice?
+
+ I’ll start with a few simple, obvious times you wouldn’t use Rails, and
+ then I’ll talk about some technically interesting times.
+
+ First, and most important, is team familiarity. If your team doesn’t
+ already know Rails and isn’t especially interested in learning it then
+ Rails is the wrong choice. This should be obvious, but it still
+ deserves first billing.
+
+ Second, when you know some other framework fits better. I’ll talk more
+ below about when that is. But sometimes you have a specific concern
+ that trumps everything else. If you need to use a Java-language machine
+ learning library and you don’t want to use JRuby for some reason, Rails
+ isn’t your framework. If you’re writing a WordPress plugin, you’ll be
+ doing it in PHP. Often there’s one specific compatibility concern that
+ overrides everything else.
+
+ You can also think of it as: use it where Rails’ good points hold and
+ its bad points don’t. So we’ll also talk about the good and bad points.
+
+ Separately: you’d normally only use Rails as an HTTP server, so some
+ tasks just aren’t Rails-shaped.
+
+When is Rails Too Much?
+
+ [10]A pirate puppet with an eyepatch, safety goggles and a huge
+ scraggly mustache watches over a purple crystal ball at his feet.' He’s
+ too much lab assistant for your lab.
+
+ Some places not to use Rails can include:
+
+ Really Small Tasks that Won’t Grow: if a server does very little, Rails
+ is often too much. Not going to touch a database? Then the DB setup
+ isn’t helping you, is it? Just a tiny low-traffic intermediate server
+ with no caching? A lot of Rails is more trouble than it’s worth.
+
+ Be careful with tasks that grow, though — making a tiny server scale up
+ to do a lot more can be ugly. If you’re already serving HTTP pages to a
+ human with a web browser, consider that you may have to add features to
+ it later. Something like that is already fairly large from the word
+ “go”.
+
+ 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: CSRF protection is entirely about dealing with
+ HTML and Javascript. Many kinds of XSS attacks are dependent on a
+ browser as the weak link, or on putting unescaped user input into HTML.
+ Redirection vulnerabilities assume automatic redirection, which APIs
+ usually don’t do. You can prevent SQL injection attacks with just an
+ ORM, a simpler ORM, or even the raw Ruby MySQL and Postgres gems, which
+ support question-mark arguments.
+
+ Rails security really shines when you’re navigating the bewildering
+ world of HTML and browser security. Small projects that mostly speak a
+ structured format read by machines will get less from Rails. Securing
+ something like an integer ID or a hash of strings is just easier than
+ ensuring your HTML contains no script tags or anything exploitable.
+
+ Related to that is when you’re doing in-browser rendering and Rails is
+ ‘just’ serving JSON. It’s a weird kind of in-between case. A lot of
+ Rails security and convenience functions no longer help you, but you’re
+ still doing things where internal libraries (ActiveRecord, ActiveJob,
+ ActionMailer) can be highly useful. But if you’re never rendering HTML
+ on the server and you’re very sure you never will, Rails will probably
+ help you less.
+
+When Is Rails Not Enough?
+
+ Rails is also designed for a small team and a medium-sized codebase. A
+ huge team (lots of programmers) or a huge codebase (lots of
+ controllers, models and/or lines of code) will tend to drag down the
+ standard Rails-app structure.
+
+ Ruby allows for a lot of [11]non-local effects. Whether that’s
+ monkeypatching, writing to a database or creating new types at runtime,
+ Ruby isn’t designed for a team of 200 programmers where you don’t trust
+ some of them. There are too many ways for them to cause you trouble.
+ You can use [12]good tooling to scale Ruby to larger teams, but even
+ that will [13]tend to have exceptions and difficulties. That’s not
+ really Ruby’s sweet spot.
+
+ In most cases you can cut up a large project into smaller projects. If
+ one Rails app is too big, you can often separate it into multiple apps,
+ or a thinner app with more back-end services, or an app and a separate
+ microservice, or… One way or another there is usually a way to separate
+ out smaller pieces. Ruby strongly encourages that, as do I.
+
+ There are also not-quite-Rails structures that can scale better. Avdi
+ Grimm’s (now retired) [14]Objects on Rails was an attempt in that
+ direction, as is [15]the Hexagonal architecture for Rails, which in
+ turn has a lot in common with the older and more general [16]N-tier
+ architecture.
+
+ But at some point you might want to consider a different framework.
+ [17]Hanami is an obvious choice, designed to be less quick and nimble
+ than Rails for getting a tiny app off the ground, but more scalable if
+ you want to use the same code with a lot more contributors.
+
+ 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. Wait to rewrite (in a more rigid framework)
+ until you’re successful and you can afford the drag on your development
+ speed.
+
+ The other worry here can be performance. If you’re rewriting a project
+ that is already as large as the current Basecamp… then you’re
+ [18]actually fine for performance. Rails still scales great for them.
+ But if you’re looking at something a hundred times larger (which by
+ definition means B2C, not B2B) then you might have a situation where
+ your server costs are substantially greater than your engineering
+ payroll. In that case it can make sense to slow down your engineers to
+ pay lower server costs. To check this, see what your EC2-or-equivalent
+ costs are just for your application servers, which are what run Rails.
+ And check your payroll just for web engineers, which is who writes in
+ Rails. Normally the engineering payroll is much larger and you should
+ stick with trading cheap machine time for expensive engineering time.
+ But at some point the balance may tip and you should consider raising
+ your engineering payroll to cut your server costs.
+
+When Does Rails Have the Wrong Assumptions?
+
+ [19]A pirate, a bear and a chimp sit at a wicker table. The bear looks
+ into a very old-fashioned microscope as the other two look on. They’re
+ checking the microscope for real-world use cases where Rails might be
+ wrong.
+
+ Before checking if Rails’ assumptions are right for you, we should see
+ what those assumptions actually are.
+
+ Before you take my word for it, I recommend taking [20]David Heinemeier
+ Hansson’s word for it in the form of The Rails Doctrine. It’s a great
+ document and it covers a lot of ground.
+
+ Indeed, if you want to better understand why Rails isn’t amazing for
+ large, low-trust teams, you should read [21]“Provide Sharp Knives” in
+ the Rails Doctrine several times. A lot of Rails’ tradeoffs are
+ entirely by design.
+
+ Rails also has some simpler assumptions: it assumes you’re writing an
+ interactive app with server-rendered HTML. It assumes that security is
+ vital (Rails trades a lot for security) but that you don’t want to
+ build your own custom security system in most cases. And it assumes
+ that you either have a small, excellent team doing prototyping work
+ (“Provide Sharp Knives”) or that you have a possibly-mediocre team that
+ needs powerful built-in guidelines ([22]“The Menu is Omakase.”)
+
+ Rails also assumes you want high developer velocity at a cost of
+ technical debt. In other words, it’s designed for building very
+ quickly. That makes sense when technical execution is not your biggest
+ risk. For instance: if you’re building a small startup, and you’re
+ pretty sure you can build the site but people may not buy your product,
+ you are dominated by market risk. That’s when Rails is perfect. You
+ want to build very quickly. And even if you build perfectly, you’re
+ probably going to have to throw away the result for nontechnical
+ reasons, like “people don’t want to buy it.”
+
+ As part of “high dev velocity, technical debt is okay” Rails assumes
+ things like, “you’ll want to use a lot of gems” and “dependencies that
+ work are fine if they speed you up.”
+
+ Rails assumes you don’t mind scaling out application servers
+ horizontally (by bringing more of them online.) It’s designed to scale
+ well if you can do that. Rails assumes CPU is fairly cheap and it’s
+ usually right about that. Relatedly, Rails assumes that the database is
+ usually your most serious performance bottleneck, which is how web
+ applications usually work.
+
+ Rails also assumes you’ll have some calculation or data transformation
+ in your application. It assumes that it’s okay to use some CPU because
+ you’ll be doing that anyway.
+
+ (When does that last assumption matter? Let’s talk about Evented
+ Servers and see.)
+
+What Isn’t Rails Good At?
+
+ [23]The Node.js logo. Sometimes you need it, or something like it.
+
+ While Rails is great at a lot of things, there’s one particular task
+ that it’s not amazing for: shim servers.
+
+ By “shim servers” I mean servers that do very little calculation but
+ integrate answers from a few other back-end services and relay the
+ result. Imagine a server that queries two JSON services and combines
+ the result with simple string-manipulation, for instance. It does very
+ little calculation, but it juggles a lot of events.
+
+ And that’s the relevant word: “events.”
+
+ There is a specific kind of app architecture embodied by Node.js and
+ its relatives called “Evented” programming. It can support many
+ thousands, or even millions, of simultaneous connections with a tiny
+ amount of server resources. It can be both high-throughput and
+ low-latency. Its benchmark numbers are matchless… for the cases where
+ it works.
+
+ Rails can’t match Evented programming at what Evented programming is
+ good at. Basically no framework can. There are Evented frameworks for
+ Ruby (e.g. [24]EventMachine, [25]Async.) Rails is built differently.
+
+ If Evented is so much better, why don’t we use it for everything?
+ Because it doesn’t work for everything. I emphasise calculation
+ per-request because an Evented server will fall down and die if you try
+ to make it do very much calculation per-request. Having one server
+ handle a million connections is no good if each connection winds up
+ using a hundred milliseconds of CPU time — that’s simply too many
+ connections and the latency will be terrible.
+
+ In other words, Rails and Node.js are different tools for different
+ projects. If you’re thinking, “I should either use Rails or Node for
+ this” I would recommend looking deeper into your project (and/or your
+ framework) until it’s obvious which one is the right answer. They do
+ different things.
+
+Look, I Just Scroll to the Bottom for the Summary and Criticise It On Reddit
+
+ [26]A chimpanzee in a lab coat stares down at his lap, containing
+ sections of wooden train track, and his hand holding a toy train. I’m
+ sure this is the right answer, but I have forgotten the question.
+
+ Rails is the wrong choice if your team doesn’t want to use it or
+ doesn’t know how.
+
+ Rails is the wrong choice in cases where a different framework is
+ specifically better, or you have a specific library you need to be
+ compatible with that isn’t Rails-friendly.
+
+ Rails might be the wrong choice if you’re not rendering HTML on the
+ server, especially if your project is very small and/or doesn’t use a
+ database.
+
+ Rails is the wrong choice is you’re not doing prototyping-flavoured
+ work, preferably with a small, highly-competent team.
+
+ Rails is the wrong choice if your dev team or your app code is too big
+ and you can’t subdivide the project.
+
+ Rails is the wrong choice if your project wants an Evented server like
+ Node.js or EventMachine.
+
+ This article is the wrong choice if you’d rather [27]listen to an
+ entertaining podcast on the same topic.
+
+ If you’re wondering when Rails is the right choice, [28]the Rails
+ Doctrine is a great first step.
+ Aug 6 2020
+ [29]ruby [30]rails
+
+You Hunger to Get Better
+
+ Subscribe to get free ebook chapters and an emailed coding class now,
+ plus videos and articles a few times a month.
+
+ Why this specific newsletter? You want to be an expert. Expertise comes
+ from learning the fundamentals, deeply. And that comes from the best
+ kind of practice. I write with that in mind. I won't waste your time.
+
+ (Yes, I also sell things. They're good, but I'm fine if you don't buy
+ them.)
+ ____________________ ____________________ (BUTTON) Sign-up
+
+Comments
+
+ Please enable JavaScript to view the [31]comments powered by Disqus.
+ [32]comments powered by Disqus
+
+Read Next
+
+[33]Computer Science: Just the Useful Bits
+
+ [34]ruby [35]rails
+ [36]Computer Science: Just the Useful Bits
+
+[37]Let's Build Course Software: Email Reminders
+
+ [38]ruby [39]rails [40]letsbuild [41]rubymadscience
+ [42]Let's Build Course Software: Email Reminders
+
+[43]Free Rebuilding Rails Video Chapters
+
+ [44]career
+
+[45]The Urban Legend of the 10X Developer
+
+ [46]career
+ [47]The Urban Legend of the 10X Developer
+
+ [48]Mastodon [49]GitHub [50]Linkedin [51]Mastodon
+
+ [52]Codefol.io © 2020 . Horace theme by [53]JustGoodThemes..
+
+ [54]Back to top
+
+References
+
+ 1. https://codefol.io/
+ 2. https://codefol.io/
+ 3. file:///posts
+ 4. file:///topics
+ 5. file:///tags/favourite
+ 6. file:///feed.xml
+ 7. file:///about
+ 8. https://www.codewithjason.com/rails-with-jason-podcast/noah-gibbs-3/
+ 9. https://www.codewithjason.com/rails-with-jason-podcast/noah-gibbs-3/
+ 10. https://rubymadscience.com/img/assistant_pirate_with_sphere_bigthumb.png
+ 11. https://en.wikipedia.org/wiki/Side_effect_(computer_science)
+ 12. https://sorbet.org/
+ 13. https://sorbet.org/docs/troubleshooting#escape-hatches
+ 14. https://www.goodreads.com/book/show/13481927-objects-on-rails
+ 15. https://medium.com/@vsavkin/hexagonal-architecture-for-rails-developers-8b1fee64a613
+ 16. https://en.wikipedia.org/wiki/Multitier_architecture
+ 17. https://hanamirb.org/
+ 18. https://m.signalvnoise.com/only-15-of-the-basecamp-operations-budget-is-spent-on-ruby/
+ 19. https://rubymadscience.com/img/dr_bear_microscope_bigthumb.png
+ 20. https://rubyonrails.org/doctrine/
+ 21. https://rubyonrails.org/doctrine/#provide-sharp-knives
+ 22. https://rubyonrails.org/doctrine/#omakase
+ 23. file:///posts/when-should-you-not-use-rails/node_js_logo.png
+ 24. https://github.com/eventmachine/eventmachine
+ 25. https://github.com/socketry/async
+ 26. http://rubymadscience.com/img/rails_internals_bigthumb.png
+ 27. https://www.codewithjason.com/rails-with-jason-podcast/noah-gibbs-3/
+ 28. https://rubyonrails.org/doctrine/
+ 29. file:///tags/ruby/
+ 30. file:///tags/rails/
+ 31. http://disqus.com/?ref_noscript
+ 32. http://disqus.com/
+ 33. file:///posts/introducing-computer-science-just-the-useful-bits/
+ 34. file:///tags/ruby/
+ 35. file:///tags/rails/
+ 36. file:///posts/introducing-computer-science-just-the-useful-bits/
+ 37. file:///posts/series-build-coding-course-email-reminders/
+ 38. file:///tags/ruby/
+ 39. file:///tags/rails/
+ 40. file:///tags/letsbuild/
+ 41. file:///tags/rubymadscience/
+ 42. file:///posts/series-build-coding-course-email-reminders/
+ 43. file:///posts/free-rr-video-chapters/
+ 44. file:///tags/career/
+ 45. file:///posts/urban-legend-of-the-10x-developer/
+ 46. file:///tags/career/
+ 47. file:///posts/urban-legend-of-the-10x-developer/
+ 48. https://ruby.social/@codefolio
+ 49. https://github.com/noahgibbs
+ 50. https://www.linkedin.com/in/noahgibbs
+ 51. https://ruby.social/@codefolio
+ 52. file:///var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L9874-9978TMP.html
+ 53. https://justgoodthemes.com/
+ 54. file:///var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L9874-9978TMP.html#page
diff --git a/themes/v2/layouts/elsewhere/single.html b/themes/v2/layouts/elsewhere/single.html
@@ -20,5 +20,6 @@
{{ .Content }}
+ {{- partial "references.html" . -}}
{{- partial "backlinks.html" . -}}
{{ end }}
