[HN Gopher] Rails adds support for Fiber-safe ActiveRecord Conne...
___________________________________________________________________
Rails adds support for Fiber-safe ActiveRecord ConnectionPools
Author : ksec
Score : 169 points
Date : 2022-02-24 12:50 UTC (10 hours ago)
(HTM) web link (blog.saeloun.com)
(TXT) w3m dump (blog.saeloun.com)
| weatherlite wrote:
| Can you realistically open thousands of fibers though ? You will
| hit the db connection limitation pretty soon no? I'm just
| wondering what was the end goal - do people hit maximum threads
| limitation and need fibers?
|
| EDIT: I might be wrong here it could be that each Fiber released
| the connection when it's de-scheduled. I'd still like to get a
| grasp on how this improves performance ...
| mperham wrote:
| The fiber can't release the connection when yielding if there's
| an open transaction.
| weatherlite wrote:
| Hey! So what's your take on this, is this something Sidekiq
| can benefit from or not so much?
| mperham wrote:
| Realistically I don't see any benefit at all. That's not to
| say it's a bad change, just not one that provides much of
| any real world benefit to a thread-based system like
| Sidekiq. I would love to be proven wrong though!
| ehnto wrote:
| Do you mean DB connections for the DB server or some db
| connection limit in rails? For the DB server, you can scale
| that out horizontally so it doesn't have to be a hard limit if
| you need more connections.
| nickjj wrote:
| This is really exciting news. Lots of folks slam Rails for being
| slow and inefficient despite there being massive sites using it
| at scale (Shopify, GitHub, etc.) with very commendable response
| times and uptime.
|
| At the same time you can still run a single $20 / month server
| for "smaller" apps even with Rails + Sidekiq + Action Cable +
| Postgres + Redis all running on the same server to power your
| solo developed SAAS app with thousands of customers while having
| a p95+ response time of <= 100ms.
|
| PRs like this just mean things are going to get even better than
| they already are and is probably a precursor to converting a
| bunch of Rails internals to use Fibers over time. The best part
| about it is I as an end user don't need to know the details, I
| just know my CPU and memory usage will go down over time while
| runtime performance continues to get better than it already is.
|
| I wonder how long it'll take before the pendulum swings so hard
| back into the direction of Rails that it shatters even the
| original growth spikes of Rails from all those years ago. With
| Hotwire Turbo being a thing now it's very possible to build very
| nice feeling apps without writing a ton of JS while leveraging
| good old HTML and HTTP with sprinkles of Stimulus and WebSockets.
|
| The more I think about it, the more I talk myself into believing
| Ruby / Rails really are a once in a generation combination. It's
| truly that good for getting real shit done in a pleasant way.
| llamataboot wrote:
| I think there is a hacker news law that says that any post
| about a feature of a language or framework will eventually
| devolve into a general argument about whether that language or
| framework is good or not, and have nothing to do with the
| specific feature :D
| ferdowsi wrote:
| I don't think it's coming back. The big players who started
| with Ruby during the peak of its 2008~ hype curve are having
| serious scaling pains and are looking to other more performant
| languages as a way out. Engineers at these companies are going
| to be taking these lessons elsewhere.
|
| This isnt even mentioning the compelling environmental
| arguments against a computationally taxing dynamic language
| like Ruby, which is going to be louder in the next few years.
| weatherlite wrote:
| It's not coming back to what it was in 2012 but it's also not
| disappearing. It's here to stay.
| playpause wrote:
| > The big players who started with Ruby during the peak of
| its 2008~ hype curve are having serious scaling pains and are
| looking to other more performant languages as a way out.
|
| Interesting, how do you know about this? I was under the
| impression GitHub were still mostly happy with Rails.
| ferdowsi wrote:
| Github has been rewriting performance-critical components
| in Go for a while now.
|
| https://github.blog/2020-05-20-three-bugs-in-the-go-mysql-
| dr...
|
| > Although GitHub.com is still a Rails monolith, over the
| past few years we've begun the process of extracting
| critical functionality from our main application, by
| rewriting some of the code in Go--mostly addressing the
| pieces that need to run faster and more reliably than what
| we can accomplish with Ruby.
| tomnipotent wrote:
| So in other words Rails has been a success for them.
| ryeguy wrote:
| The context here is whether or not they're still happy
| with it.
| berkes wrote:
| People too often cite "speed of the language" as the only
| reason to abandon Rails (and Ruby). But this is a bit of a
| stretch, because you'll hardly ever have this performance
| problem at all and if you do, paying a little more for
| hosting infra "solves it"1. You'll hardly ever reach the
| scale at which this truly starts to matter.
|
| I'm certain there are other, far more valid reasons to
| migrate to Java, .net, Go, Rust or whatever. Rails'
| opinionated setup might simply not fit your use-case. Lacking
| language features (Interfaces, Typing, etc). Poor
| libraries(in your domain). Complex deployment- and operating
| stack. Too few good and experienced developers who know and
| like Ruby around and so forth and so on.
|
| There are numerous reasons to move away from Rails and Ruby.
| Speed is but one. And often the easiest to solve in other
| ways.
|
| 1 Actually, in my previous role as Rails consultant I often
| did performance tuning for Rails. 99.99999% of the times the
| executing time nor the GIL, nor the GC, are the problem. But
| the database is. Poor DBA, in my experience is the thing that
| makes most Rails apps slow. For which I blame Rails, because
| it makes it so damn easy to forego any sane design on the
| DBA, and just hobgobble together some
| `@user.devises.active.order(:used_at).messages.new` in your
| views, which fires the worst ever query on your database.
| dangerface wrote:
| > compelling environmental arguments against a
| computationally taxing dynamic language
|
| Cost of development has always been the more significant cost
| over compute power for these businesses. Considering the
| entire web uses under 10% of the global energy rewriting your
| entire stack in c++ for the small performance improvement is
| not going to make a dent in that.
|
| Why would businesses do this for such a small environmental
| improvement when they could spend half the money putting in
| solar and produce significantly more green energy than their
| stack uses?
| ksec wrote:
| >while having a p95+ response time of <= _100ms_.
|
| Which is where the argument began. Emphasis on the _100ms_. But
| lets not derail ( no pun intended ) into that again.
|
| >PRs like this just mean things are going to get even better
| than they already are and is probably a precursor to converting
| a bunch of Rails internals to use Fibers over time.
|
| And the fact this actually got merged. For the longest time
| watching rails I thought no one was interested. Samuel Williams
| seems to be the only one pushing for it.
| pizza234 wrote:
| > At the same time you can still run a single $20 / month
| server for "smaller" apps even with Rails + Sidekiq + Action
| Cable + Postgres + Redis all running on the same server to
| power your solo developed SAAS app with thousands of customers.
|
| This is true but in a narrow sense. Rails and Ruby are
| inherently inefficient, both in the performance and memory
| profiles.
|
| Rails is theoretically threadsafe, but not really - I've been
| hit by a threading issue just within the first hour of testing,
| and even if Rails was, the ecosystem isn't. Which means, one
| needs multiple processes, which requires lots of memory.
|
| Speed isn't great, either. I can't really do apples-to-apples
| comparison, but I think it's realistic to state that
| equivalent, statically typed, applications are very
| significantly faster (without explicit optimizations), which
| requires more computing units.
| Lio wrote:
| Things are changing on this front.
|
| We now have better fibres for IO bound code and ractors for
| thread safe CPU bound code.
|
| Personally I don't think ractors are completely solid but I
| don't think it will long until they are.
|
| I think Ruby's future is pretty rosey compared to a few years
| ago.
|
| I would even say that small projects can avoid Sidekiq and
| Redis by using Good Job and Postgres making them even cheaper
| to start with.
| pizza234 wrote:
| Regarding the ractors, I'm a big fan - I believe true
| multithreading in a language with a GIL is a revolutionary
| change. On the other hand, I also believe that Ruby has
| always had a culture of single threading, so for the
| ecosystem to adjust (in practice, for having threadsafe
| libraries), it will take a very long time (if ever; I'm
| pessimitic and personally believe the ecosystem will never
| catch up, but of course, I wish all the best :)).
| qudat wrote:
| Ruby has a severely lacking ecosystem imo and since it is
| virtually a language to support rails, so I find it hard to
| believe it will pick up anymore traction than it already has.
|
| Static typing, lack of static analysis tooling, and
| autoformatting are sorely missed. Whenever I work on a
| ruby/rails codebase I feel like I've gone a decade in the past.
| The DX is not that great and many other ecosystems have
| comparable DX with a modern toolset.
| zzzeek wrote:
| > Lots of folks slam Rails for being slow and inefficient
| despite there being massive sites using it at scale (Shopify,
| GitHub, etc.) with very commendable response times and uptime.
|
| Github is moving away from activerecord for exactly these
| reasons:
|
| https://github.blog/2020-05-20-three-bugs-in-the-go-mysql-dr...
|
| > Although GitHub.com is still a Rails monolith, over the past
| few years we've begun the process of extracting critical
| functionality from our main application, by rewriting some of
| the code in Go--mostly addressing the pieces that need to run
| faster and more reliably than what we can accomplish with Ruby.
|
| full disclosure, I'm the author of SQLAlchemy for Python. But I
| certainly wouldn't expect Github to migrate from Ruby to Python
| for speed reasons, it would be like trading up your Ford Pinto
| for a Dodge Dart - not worth a rewrite :). Right now if you
| have middleware that is to be crushed with billions of reqs per
| hour, interpreted languages are simply not going to cut it.
| jrochkind1 wrote:
| That's a good blog post, thanks for posting!
|
| I do not think "moving away from activerecord" is an accurate
| summary of what you yourself quoted, "extracting critical
| functionality from our main application... mostly addressing
| the pieces that need to run faster and more reliably than
| what we can accomplish with Ruby."
|
| Anyway, ruby and python are indeed pretty close performance-
| wise, for whatever reason python has become more popular (and
| it clearly has), it's not performance! Yet people always
| bring up performance when talking about why ruby isn't more
| popular... doesn't seem to be hurting python much.
| BosStartup wrote:
| We migrated a rails app, that needed in memory data structures,
| from rails to java. We went from needing rolling restarts and
| 100 aws servers all cpu bound, to running 10% cpu on 2 java
| servers never needing a restart.
|
| Ruby and rails is great for a PoC or a quick crud app, but it
| is not close to being performant which usually doesn't matter
| but sometimes it does.
| midrus wrote:
| I really hope some sanity comes back to this industry. Rails
| and Laravel are the best tools by far to build like... 90% of
| what we build on the internet (Other 10% being offline first
| apps and stuff like figma, etc).
|
| It just hurts to see how my team, and previous teams I worked
| with struggle with all the SPAs and microservices, and Go
| backends and GraphQL nonsense when what we're doing are just
| fancy crud forms with maybe one or two really interactive
| widgets overall.
|
| So much time and money wasted just for following fashion.
| hellcow wrote:
| Calling it "fashion" is disingenuous.
|
| I ran Rails in production years back and swore it off then.
| We had constant memory leaks that seemingly came from Rails
| itself, and the only solution we had was "just restart the
| server." We also had no typing then, so every bug was a
| runtime bug. Hopefully it's improved in the years since...
|
| I've been happily running Go backends for the past 7 years
| now, and they're stable and fast and easy to refactor.
| christophilus wrote:
| This is my experience, too. I'm currently working on a
| TypeScript+Node service, which is decent, but Go is my
| preference these days.
| midrus wrote:
| > I ran Rails in production years back and swore it off
| then. We had constant memory leaks that seemingly came from
| Rails itself, and the only solution we had was "just
| restart the server."
|
| Nothing is perfect. In my book restarting a server because
| of memory leaks is an acceptable trade off versus all the
| crazynes of having to decide and maintain on how to tie
| together a database, error validation, background jobs,
| translations, react, redux, an API to interface with the
| backend, logging, etc, etc, etc. Also, Go is just part of
| your system, I'm pretty sure you also have a frontend
| stack, and complexity increases a lot as I explained here.
| Compare that to Laravel+Livewire or Rails+ Hotwire. Night
| and day. I'm pretty sure any serious business will take the
| restarts any day vs the increased complexity and developer
| time.
|
| > I've been happily running Go backends for the past 7
| years now, and they're stable and fast and easy to
| refactor.
|
| Yes, and I bet something built in 7 years with Go would
| have taken 7 months with Rails or Laravel.
|
| On the static typing stuff, I'm with you on that. PHP (and
| Laravel) are a bit closer to that, but nothing is perfect.
| And for Web Development using Laravel or Rails is a good
| trade off.
| simplify wrote:
| Go is good and all, but it's odd to compare it to the vast
| feature set that Rails provides. The point of Rails is to
| give you standard tools so you don't have to consider /
| reimplement / configure / hook up e.g. background processes
| for every app you build.
| xionon wrote:
| > I ran Rails in production years back and swore it off
| then. We had constant memory leaks that seemingly came from
| Rails itself, and the only solution we had was "just
| restart the server."
|
| This hasn't been a serious problem in a decade.
|
| > We also had no typing then, so every bug was a runtime
| bug. Hopefully it's improved in the years since...
|
| The ecosystem has been introducing gradual typing, but even
| at high scale, types were not remotely the most common type
| of problem I ever ran into, and certainly not "every" bug.
|
| (ex-Braintree engineer, we processed billions of requests
| on Rails)
| hellcow wrote:
| > types were not remotely the most common type of problem
| I ever ran into, and certainly not "every" bug.
|
| If you took that away from what I wrote, I apologize. I
| meant that without a compiler and type-checker, you would
| only find bugs at runtime. In my experience, the vast
| majority of these would be easily discovered by a
| compiler. Presumably that experience is shared by Ruby
| devs since they're now adding type-checking.
|
| > This hasn't been a serious problem in a decade.
|
| That may be true. I haven't had any need to revisit Ruby
| or Rails since I moved to Go. But it was a serious
| problem with no workaround, and I've never encountered
| any scenario like that since switching to Go.
| midrus wrote:
| While I do like static typing, I find more bugs because
| people have no clue about security and they think they
| can do it better by just tying together a few libraries
| and storing a jwt in local storage or they forget to
| handle Prisma exceptions or they didn't know what session
| fixation is or because they forgot to consider a corner
| case of foreign key exceptions from the database library,
| etc, etc than because somebody passed a string where an
| integer was needed.
|
| Giving up frameworks with 10+ years of hardening and
| documentation and libraries and support etc just because
| of coroutines or static types or nice syntax or because
| that's what google does then I should do it too makes
| absolute no sense to me.
| tinco wrote:
| If you're finding bugs in production that a compiler or
| typechecker could have found then there's something
| seriously wrong with your test suite. That's how Rails
| works, if you don't have 90%+ statement coverage it will
| be hell.
| aczerepinski wrote:
| My experience with ruby is often documenting the expected
| argument and return types with comments and then writing
| code and/or tests to enforce the types.
|
| Having also used Go a fair amount, I very much prefer the
| real type system which both documents and enforces.
|
| I enjoy both languages though.
| DerArzt wrote:
| On the other hand, if you have a compiler/typechecker
| that finds things that your test suite could find I will
| always reach for the compiler/typechecker. No sense in
| writting tests against something a standard tool will
| find aside from sanitizing data from your inputs.
| eropple wrote:
| IME, adding that 90% statement coverage is much of the
| tedium and frustration of the job in Ruby-land--in
| particular for things that you just get _solved for free_
| with something like TypeScript.
|
| It might have improved somewhat, but I find myself pretty
| comfortable with a much more pared-down test suite that
| focuses on correctness tests at logical module boundaries
| in TypeScript, rather than verifying things the computer
| can just _do_. I do look forward to seeing Ruby 's
| gradual typing become more entrenched in the ecosystem,
| though, because I like the language--I just don't like
| using the language _professionally_ because of the
| additional manual work I find myself doing.
| dwaite wrote:
| > IME, adding that 90% statement coverage is much of the
| tedium and frustration of the job in Ruby-land--in
| particular for things that you just get solved for free
| with something like TypeScript.
|
| I would argue that if your unit test is only testing
| things which would have been shown by the type system of
| another language, you are testing at too low of a level.
| In addition to being tedious, such tests are often very
| brittle.
| eropple wrote:
| Those tests are brittle, and they're also the thing that
| protects you at module boundaries when those boundaries
| are being hammered on by different groups of people.
|
| Having them not be necessary is nice.
| jshen wrote:
| I've worked on many large rails apps at scale and large
| Java apps at scale. There has been no significant
| difference in the big count between them despite Java
| having static types.
| Tainnor wrote:
| Java has a bad type system that makes it awkward to
| express many well-typedness guarantees (too much
| boilerplate to create new types (classes or interfaces),
| no sum types (tagged unions), no null safety, exceptions
| are a mess especially with lambdas, and don't get me
| started about all the reflection madness of popular
| frameworks that throws type-safety out of the window,
| etc.). As a result you don't get much safety in exchange
| for all the boilerplate. Still, I find Java massively
| easier to refactor. You can remove a field from a class
| and verify that you've changed all the places that were
| using it (barring reflection, of course). In Rails, that
| requires _at least_ running the whole testsuite which
| could be very slow (because Rails tests are often very
| slow). And even then, you have no guarantee you didn 't
| miss a particular case.
|
| Languages with better type systems do exist (Rust, Swift,
| Kotlin, from what I hear even typescript?, and all ML
| type languages including Haskell, ...). They are much
| better at preventing bugs. My life became better when I
| had to stop worrying about NPEs, for example.
| Tainnor wrote:
| > [...] types were not remotely the most common type of
| problem I ever ran into, and certainly not "every" bug.
|
| That's a typical response from dynamic typing advocates,
| but the response is that in a language with a good type
| system, _many more things_ can be type errors than would
| be in a dynamically typed one.
|
| For example, from my time writing Ruby, trying to call
| methods on `nil` was an incredibly common error, but this
| is simply a type error in some more modern statically
| typed languages (including Kotlin and Swift).
| Lio wrote:
| I agree, I think it's a good reason to use the static
| typing in Ruby > 3.0.
|
| Any static analysis tool you can use to catch bugs before
| runtime in production is something we want.
| djur wrote:
| A substantial number of bugs I see where a method is
| called on nil are business logic errors that result in
| something not being where it's expected, and those bugs
| would just manifest differently at runtime with static
| typing. Every web app I've ever seen in a statically
| typed language has plenty of logic relying on "unwrap
| nullable or raise error" mechanisms.
| jjice wrote:
| As someone who seems to work with Go backends quite a bit,
| what's your preferred way of doing this? I've been playing
| with net/http compatible routers and I've been liking them,
| but interested to hear what someone with more experience
| uses. Any good way of dealing with common boilerplate that
| frameworks like Django and Rails help remove?
| hellcow wrote:
| On small projects, I just write out the boilerplate. It's
| annoying but it's straightforward to read and revisit
| years later.
|
| On larger projects (100k LOC+) I use chi for my router in
| combination with codegen via sqlc and moq, and I wrote a
| small program to generate the routes for me automatically
| with a config file.
| jjice wrote:
| sqlc is very interesting. Gives me sqlx (from Rust, not
| the Go package) vibes. Definitely will play around with
| this.
| zinclozenge wrote:
| There's a variety of projects out there. gorilla/mux,
| chi, httprouter are all pretty commonly used for just
| defining routes. If you want a full on framework, gin and
| beego are also common. For the database (I'm
| unfortunately mainly familiar with postgresql related
| projects) there's pgx, sqlx, gorm, and then code
| generators like sqlc such as sqlboiler and entgo.
|
| Golang encourages libraries and frameworks with much
| smaller surface, so there is indeed a boilerplate issue,
| but that's also an issue with golang as a whole.
| treeman79 wrote:
| I've seen a few times where a company replaced one guy using
| a Rails monolith with jQuery and replaced em with a 30 person
| team that is far less effective.
| midrus wrote:
| THIS
|
| I think that if we were more pragmatic and less about
| following the current fashion or trying to do what FANG
| does (which probably is just the opposite of what everyone
| else needs) we wouldn't be in such a high need of
| developers... which... I shouldn't be saying out loud
| probably :-)
| midrus wrote:
| Also, note that when not going the
| microservices/spa/kubernetes route, the alternative is not
| "old style reloads on every click and jQuery spaghetti",
| I'd say that's equally as bad.
|
| Nowadays there are alternative middle ground solutions such
| as Livewire, Hotwire, LiveView, Unpoly, Htmx, etc which
| provide a great way to organize the code and keep it
| maintainable.
| treis wrote:
| I think these are all bad ideas on the other extreme.
| Once you incur the cost of a round trip to the server the
| additional latency due to sending HTML instead of JSON is
| pretty close to 0. You really only need something like
| Turbolinks to avoid a full page reload/render.
|
| Amusingly enough at $Current_Job the JSON we send back
| that is larger in size than the HTML it's rendered into.
| We'd likely have better performance doing all server side
| rendering + Turbolinks.
| midrus wrote:
| Yeah, this is the case I was talking about with the 90%
| of cases I was referring to.
|
| At a previous job, we had a many, many thousand lines
| codebase of typescript, redux, observables, epics,
| thunks, custom server API libraries, websockets, Elixir
| backend, Kafka to communicate with other microservices,
| etc, etc..for...a frigging signup wizard.
|
| Which then failed in so many stupid ways, had almost no
| server validation (everything unexpected was a 500) and
| it took days to do the smallest of the changes. But hey,
| don't dare to suggest doing this with Laravel would take
| 2% of the effort because you'd be crucified in the next
| frontend guild meeting.
| brightball wrote:
| I'd add Elixir and Phoenix to that list and then agree with
| you.
| MathCodeLove wrote:
| I'd add Phoenix to the list when it gets its documentation
| in the same echelon as that of Rails or Laravel. It may be
| as productive if you already know how to use it, but good
| luck building anything non-trivial on your own if you
| don't.
| brightball wrote:
| Don't you usually learn how to use your tools before you
| build with them? This feels like a strange response.
| lovich wrote:
| As a bronze league engineer who still pulls a decent
| wage, you absolutely do not need to understand your tools
| to build things.
| nickjj wrote:
| I've always found the Phoenix docs to be more like
| references. There's "guide-like" aspects to it but in my
| opinion it's no where near the level of where the Rails
| docs are. I agree with the person we're replying to, I
| almost always found myself having to research third party
| sources when learning Phoenix (blog posts, IRC, etc.) to
| get answers to questions that I never had to ask about
| Rails, Flask or Django because their docs covered it very
| well.
|
| The Rails doc feels like you have DHH at your side
| guiding you on exactly how to do something in the context
| of a practical application and whenever you think to
| yourself "that's great, but what if I want to do...",
| often times the very next sentence in the docs will
| answer your exact question.
|
| The Rails routing docs
| https://guides.rubyonrails.org/routing.html are a great
| example of this when they talk about namespaces and
| scopes but there's a million other examples.
|
| It feels like it was written by folks who have been
| through the thick of it and back 100 times over to
| extract out the exact questions folks would have when
| using various features of the framework. Each piece of
| the docs feels like it's a mini book written on par with
| any book on a technical subject and then there's a
| completely separate reference guide docs with more
| examples.
|
| Even the styling of the page itself just feels good. It's
| really easy to skim and navigate. The Phoenix docs feel
| more like a big wall of text with a few small headers and
| code blocks. It's hard to explain but personally my brain
| identifies the Rails docs as easy to mentally parse where
| as the Phoenix docs are not based on nothing more than
| the styling aspect alone.
|
| Overall the Rails docs feel like they are written with a
| ton of empathy around the person reading them, completely
| holding your hand from beginning to end to solve a
| practical issue which is exactly what you need when
| learning something new. The reference guides are always
| there if all you care about are a few quick examples.
| brightball wrote:
| That's true. Rails docs are fantastic.
|
| Don't get me wrong here, I'm a big Rails fan as well.
| Been using it for a decade at this point. It's the best
| development experience out there. But eventually, you're
| going to run into issues that are harder to address with
| it. Happens on every big project I've run into.
|
| But, they all became big projects thanks to the
| productivity of Rails.
| gregors wrote:
| I like Phoenix, I really really do...but you are correct
| regarding docs. The documentation in Phoenix is fine for
| "what does this function do?". However, if you want the
| Rails Guides experience - it's just not there.
| pythonaut_16 wrote:
| What do you find lacking in the Phoenix docs? I've always
| been impressed with the docs in the major Elixir and
| Phoenix libraries.
| MathCodeLove wrote:
| There's a good deal that I feel is lacking, but a big
| issue is the lack of continuity of documentation between
| Phoenix's component parts. If I want to build a CRUD app
| with Rail, Django, or Laravel, then I can get all the
| information I need from their docs. If I want to do the
| same in Phoenix, I'll have to jump between the docs for
| Phoenix, Ecto, Plug, and HEEx/Liveview.
|
| Rails, while it has its equivalent of these modules,
| presents them in a cohesive manner and makes it clear the
| role they play in the greater context of the application.
| Phoenix doesn't make it nearly as clear and instead of
| being able to gradually learn these various concepts as
| they become relevant you have to take on the burden of
| them all before being able to even begin to be
| productive.
| sfusato wrote:
| Have you looked at the Phoenix Guides [1]?
|
| [1] https://hexdocs.pm/phoenix/overview.html
| MathCodeLove wrote:
| Yes. They do a poor job of the above and I still stand by
| what I said.
| hombre_fatal wrote:
| At the end, it's all trade-offs.
|
| After working with Rails for 10 years, I ended up preferring
| the opposite end of the spectrum of just using small
| frameworks like Express and just writing our own boilerplate.
|
| I agree with Elm's take on boilerplate: it's not boilerplate
| and glue code that makes application development hard, and I
| don't think it's always a net positive to build abstraction
| around it like you see in large frameworks. As a Rails app
| grows, I just find myself spending more and more time
| unrolling abstraction to figure out what's going on.
|
| Most things, like authentication, I prefer to just read in
| the application code itself to see what's being written to
| the cookie rather than dissect, say, the highly-abstracted
| Devise gem in a Rails app to debug session issues.
| midrus wrote:
| Yes, me too. But it makes absolutely no sense business
| wise. We like to play with tech, and learn and use the new
| shinny. While you're writing your frontend in elm and
| building your graphql API with Apollo and your serveless
| functions on kubernetes your causing a cost to your company
| which could have been avoided.
|
| That's not engineering. That's playing with Legos just
| because we can.
| treis wrote:
| I don't think this is a fair characterization of their
| post. They aren't playing with legos. Rails trades
| boilerplate code savings for abstraction. The GPs point
| is that boilerplate isn't hard to write while abstraction
| makes everything harder. And I think it's a fair
| criticism. Large Rails projects are difficult to work in
| because of that abstraction. It can be hard to even
| figure out what code is running let alone identifying
| bugs there.
| berkes wrote:
| There is no "sanity" lost, nor are the masses "following
| fashion". That is unfair to those who put real thought, time
| and effort in their software.
|
| Rails has its strong sides. And its weak sides. Trade-offs
| are to be investigated. An extremely weak side of Rails, is
| how it is very tightly coupled to the database. Which -its
| strong side- is perfect for _simple_ CRUD applications. But
| it falls down quickly when you have much more event-driven or
| domain-logic heavy applications.
|
| And yes, I _know_ Rails can be used for this. But just like I
| can, potentially write a web-app in Bash, it 's not where it
| shines and it will bring you pain.
|
| For Rails, the pain quickly becomes evident when a lot of
| business-rules are spread out through "Validators". Or when
| migrations become a pain to manage. Or when you have more and
| more complexity moved into async jobs. All of these are signs
| that the CRUD-nature and/or the tight database-coupling is
| harming you more than helping you.
|
| Choosing some other architecture that better fits your domain
| is not "following the latest fashion". It's sane, proper due-
| diligence.
| Karunamon wrote:
| _> There is no "sanity" lost, nor are the masses "following
| fashion". That is unfair to those who put real thought,
| time and effort in their software._
|
| It's also a forthright description. Developers chase fads,
| the new shiny, just like everyone else does. Neither are we
| immune to cargo-culting; I'd go so far as to make the
| absurd comparison to web apps written in shell script to be
| an instance of this.
|
| I've been behind the curtain on large Rails apps. Every
| issue you mentioned is either reasonably mitigated or
| exists more-or-less equally on other frameworks.
| skrtskrt wrote:
| Django has these same limitations in my experience, but to
| me the issues are largely caused by the _common usage
| patterns_ which are encouraged by the official docs and
| community, and lead to absurd amounts of coupling /ball-of-
| mud apps.
|
| you can be disciplined about clean
| architecture/DDD/hexagonal architecture, etc, but you have
| completely ignore the patterns encouraged by Django, Django
| Rest Framework, etc etc.
|
| Hide the ORM behind Repository interfaces
|
| Marshall ORM objects into true Domain objects
|
| Do not call to the database in the HTTP adapter/validators
|
| Etc etc
| tiffanyh wrote:
| Have you looked at Phoenix?
|
| A ton of new Rails features/development you mentioned is
| inspired by work the Phoenix team built, who were also once
| core Rails contributors.
|
| https://www.phoenixframework.org/
| weatherlite wrote:
| What does Phoenix have to do with it? The guy can't say
| anything good about Rails without us talking about Phoenix?
| Have you looked at Django? Have you looked at Laravel? Have
| you looked at Go? Rust? Node? We get it everyone is doing web
| frameworks noawdays, Rails isn't unique.
| throwamon wrote:
| Sheesh, why so much hostility? Elixir and Phoenix were
| created precisely to address Ruby's and Rails'
| shortcomings, and by noteworthy Rails contributors no less.
| They're incredibly good (paradigm-shifting even), the
| community is great, etc. They're also not mainstream yet,
| so it makes perfect sense to mention them. Just because
| you're tired of hearing about something it doesn't mean
| there aren't (lots of) people who have never heard about
| it. (See https://xkcd.com/1053/)
|
| In fact, if you're tired of hearing about this, you might
| want to expand your bubble a little bit.
|
| (I have no involvement with them, just a passerby.)
| dnautics wrote:
| For starters, phoenix has had "support" for the equivalent
| of fiber-safe database connection pools forever, and it's
| advanced enough that you can concurrently run tests that
| checkout database "sandbox" transactions _and_ you can
| spawn a task off it "that runs in another fiber" which
| will still know which database sandbox to use _and_ with
| about 10LOC you can make it so your integration test can
| issue an http request to the server and the "fiber" that
| handles the request operates in the same sandbox. Oh, and
| this pattern is part of the standard library so it will
| work with just about any other thing that needs to share
| global state (like mocks), not just databases.
| brightball wrote:
| The reason he mentions Phoenix and Elixir is because it
| differentiates from every other language and framework due
| to its concurrency and memory models. Those models make
| hard things easy that you simply cannot do in other web
| frameworks.
|
| That is why he mentions it. It's not "another web
| framework", it's changing the expectations for what you
| should be able to do without all of the crazy plumbing that
| was mentioned earlier.
|
| He replied with that because it's quite literally the
| answer to the problems pointed out. Not "another web
| framework, k thanks".
| tempest_ wrote:
| Phoenix is often mentioned in conjunction with Rails
| because Elixir's syntax is often described as "Ruby like"
| and the guy who made Elixir is(was?) a member of the rails
| core team.
| gregors wrote:
| As someone who uses and likes Elixir and Ruby, the syntax
| is more accurately described as Erlang and Ruby in a car
| crash.
| weatherlite wrote:
| Yeah I get it, thanks. I still think it would be nice to
| stop it.
| RexM wrote:
| Stop discussing technologies that were made specifically
| to address the short-comings of the topic of the article?
| Thaxll wrote:
| What people think about active record outside of Ruby, I find
| that strange to couple the storage interface to the entities that
| you manipulate.
|
| Is active record patern popular outside of Rails?
| berkes wrote:
| It is a reasonably common design pattern[0].
|
| But it has serious downsides[1], which is a valid reason to
| forego it for applications that you already know will be
| complex in domain-logic, transaction-boundaries or where
| distribution and concurrency are crucial features.
|
| Indeed, the tight coupling to the database is a real and felt
| problem. It makes migrations and deployments hard. And it makes
| layering your architecture almost impossible. e.g. I'm
| currently working on a Ruby (not Rails) application following
| the Hexagonal Architecture. Where ActiveRecord is powering the
| persistency adapter; away and aside. AR is not happy in that
| role. And we use hardly any features of AR, so it is overkill
| and will be fased out soon (we didn't design it this way, we
| merely moved the AR out of an existing tangled mess into its
| dedicated layer/adapter; the next logical step is to remove AR
| entirely).
|
| [0] https://martinfowler.com/eaaCatalog/activeRecord.html [1]
| https://en.wikipedia.org/wiki/Active_record_pattern#Criticis...
| Lio wrote:
| There's no reason why you have to couple storage interface to
| business logic.
|
| I've done this before. Develop business logic as a separate gem
| and then include that in a Rails project.
|
| ActiveRecord is actually entirely optional in Rails, it's just
| the default.
|
| You can also use POROs as presenters and mixin ActiveModel if
| you want things like validations.
|
| Then couple that with Sequel as an alternative to ActiveRecord
| to run data access objects.
|
| Sequel is often regarded as a more permanent alternative to
| ActiveRecord. It's not a drop in replacement though so that
| might be a consideration for team skills/support.
| ehnto wrote:
| It's not quite coupled to the storage, in that you can use a
| number of different drivers with ActiveRecord for the actual
| storage portion. But I think you might mean coupling the model
| so tightly to it's CRUD logic.
|
| Inside the application you are actually trying to get all the
| benefits of having an Active Record model, not all the benefits
| of having a Car/Cat/Dog model. So you don't actually have a Car
| model, you have an Active Record model that represents a Car.
| Thinking about it that way I think sets the right expectations
| for what you're trying to achieve.
| dwheeler wrote:
| It's an extremely common pattern.
|
| ActiveRecord is an example of an ORM. ORMs are a very common
| way to connect an object oriented language with a relational
| database. Since many languages are object oriented, and the
| databases many people use are relational databases, this is a
| common solution.
| arnvald wrote:
| I believe it's quite common outside of Ruby world - for example
| both Python and PHP have popular active record implementations
| (Django ORM and Laravel ORM respectively).
| byroot wrote:
| This article is full of inaccuracies, I don't think the author
| really understand the subject.
|
| > As Rails continues to replace the usage of threads with fibers
|
| That's not what we're doing... Rails doesn't really use threads
| anyway. We just introduced an indirection so that the request
| state can be stored either on thread local or fiber local
| variables.
|
| > An isolation level determines how database tractions are
| propagated to other users and systems.
|
| The author is confusing `active_support.isolation_level` which is
| either Fiber of Thread with database transaction isolations. The
| concept is similar, hence why the name was chosen, but it's two
| very different things.
|
| > Ideally, in the foreseeable future, we can expect good
| performance improvements to Rails I/O operations.
|
| Not really no. I/O will still be IOs, you may gain a tiny bit
| because of the cheaper "context switches", but it's gonna be very
| marginal for the vast majority of Rails apps.
|
| The goal is to allow the community to use fiber based server if
| they wish, but I (the author of most of these changes) don't
| except any substantial performance improvement from it.
| acallaghan wrote:
| Nice - there's a demo repo of this on edge Rails here:
| https://github.com/machty/rails-edge-async-test
___________________________________________________________________
(page generated 2022-02-24 23:01 UTC)