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

DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search

m.twitter.com

Post reply on HN
Print view View original

201–210 of 259 posts

Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search

#201

Post by brobinson »

Kiro wrote: post #167
brobinson wrote: post #120

Earlier quoted context omitted.

I don't know if I could go back to not having transactional DDL, partial and function-defined indexes, non-blocking ("concurrent") indexing, and so on...

What do you build that requires those things?

I've used them (via Postgres) to build large database-backed web applications (like Hey), realtime bidding systems (100mm+ records, 250,000+ requests/sec), and so on over the last 10+ years. Recursive CTEs as well, and MySQL finally has those as of a year or two ago. The feature gap is closing, but it's been a very, very slow process.

Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search

#202

Post by [deleted] »

ChefboyOG wrote: post #7
amrrs wrote: post #4

Idk,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…

[deleted]

Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search

#203

Post by meritt »

brobinson wrote: post #120
meritt wrote: post #51

Earlier quoted context omitted.

MySQL 8 is very solid and has resolved the vast majority of the gripes of the past. Postgres is, as always, amazing software, but MySQL is no longer the choice to be shunned.

I don't know if I could go back to not having transactional DDL, partial and function-defined indexes, non-blocking ("concurrent") indexing, and so on...

I'm not sure where I suggested "Hey, long time Postgres users, you should switch to MySQL!". The point is it's a solid modern database and a completely fine option in 2020.

MySQL8 supports functional indexes and concurrent indexing fyi. It still does not have transactional DDL nor partial indexes.

Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search

#204

Post by ksec »

dmlittle wrote: post #28
diminish wrote: post #6

> - MySQL for DB (Vitess for sharding) Curious why not postgres?

They probably use MySQL for Basecamp and it's worked for them so they're also using it for Hey (same team developing both). As for Vitess it makes sense since it's made to work nice with Kubernetes (which they are using). I don't know of a Postgres equivalent.

Is there a Vitess for Postgres?

Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search

#205

Post by gyanamo »

mtmail wrote: post #10
gyanamo wrote: post #2

isn't "Vanilla Ruby on Rails" akin to "Vanilla Deluxe Chocolate Fudge Sundae"?

https://en.wikipedia.org/wiki/Vanilla_software "when not customized from their original form, meaning that they are used without any customizations or updates applied to them"

I was actually being serious. I've never seen anyone refer to a customized RoR, have you?

Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search

#206

Post by frandroid »

piazz wrote: post #65

Noteworthy how they tout the success of their "magic" frontend stack made with vanilla JS, lack of a trendy framework, etc. But if you use the app, the UX is fairly laggy, requires frequent refreshes, all the animations and interactions are off - the list goes on and on. It's noticeably subpar (and I like Hey). Seems to me that the proof is in the pudding wrt their stack, but it's probably not what they wanted to pro…

What I find amusing is that all of today's SPA frameworks/views are kind of descended from Angular, which Google built internally after learning the lessons of how to build such a thing while putting the Gmail front-end together. We 15 years of SPA usage in email applications demonstrating their superiority. We have things like Facebook, the one true SPA which rules them all. And yet. Turbolinks.

(And I say that as a big RoR fan!)

Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search

#207

Post by maps7 »

piazz wrote: post #65

Noteworthy how they tout the success of their "magic" frontend stack made with vanilla JS, lack of a trendy framework, etc. But if you use the app, the UX is fairly laggy, requires frequent refreshes, all the animations and interactions are off - the list goes on and on. It's noticeably subpar (and I like Hey). Seems to me that the proof is in the pudding wrt their stack, but it's probably not what they wanted to pro…

I've been using it for the last few days and I don't have this experience. It's better than Outlook (web or desktop), hotmail, yahoo, gmail and other email services I have tried.

Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search

#208

Post by ksec »

meritt wrote: post #51
diminish wrote: post #6

> - MySQL for DB (Vitess for sharding) Curious why not postgres?

MySQL 8 is very solid and has resolved the vast majority of the gripes of the past. Postgres is, as always, amazing software, but MySQL is no longer the choice to be shunned.

Is there a MySQL Roadmap somewhere? I cant seems to google anything up. Compared to Postgres which seems have way more information.

And Postgres still hasn't caught up to MySQL in multi / clustering solution. Or may be they dont ever intend to focus on it and leave it to third party.

Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search

#209

Post by johannes1234321 »

Aduket wrote: post #198
learc83 wrote: post #186

dang was this flagged for some reason? It seemed to be pushed off the front page really fast.

OP here. indeed, it was at the top of the front page for having the highest vote. Now it was sent the second page. Weird, why could this be?

Happens with different posts regarding Basecamp/dhh ... but who knows

Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search

#210

Post by whoisjuan »

karmakaze wrote: post #199
whoisjuan wrote: post #111

Earlier quoted context omitted.

They are using Turbolinks. They generate everything server-side and then Turbolinks calculates the delta between the existing loaded template in the client and the incoming template generated in the server and injects only the changes. This has a lot of advantages, mainly that you don't need to care about state on the client side and you're always synced with the real estate on the backend. It has one major drawback…

Where is the "existing loaded template" kept server-side, sticky session cache? Seems maybe better for scale to send the whole small html and let client diff-apply.

In theory the server doesn’t care about this because the idea is that you’re requesting something that is generating a complete new template. What turbolinks does is looking at the difference between whatever you have loaded in the browser and whatever was sent by the server.

So if you have 10 images loaded and one changed, turbolinks it’s only going to swap the one that changed.

Have in mind that we are talking about plain HTML likely gzipped blobs. So although this is not efficient it’s still fast enough for simple app layouts.

Post reply on HN