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

211–220 of 259 posts

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

#211

Post by jedieaston »

jimnotgym wrote: post #177

Am I misreading something, or can you only use a *@hey.com address and not your own domain? So if Hey lock you out you potentially lose access to all of the accounts you set up using that address. PayPal can't send their 1 time code, your bank can't reset your login. Your password manager can't do 2fa. If you own the domain you can switch there dns to someone else and regain your life. If you don't own the domain to…

Custom domains are apparently in testing right now (i'm on a list to hear back about it). The corporate version requires them.

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

#212

Post by jedieaston »

gregkerzhner wrote: post #96
mkchoi212 wrote: post #74

It uses ElasticSearch? Does this mean that HEY only supports searching when the device is online? I would expect search to work on a mobile app with no internet access when I'm paying $100 for an email service...

I assume this is their web stack. For their mobile apps they most likely use native iOS / Android codebases. The typical stack for a data heavy native app is to use an SQL store (or just filesystem) to cache data locally so its available offline. You won't obviously be able to search all of your emails offline though, only your most recent ones that happened to be loaded during online usage.

They don't, it's all online with webviews on iOS and Android. I don't think there is offline functionality (still haven't gotten an invite).

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

#213

Post by alecdotninja »

ksec wrote: post #197
latortuga wrote: post #103

Earlier quoted context omitted.

Interesting note, on Twitter DHH mentioned that they have some additional "magic" that they're using to do frontend work. It sounds like HTML over websockets, not unlike Phoenix LiveView or (tooting my own horn here) our recently released Motion library ( https://github.com/unabridged/motion ) which both allow you to use the server as your single source of truth while providing reactive UI components on the frontend.…

>Motion library Nice, this is much closer to LiveView than Stimulus Reflex. Will check it out when I have time. Slightly off topic: >Github's ViewComponent is currently the de-facto standard for component/presenter-style libraries for use with Rails and likely will make it into Rails eventually. I thought DHH rejected the idea? https://github.com/rails/rails/pull/36388

> I thought DHH rejected the idea?

I can't speak for DHH, and I don't see anywhere that he commented in the PR. My read of the thread is that there are open questions about the best way to structure this abstraction, so the minimal interface to allow for clean community experimentation has been stabilized in the meantime.

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

#214

Post by rsanheim »

diminish wrote: post #6

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

Basecamp (and 37 Signals) has been a MySQL shop forever, so I'm sure they have a ton of operational experience with it. There is no reason for them to switch to Postgres at this point, for much of the same reasons a place like GitHub is still on MySQL.

Changing database engines with large, established apps has a _huge_ cost and is usually not worth it.

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

#215

Post by sarchertech »

gyanamo wrote: post #205
mtmail wrote: post #10

Earlier quoted context omitted.

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?

Some large companies have customized rails, and since Hey is built by the company behind rails, I assume DHH meant to imply that they are not using something special that everyone else won’t get access to.

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

#217

Post by rsanheim »

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…

The UI performance feels snappy to me, and opening up threads or going to commonly used pages feels about as fast as Gmail. From watching the performance w/ network tab open things happen in around 300 - 500 ms, which is inline w/ Gmail as well.

_Opening_ app.hey.com is a different story, and is far faster than opening a tab to gmail. I often wait for Gmail while staring at a blank tab as it loads, even one a fast broadband connection. Using Gmail over spotty broadbad, say while traveling, often leads to dropping down into "simple HTML mode".

Hey loads up very, very quickly, which isn't surprising given how small the bundle of html/js/css you are pulling down is.

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

#218

Post by gyanamo »

sarchertech wrote: post #215
gyanamo wrote: post #205

Earlier quoted context omitted.

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

Some large companies have customized rails, and since Hey is built by the company behind rails, I assume DHH meant to imply that they are not using something special that everyone else won’t get access to.

ah, didn't know that. appreciate the response

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

#219

Post by meritt »

ksec wrote: post #208
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.

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.

Not that I'm aware of no. While the end product is released open-source, the development cycle itself is very much closed-source and there are very valid concerns about MySQL being owned by Oracle. MariaDB is a fully open-source alternative though I'd argue MySQL8 has surpassed MariaDB in terms of quality and features.

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

#220

Post by dmlittle »

ksec wrote: post #204
dmlittle wrote: post #28

Earlier quoted context omitted.

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?

Looking at Vitess' roadmap[1] it's in their medium term roadmap but I'm not aware of any other project that currently support Postgres.

[1] https://vitess.io/docs/resources/roadmap/

Post reply on HN