Has anyone tried TruffleRuby in a project yet?
Moving my serverless project to Ruby on Rails
141–150 of 189 posts
Re: Moving my serverless project to Ruby on Rails
#142Earlier quoted context omitted.
> It doesn't allow you to run all the other services like DynamoDB, SNS, S3, etc. locally. Sounds like you're mixing up how a test pyramid works. AWS SAM supports running unit tests locally. Your remarks refer to integration tests. Integration tests are expected to be performed on environments that mimic either subsets of the production environment, or the whole production environment. https://docs.aws.amazon.com/whi…
What about manual tests? You know, just running the app on your machine and check if it works/how it works. You're forced to either share the aws resources with other devs or provision separate resources for each dev which is a big PITA.
As long as you use terraform/cloudformation/sam, it should be fairly simple. You deploy everything with your name as a suffix. Most of the resources will be billed on usage only as well, so you don't even pay more than a few cents for testing like that.
Re: Moving my serverless project to Ruby on Rails
#143Earlier quoted context omitted.
DynamoDB and AWS Step Functions are notable exceptions to the fact that AWS services are usually not available locally. The vast majority of AWS services isn't available outside of AWS.
I have a local tool for every AWS service just tell what are you looking for, for example I use https://github.com/softwaremill/elasticmq to emulate SQS locally
There's also https://github.com/localstack/localstack for the heavier services.
Re: Moving my serverless project to Ruby on Rails
#144Earlier quoted context omitted.
Even in mid-sized projects there's usually one or two pages with sufficiently complicated front-ends that it's worth having something like React in your toolbox, though it might be Vue or Svelte. You don't have to make the whole app a SPA to use these tools. You can just use it in those few pages that really need it.
Meh, put React into your build, maintain the thing, make the website download and parse React - all that just for one page? Better be a damn dynamic page. I wouldn't do it even if it's a big form with some dynamic fields.
It's very easy to load React only on the page that needs it. Use dynamic ES module import, or link the standalone builds only on the pages that use it.
Alternative like Preact is very small and can be easily (pre)cached on the client side.
Re: Moving my serverless project to Ruby on Rails
#145I have no strong opinion on serverless but I’ve used Rails for 13 years now (in massive $multi-million SaaS products as well as hobby projects) and it still makes me happy. I keep thinking about learning Node and React but I just can’t be bothered because Rails lets me get things done so quickly while also being a joy to write Ruby and Rspec. Regarding hosting, I think this is actually a great time to host Rails apps…
I’m also a big fan of rails, but I’ve experienced a lot of problems scaling it. A lot of the problems ultimately came down to the simple fact that Ruby is really, really slow. At a certain scale you end up forced to develop infrastructure on a different stack to keep up with the CPU load. I never ran into that so quickly when building similar systems with java, go, and C#. I wanna say something nice about rails too s…
Would love to hear what you're doing that's got Ruby pegging the CPU. I've ran a few rather large Rails deployments over the years and it's rare to crush the app tier first, so I wonder if there's something unique here that we can make Rails better at.
Re: Moving my serverless project to Ruby on Rails
#146Earlier quoted context omitted.
For example a newspaper with customizable content, 1 petabyte (70% video) per month and avg. 2k request per second.
Which newspaper is hitting 2k req/s ?
For example:
https://stackoverflow.com/a/373188
> Wikipedia seems to be 30000 to 70000 [requests] per second spread over 300 servers
So 2k is not unusual for bigger news sites, that may or may not employ a (few) rails team(s).
Re: Moving my serverless project to Ruby on Rails
#147Earlier quoted context omitted.
I’m also a big fan of rails, but I’ve experienced a lot of problems scaling it. A lot of the problems ultimately came down to the simple fact that Ruby is really, really slow. At a certain scale you end up forced to develop infrastructure on a different stack to keep up with the CPU load. I never ran into that so quickly when building similar systems with java, go, and C#. I wanna say something nice about rails too s…
"the simple fact that Ruby is really, really slow"... it's that slow that Shopify and Stripe don't mind building their global scale products in Ruby.
Slowness seems to be an overblown issue when it comes to the backend. Hardware is cheap compared to developers and app servers scale horizontally by default; if a language is actually slow but otherwise provides good productivity it's almost always cheaper to throw more hardware at it than move to a "faster" language (there's a reason we don't typically write web apps in C).
Re: Moving my serverless project to Ruby on Rails
#148I've seen a lot more discussion of Ruby recently than in past years, and maybe I'm just finding what I'm on the lookout for, but either way it makes me happy :)
I think it's past the latest hate cycle to good all boring now, kinda like php but with a bit of a better rep. I'm not sure actually why php and ruby are so despised.
> php
I personally quit PHP around 2013 because of the inconsistent standard library. I spent more time looking up the docs than developing because the language just wasn't intuitive compared to let's say Python. However, beyond that, PHP has some pretty great frameworks nowadays (and I am forever grateful to Laravel for teaching me the concepts of an MVC framework, which proved useful when I switched to Django).
Re: Moving my serverless project to Ruby on Rails
#149Earlier quoted context omitted.
Elixir (with Phoenix) really is the sweet-spot for a productive framework that's fast, scalable and easy to pick up for a Rails developer: https://medium.com/coryodaniel/from-erverless-to-elixir-4875...
Second this. I did rails for years and liked it a lot, but there were pain points, particularly as a project scaled. Elixir/Phoenix solves a lot of these pain points and is a joy to work with. If you like Ruby/Rails then you already know quite a bit of Phoenix. Schedule yourself 4 hours to follow a tutorial or book.
If you need high concurrency then Elixir is awesome but you can get the same performance from Ruby + lighter framework like Roda or Sinatra.
Re: Moving my serverless project to Ruby on Rails
#150I have no strong opinion on serverless but I’ve used Rails for 13 years now (in massive $multi-million SaaS products as well as hobby projects) and it still makes me happy. I keep thinking about learning Node and React but I just can’t be bothered because Rails lets me get things done so quickly while also being a joy to write Ruby and Rspec. Regarding hosting, I think this is actually a great time to host Rails apps…
I’m also a big fan of rails, but I’ve experienced a lot of problems scaling it. A lot of the problems ultimately came down to the simple fact that Ruby is really, really slow. At a certain scale you end up forced to develop infrastructure on a different stack to keep up with the CPU load. I never ran into that so quickly when building similar systems with java, go, and C#. I wanna say something nice about rails too s…
Rails makes it really easy to do something 10 different ways to get the same result. Unfortunately, most of which aren't the most performant way. In my 10 years of building Rails apps of all different sizes, and seeing some very mature apps in production, this is the most common culprit I've seen.
I currently work on a rather large Rails app for a site that most of us here use. A common pattern for our performance pitfalls are things like this:
Tag.all.map(&:name)
Tag.all.pluck(:name)
`#pluck` will change the SQL from `select * from tags` to `select tags.name from tags` and never instantiate a `Tag` object, instead short-circuiting and directly fetching the resulting SQL rows — which comes back as an array. It's something along the lines of:
ActiveRecord::Base.connection.exec_query(Tag.select(:id).to_sql)
ProgrammingLanguage.where(tag_id: @user.tags.select(&:language_tag?).map(&:id))
ProgrammingLanguage.where(tag_id: @user.tags.select(:id).where(type: 'LanguageTag'))
The second example joins the two resulting SQL statements and calls `#to_sql` on the second statement, building one query from two queries.
Are these times when the first example would be preferred? Yeah, plenty! If your result is already `#loaded?`, then you probably don't need to hit the database again. But for this example and the ones I'm stumbling across while getting our company up-to-speed on "good ways", these are the the commonalities.
Save for only very recently, the company I work for hasn't put emphasis on real-world Ruby/Rails skills, instead "if you can code at a high level for any language, we think you can make reasonable contributions to our codebase." This has lead to hiring skilled developers that just don't know that there's a more preferred way of doing things in Rails for different contexts.
Double-edged sword, really.