gregmfoster

Thanks for writing this up! I really enjoyed the comparison. My team is considering moving some of our data to elastisearch out of postgres, and this analysis helps confirm some of our thoughts.

To me, the critical points here are:

PostgreSQL has a single master and multiple read replicas, Elasticsearch has horizontal scalability via sharding.

if you have a large data set search and search relevancy is critical to your application (for example, in e-commerce), using a dedicated search engine like Elasticsearch is going to perform better

I love the mentality of "default to using Postgres for everything, and specialize when you need to." In this case, it looks like you'll need to evolve text search out of Postgres the moment your dataset gets into the millions, which roughly matches my experience.

I love the idea of more book-focused social networks! Curious what the motivation here is to make it federated, instead of focusing on high-velocity user-focused product development. My greatest gripes with existing book-social-media-networks aren't the federation, but rather the dated UX.

I'm curious how much people prefer TUIs over editor-plugin-GUIs these days. I'm getting more and more persuaded by the plugin model personally - perhaps partly by how easy it is to discover, install, update, uninstall, etc VSCode plugins

I imagine this would be brutally hard for guitar - so often, my fingers are "touching" the correct strings, but not pushing down hard enough to trigger the note. Piano might be more feasible because you can watch the motion of the keys themselves.

Question - what is your root goal? Are you convinced video processing is the best way to achieve this?

yeah, it's really interesting, I've seen this confusion before

Congrats on the launch! How are you thinking about building an open-source company vs a closed-source?

why

nah, not real, I was just being silly :)

FWIW, graphite.dev's MQ supports GitHub Enterprise Server

If a merge queue is light and fast, all repos could benefit from having it enabled by default

Seeing 421 on our AWS amplify splash page as well

This comment seems off topic?

I wonder if folks can trade in dev kits for the first version when it's released next year. That was the case for me with the Apple TV dev kit.

We're seeing this from graphite.dev's API calls to GitHub

Sounds like have some really thoughtful opinions regarding code review tools!

"Being able to comment on character-level granularity is cool!" This is something that I really like too - I'd go so far as to say PR titles, file names, etc, nearly everything should be commentable.

Have you checked out graphite.dev? Its iterating rapidly and incorporating a lot of what Phabricator and Gerrit did well.

Proud to be working with friends to improve the world of dev tools. There's a massive community of engineers on Slack who have been beyond generous with feedback, bug reports, and motivating messages. Makes grinding hard on Graphite meaningful :)

graphite.dev (alternative frontend to github code review) still up, it appears to be just their frontend.

Love to see the manually updated status page not updating

Down for us (graphite.dev) as well, running on us-west-2

Im a fan of keeping my git branches clean locally (only having a couple active branches) and aggressively deleting merged/abandoned ones, though I know that this can be contentious

Thank you! All thanks to Xiulung Choy's hard work

What is your thinking around post merge reviews?

Neither GitHub nor GitLab quite hit the mark for me with regards to code review. Phabricator (RIP) was close IMO, with first class support for (1) seeing comments and code on one view and (2) supporting stacks which prevent mega changes.

I've been working with some peers on a better code review tool since hearing about Phabricator shutting down: https://graphite.dev/

It syncs all data to GitHub while offering things like a review queue, gif reactions, stacked diffs, etc - all inspired from Phabricator.

++ stacked changes workflow. @tomasreimers made me a convert after debating traditional github workflows for a year