Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to build a search engine with Ruby on Rails

blog.testdouble.com

Post reply on HN
Print view View original

31–40 of 65 posts

Re: How to build a search engine with Ruby on Rails

#31

Post by Toutouxc »

I love the section about getting rid of Active Record only to discover that the handwritten SQL equivalent is unmaintainable and slower.

Also if you're on the fat-models team and you have lots of behaviors and business logic on your models, it's often easier to just go with Active Record, because the second you wander off the beaten path (e.g. handwritten joins) you start dealing with weird franken-models that contain attributes from multiple tables, but not their behaviors (methods, callbacks).

Re: How to build a search engine with Ruby on Rails

#32

Post by semisober »

jamesfinlayson wrote: post #4
gscho wrote: post #2

This is a bit off topic but I wanted to say I’m really glad there are still people out there hacking on some ruby + Postgres projects and writing about it. I feel that ruby is an excellent language and dread the demise of it.

As someone who has recently started using Ruby for some personal projects - I agree. I like the simplicity of it and that I can do simple command line one liners with it.

Exactly, I only started maybe a month ago and incredibly simple to get into.

Re: How to build a search engine with Ruby on Rails

#33

Post by ksec »

jamesfinlayson wrote: post #24
sho wrote: post #12

Earlier quoted context omitted.

Isn't that graph hopelessly tainted by eg. the dominance of WordPress? I mean, yes that's PHP, but just because 80% of sites are running it doesn't mean 80% of development is in PHP. Far from it.

It is, but discounting PHP because of WordPress from that graph is still interesting - I doubt there are free one-click installs for ASP.Net like there are for WordPress for example, but are there for Ruby on Rails?

That graph counts site using Shopify. And shopify represent 80%+ of RoR usage.

Re: How to build a search engine with Ruby on Rails

#35

Post by lambda_lord »

Mikeb85 wrote: post #23
itake wrote: post #6

Earlier quoted context omitted.

Rails hasn't had any interesting updates since version 4, and arguably introduced a few regressions IMHO (I'm looking at you, active storage and action cable) Ruby hasn't evolved much either. Rails only scales so far and then scaling gets really challenging, obviously the named companies have figured it out, but its not easy. For example, rails due to the high coupling between models and the database, rspec test get…

Rails doesn't scale? Github's the largest code repository site in the world. Stripe's one of the largest fintech sites in the world. Shopify is one of the largest ecommerce sites in the world. There's also Airbnb, TripAdvisor, many others that are huge. Also, you can write shitty, slow code in any language. You can make too many calls to the DB in any language. You can also scale to Google size in any language. Pytho…

Stripe never used Rails. It uses Ruby with in-house ODM libraries, logging frameworks, and more. And a lot of those features are being moved to Java services.

Re: How to build a search engine with Ruby on Rails

#36

Post by KronisLV »

Mikeb85 wrote: post #23
itake wrote: post #6

Earlier quoted context omitted.

Rails hasn't had any interesting updates since version 4, and arguably introduced a few regressions IMHO (I'm looking at you, active storage and action cable) Ruby hasn't evolved much either. Rails only scales so far and then scaling gets really challenging, obviously the named companies have figured it out, but its not easy. For example, rails due to the high coupling between models and the database, rspec test get…

Rails doesn't scale? Github's the largest code repository site in the world. Stripe's one of the largest fintech sites in the world. Shopify is one of the largest ecommerce sites in the world. There's also Airbnb, TripAdvisor, many others that are huge. Also, you can write shitty, slow code in any language. You can make too many calls to the DB in any language. You can also scale to Google size in any language. Pytho…

> Rails doesn't scale? Github's the largest code repository site in the world.

You know, i think i understand both of the viewpoints here. Personally, i'd say that Rails doesn't scale as well as i'd expect it to. You can definitely build scalable systems in it, though you'll end up throwing a whole bunch of hardware resources, when compared to certain other languages and technology stacks, to serve similar load.

For example, right now i self-host a GitLab (https://about.gitlab.com/) instance for managing my code repositories, CI builds and so on. Even with just me using it (alongside some automated processes), it routinely eats up close to 4 GB of RAM, which in my case is an entire VPSes worth and costs me about 60 Euros a year with Time4VPS (affiliate link, if you'd like to check it out: https://www.time4vps.com/?affid=5294) but would cost me way more in AWS, GCP etc. One could argue that that's not too expensive, but not everyone earns a lot of money and running 10-20 VPSes does eventually add up, since i can't afford colocation and my residential homelab setup with a WireGuard tunnel to bypass ISP NAT with a proxy VPS is pretty slow, even if i can afford more storage, RAM and CPU power that way.

Compare that situation to projects like Gogs (https://gogs.io/), Gitea (https://gitea.com/), GitBucket (https://gitbucket.github.io/) and sourcehut (https://sourcehut.org/) - i'd argue that all of them on average use less CPU resources and memory for accomplishing similar tasks.

However, we cannot ignore the fact that using Ruby might have been exactly what allowed for quickly creating the functionality of GitLab and many other platforms and tools out there, GitHub included, so the choice between usable software and innovation in the near future and performant software possibly years from now is a tricky one.

There are probably good arguments for both, but noone can declare either to be better. Personally, i don't mind using Ruby, Python or even PHP when it makes sense and i don't need to worry about scalability from day 0.

Re: How to build a search engine with Ruby on Rails

#37

Post by gvurrdon »

stephenhuey wrote: post #14
wpietri wrote: post #10

Earlier quoted context omitted.

Depends on the product. The Rails architecture is fine for CRUD apps, and Heroku will happily take more and more money for more and more database capacity. As long as your ARPU is solid, you're fine scaling like that. But there are more things in the world than CRUD apps. I'm building tools to track hate on social media, and there's a lot of social media out there. Rails, or any RDBMS-centered architecture, won't cut…

For implementing ye olde business logic, which is far more common in software development than cool tech such as ML that is discussed a disproportionally high amount compared to its real-world usage, Ruby on Rails wins. Sure, there are lots of frameworks that are good for shipping business features quickly, but Ruby on Rails is still among the leaders of that group due to concise code, magical defaults that give you…

There's a lot of "ye olde business logic" in what I'm building, for people who often change their mind about what they want. A Rails API (with Postgres and Elasticsearch) makes this fairly easy to handle, especially with the limited staff we have. A Vue.js client provides the fancy UI the users want.

Re: How to build a search engine with Ruby on Rails

#38

Post by NicoJuicy »

Graffur wrote: post #30
gouda-gouda wrote: post #27

Ruby is alive and well. We don’t use Rails specifically (Hanami + ROM.rb + DRY.rb), but absolutely love Ruby as a language and the ecosystem surrounding it. It’s productive, and as powerful as you need it to be. When it comes to building feature-rich web applications quickly and sanely, Ruby is still hard to beat IMO.

Doesn't React beat it quick easily?

Quick... Rails generates front-end and backend with a one line command.

How many components in react would you need to add for 1 crud ?

Re: How to build a search engine with Ruby on Rails

#39

Post by masa331 »

Graffur wrote: post #30
gouda-gouda wrote: post #27

Ruby is alive and well. We don’t use Rails specifically (Hanami + ROM.rb + DRY.rb), but absolutely love Ruby as a language and the ecosystem surrounding it. It’s productive, and as powerful as you need it to be. When it comes to building feature-rich web applications quickly and sanely, Ruby is still hard to beat IMO.

Doesn't React beat it quick easily?

no

Re: How to build a search engine with Ruby on Rails

#40

Post by papaf »

KronisLV wrote: post #36
Mikeb85 wrote: post #23

Earlier quoted context omitted.

Rails doesn't scale? Github's the largest code repository site in the world. Stripe's one of the largest fintech sites in the world. Shopify is one of the largest ecommerce sites in the world. There's also Airbnb, TripAdvisor, many others that are huge. Also, you can write shitty, slow code in any language. You can make too many calls to the DB in any language. You can also scale to Google size in any language. Pytho…

> Rails doesn't scale? Github's the largest code repository site in the world. You know, i think i understand both of the viewpoints here. Personally, i'd say that Rails doesn't scale as well as i'd expect it to. You can definitely build scalable systems in it, though you'll end up throwing a whole bunch of hardware resources, when compared to certain other languages and technology stacks, to serve similar load. For…

it routinely eats up close to 4 GB of RAM, which in my case is an entire VPSes worth and costs me about 60 Euros a year

You are absolutely correct that running other peoples Ruby code is expensive. I would argue similarly for Java because of the high RAM requirements.

However, if you are a company developing your own software, if you use a more productive technology and it spares just 1 programmer then you have paid for a few hundred VMs and running costs become insignificant compared to labour costs.

This is an argument in favour for both Rails and the Java monsters.

Post reply on HN