Live data from Hacker News

Building GitHub with Ruby on Rails

github.blog

191–200 of 332 posts

Re: Building GitHub with Ruby on Rails

#192
post #83

Earlier quoted context omitted.

JS is not only for frontend anymore. Alas.

Yea and new backend frameworks pop up every day. Wait, they don't. They were clearly talking about frontend frameworks.

Unsure why you were downvoted, you're almost certainly correct.

Re: Building GitHub with Ruby on Rails

#193
post #141

Earlier quoted context omitted.

I agree with this, but that seems to be a problem with Github's frontend code, not their server code. I don't think that detracts from this blog post's message.

I guess my implied question should be stated more explicitly: is GitHub's front end code entirely separate fro the Rails code? That's not how Rails apps usually work, I thought. Admittedly, it's been a long time since I looked at Rails code, and I don't have the slightest idea how GitHub is actually architected. But I don't remember the "front end code" in Rails being a separate thing from the server code, typically:…

It seems that they are using React https://twitter.com/rauchg/status/1591464351990697984?s=46&t...

Re: Building GitHub with Ruby on Rails

#194
post #47

Earlier quoted context omitted.

Very true, but that's a frontend problem, not a rails problem.

These problems are always more common in server-rendered apps though, because front-end state is always a patchwork. And the Rails developers and community have a strong preference for this architecture.

Mind you some parts of Github FE are React https://twitter.com/rauchg/status/1591464351990697984?s=46&t...

Re: Building GitHub with Ruby on Rails

#195
I'm curious what their data access layer looks like underneath that monolith. Is the Rails piece mostly now just a frontend for dozens of other services, properly owned and maintained by other teams? I don't mean to trivialize something that's obviously huge and complex as "just a frontend", but IME one of the biggest things that breaks down in a Rails monolith as it scales is heavy, direct usage of ActiveRecord. Either there's lots of DB migrations happening since there's so many different developers working on different features, which makes development with a shared DB tricky, or the scale makes DB performance problems hard to diagnose since they cut across many teams or tables in complicated ways.

Re: Building GitHub with Ruby on Rails

#196
post #3

I absolutely love Rails. I'll always remember back in 2010 catching the train to Waterloo station in London and seeing a huge sign overlooking the train tracks that read something like "We Need Rails Developers". Rails was such a huge part of my professional career. Now, 13 years later and I'm deep in the JavaScript ecosystem and have been for 8 years. The most exciting thing to come out of this ecosystem recently is…

I started my professional career with Rails 8 years ago and deeply miss aspects of it. It uses lines of code so efficiently, letting you go from zero to product with outrageous speed. Everything is a solved problem. Ruby as a language is so expressive, so beautifully ergonomic, so easy to read. It's such a joy.

But the view layer has not aged well. After years of working with a focus on React and TypeScript, I can't stomach the Rails approach to views. As much as I appreciate the value proposition of Stimulus and truly feel the shortcomings of SPAs deep in my bones, I crave components, type safety, unidirectional data flow, and more options for styling than just classes. React in particular has rich options for UI frameworks that feel truly idiomatic. The last time I tried to start a project with Rails, I moved at a breakneck pace until I got to the view layer, at which point I had to pull the plug.

I'm reaching for Next.js these days because it's the closest I can get. It gives me the opinionated framework I crave plus server rendering and the ability to drop down into client-side rendering when it calls for it. Prisma is a damn good ORM, even if it doesn't have the intuitively ergonomic beauty of ActiveRecord. And of course, TypeScript throughout is a godsend.

But I still miss Rails. I miss the console, Sidekiq, the profound power of ActiveRecord for simple things with the ease of dropping back into SQL when I need it, the polish of FactoryBot and those easy easy easy tests. I miss the breezy and fluid syntax of Ruby. I don't feel limited by TypeScript, I love working with it, but TypeScript lets me lecture, Ruby lets me sing.

Re: Building GitHub with Ruby on Rails

#197

> Every Monday a scheduled GitHub Action workflow triggers an automated pull request, which bumps our Rails version to the latest commit on the Rails main branch for that day. That’s a bold move to do as opposed to being end of week or weekend.

I sure don’t want to be called on Saturday to be told that there’s something wrong with Friday’s build.

I’m sure paying customers don’t want outages during their prime usage days.

Re: Building GitHub with Ruby on Rails

#198

I'm curious what their data access layer looks like underneath that monolith. Is the Rails piece mostly now just a frontend for dozens of other services, properly owned and maintained by other teams? I don't mean to trivialize something that's obviously huge and complex as "just a frontend", but IME one of the biggest things that breaks down in a Rails monolith as it scales is heavy, direct usage of ActiveRecord. Eit…

I've heard this several times over the last few months. Like what makes several devs working in the same area of the code "hard"? In my experience whomever is lucky enough to commit first gets the easiest of it, everyone else just rebases and resolves their conflicts. Maybe if you don't rebase and merge instead? I've seen some screwed up stuff happen from bad merges... like entire lines of code vanish.

But generally, I've worked with hundreds of devs in the same code base without issue. So, why do people ask this?

Re: Building GitHub with Ruby on Rails

#199
And as I have said before but worth repeating again, Rails is perhaps the only open source framework that is being battle tested in development at scale. It may not be the fastest ( or in fact quite slow ), but I dont think you could find similar testing being done and Deployed at the scale of Github on any other framework.

I wonder if Eileen Uchitelle will bring this practice to Shopify as well? Edit: It seems [1] Shopify is also running on latest Ruby and Rails version as well.

[1] https://news.ycombinator.com/item?id=35481352

Re: Building GitHub with Ruby on Rails

#200
post #199

And as I have said before but worth repeating again, Rails is perhaps the only open source framework that is being battle tested in development at scale. It may not be the fastest ( or in fact quite slow ), but I dont think you could find similar testing being done and Deployed at the scale of Github on any other framework. I wonder if Eileen Uchitelle will bring this practice to Shopify as well? Edit: It seems [1] S…

Yes, we’ve been doing this at Shopify for quite a while now.
Post reply on HN