I built my startup 4 years ago with a combination of react + aws + gatsby + hasura. I thought this would be great for performance and scale. Fast forward to today, I spend at least 2x as much time to code a feature than if I had just stuck with a simple rails stack, and the scale I imagined never happened. Now rebuilding everything with rails so I can ship faster and focus on growing the product, not making engineering prowesses.
Building GitHub with Ruby on Rails
61–70 of 332 posts
Re: Building GitHub with Ruby on Rails
#62Earlier quoted context omitted.
I have yet to see a tech stack that's not locked up into a framework version. That's more because of our engineering culture. The cost of NOT upgrading outweighs by a huge margin than keeping building on top. And yes, have seen Django shops locked into 0.9x release patched right into the core and running for a very long time, impossible to upgrade and all the horror stories. EDIT: Added Django
As a counterpoint I have yet to see one that is locked in my 15 years working with Rails.
I have customers with a mix of small Rails projects in version 6 or 7. I told one this week that we could use AR's encrypts :field to encrypt some fields in the database, but that project is Rails 6 and that feature is added by Rails 7. We could add the code to handle it because it's small, but customer decided not to encrypt the field and wait until (if!) the project moves to Rails 7.
Re: Building GitHub with Ruby on Rails
#63Github is one of the few webapps where I can feel daily that the framework used isn't enough. So many things get out of sync/not up to date, which are fixed by refreshing the page.
I feel the same with Gitlab, with e.g. build pipeline status not updating when it's done - it feels pull- instead of push-based.
I mean it may be working just fine, but I don't see it - and the success rate of refreshing a page to see an update is so high that it doesn't instill confidence.
These tools should be more reactive, I think, with live progress indicators and the like.
Re: Building GitHub with Ruby on Rails
#64Earlier quoted context omitted.
I imagine it wouldn't be too hard, since Django only has one dependency - Django itself (NodeJS developers weep). Is rails the same way dependency wise?
That's not correct. Django isn't independent, depends on lot many packages but that's not the issue. Issue is the frameworks own Interface: Existing Interface getting removed OR behavior or defaults changing for an already existing Interface. That's usually the upgrades are about.
> Django isn't independent, depends on lot many packages
It is quite independent. There are between two and four dependencies: asgiref, sqlparse, tzdata on Windows only [0], and typing_extensions on [0] https://github.com/django/django/blob/main/setup.cfg#L39-L42 [1] https://github.com/django/asgiref/blob/main/setup.cfg#L34-L3...
Re: Building GitHub with Ruby on Rails
#65> scheduled GitHub Action workflow
..sounds like they're not dogfooding dependabot? curious if anybody knows more/why
Re: Building GitHub with Ruby on Rails
#66Earlier quoted context omitted.
I have yet to see a tech stack that's not locked up into a framework version. That's more because of our engineering culture. The cost of NOT upgrading outweighs by a huge margin than keeping building on top. And yes, have seen Django shops locked into 0.9x release patched right into the core and running for a very long time, impossible to upgrade and all the horror stories. EDIT: Added Django
As a counterpoint I have yet to see one that is locked in my 15 years working with Rails.
You have worked on a few projects that were behind a few major versions and needed considerable effort to be updated :)
Re: Building GitHub with Ruby on Rails
#67I built my startup 4 years ago with a combination of react + aws + gatsby + hasura. I thought this would be great for performance and scale. Fast forward to today, I spend at least 2x as much time to code a feature than if I had just stuck with a simple rails stack, and the scale I imagined never happened. Now rebuilding everything with rails so I can ship faster and focus on growing the product, not making engineeri…
Considering most of the times the startup at hand will fail anyway and the planned scale will not happen, building the initial architecture to be "web scale" is a perfect example of YAGNI.
I had a similar experience, and it was a great lesson.
Re: Building GitHub with Ruby on Rails
#68Earlier quoted context omitted.
On the contrary, it is so much easier to upgrade a small app every week or so because you have little to test and probability of breaking changes affecting you is minimal. You should be upgrading all the time since day one, adding necessary infrastructure gradually as your app grows.
Absolutely. I was leading a team a while ago and I instituted this practice to good effect. Conversely, I was called by a company that I had built an app for previously. They had not upgraded the framework it was built with (Laravel), and ended up offering me consulting days to jump several versions. The irony is that the job ended up being quick and easy to do.
Laravel is relatively painless to upgrade as long as you have the autonomy to get the work done in a timely manner. I've seen upgrade projects drag on for weeks causing issues upstream since most of the team was still working on the product or fixing bugs while one developer was tasked with the upgrade.
Did you use a tool like Shift to help with the upgrade? What about frontend dependencies? The recent move from Mix to Vite is great, but if you have a large frontend, it can be a major PITA to update. More so if you have any sort of custom webpack configuration.
Re: Building GitHub with Ruby on Rails
#69[flagged]
> As someone who has experience working with large codebases, I am thoroughly impressed by GitHub's approach to upgrading their Ruby on Rails monolith. It is clear that the GitHub team has invested a significant amount of time and resources to ensure that their application runs on the latest version of Rails and Ruby, and this has resulted in real tangible benefits such as better database connection handling, faster view rendering, and improved security posture.
To be fair, they did spend years not adding features. (Only really starting to add features when the Dear GitHub letter came out) It seems like they spent that time wisely just investing in stuff like this. GitHub are in a unique position where they spent so long ignoring features while having a large team. I feel like for the majority of teams these sort of investments are rarely possible because feature work is required.
Re: Building GitHub with Ruby on Rails
#70Good post and an interesting glimpse into the behind-the-scenes efforts that goes into maintaining Github. I cannot agree with the "Should I do it too?" section. It probably works very well for an org as large and dedicated as Github, it very likely makes a lot of sense for what they do at the scale they do it at. For most of us that are consumers of technologies and frameworks, treating the framework as an extension…
> and that is not our core business, nor should it be
And that's problem. Tech is an integral part of most businesses now. Chances are if there's an outage you'll lose customers. It's a core part of your business - possibly 1 of the most important.
Often the #1 reason why something can't be done is that the tech behind it doesn't support it.