[deleted]
DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
11–20 of 259 posts
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#12Why is it called Hey stack?
Why does the "Hey stack" persist to the obsolete Mysql dB engine and not PostgreSQL (opinionated dovnvote fodder, I know, but hey; bring it on! They are valid questions).
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#13> - MySQL for DB (Vitess for sharding) Curious why not postgres?
DHH (somewhat surprisingly) said he really has no preference between MySQL and Postgres: https://twitter.com/dhh/status/1275909837793062912
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#14> - MySQL for DB (Vitess for sharding) Curious why not postgres?
Probably in-house expertise and experience running previous services. That usually (or should at least) outweighs feature set in selection process, especially for databases.
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#15Why is it called Hey stack? Why does the "Hey stack" persist to the obsolete Mysql dB engine and not PostgreSQL (opinionated dovnvote fodder, I know, but hey; bring it on! They are valid questions).
[deleted]
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#16Was AWS unavoidable?
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#17What I think is even more significant than Hey’s backend stack is its _frontend_ stack. There’s no complex JavaScript framework; it’s all server side rendered HTML with a few touches of lightweight JS (mostly Turbolinks and StimulusJS, afaik) on the client to add basic interactivity. And it feels just as fast—if not faster—than any other modern, well-built web app.
It goes to show that libraries like React and Vue are _not_ necessary to build smooth, modern, and fully-featured web interfaces.
Edit: removed mention of Angular because, yes, it’s a framework, not a view library.
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#18Why is it called Hey stack? Why does the "Hey stack" persist to the obsolete Mysql dB engine and not PostgreSQL (opinionated dovnvote fodder, I know, but hey; bring it on! They are valid questions).
The app is called "Hey". It's not the HEY Stack in the same sense as the MEAN stack or the LAMP stack. It's the stack for the app called HEY.
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#19Idk,I actually don't understand the obsession of many with Tech Stack or predicting the doom of a language. Because Facebook uses PHP for their service, Would you still use PHP? A lot of people despise PHP. But there's PH maker Mubs, most of his indie products LAMP stack. The main lesson I get from any of these is that pick the one that you're comfortable with and deliver the project than looking for what's the best…
Yeah, selecting a stack IMO has more to do with scoping your goals. For example, if you are an indie dev who will be developing a project solo, pick whatever you're best at, because all that matters is the product. If you're an open source project, that's a different story. If you're looking to hire engineers, also a different game. And if you're the creator of Ruby on Rails and have created a giant personal brand ar…
I'd also say that a lot of people expecting to eventually hire on developers don't have to pick the tech stack that will scale to a 30 developer team. I've known a lot of very successful companies where the core tech was rebuilt/replaced as the team demands grow. And a lot of them probably wouldn't have gotten there that quickly if they make decisions around a 30 person team when they were 2 people.
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#20> - MySQL for DB (Vitess for sharding) Curious why not postgres?
There's something to be said for familiarity - I work in a Postgres shop now, but spent years operating large MySQL clusters in prior jobs. I'm learning Postgres, but still way more intimately familiar with MySQL (and in particular, InnoDB) internals and would probably reach for it for any new project I were architecting on my own.
Major relational databases generally all do the same stuff in similar ways for the 80% use cases, but when you get into the 20% of weird edge cases, operational concerns at scale, and troubleshooting... really knowing the storage engine internals like the back of your hand is useful.