New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
✂️ Remove search from Connect #13235
Conversation
| [current_user.id] | ||
| end | ||
|
|
||
| result = Search::Postgres::ChatChannelMembership.search_documents( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You'll notice I left everything in the Search namespace (the route, the controller, and the service naming). I originally started removing chat_channels from search all together since this behaves more like a filter than a search.
However, I discovered there are some JS components that are using this endpoint as an "index". I started refactoring everything, but it quickly got out of hand and out of scope for what this PR is intended to address. I also realized it may actually be nice to leave everything in the search namespace so that when we re-do the search for Connect in the future, it's a smoother experience.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I started refactoring everything, but it quickly got out of hand and out of scope for what this PR is intended to address.
👍 good call taking the simpler approach in this PR
With that said, since we have the ChatChannelsController and the ChatChannelMembershipsController each with index actions, I think the right move would be to move those JS components to them so we don't have multiple controllers performing the same actions. I also am always hesitant to leave code around with the idea we might use it. What do you think about making an Issue for it once this is merged so someone else can tackle the refactor at some point?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#13277 🚀
| <input | ||
| placeholder="Search Channels" | ||
| onKeyUp={this.debouncedChannelFilter} | ||
| id="chatchannelsearchbar" | ||
| className="crayons-textfield" | ||
| aria-label="Search Channels" | ||
| /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing the search box from the UX 🎉
| @@ -118,7 +118,6 @@ export const createDataHash = (additionalFilters, searchParams) => { | |||
| } | |||
| dataHash.per_page = 30; | |||
| dataHash.page = searchParams.paginationNumber; | |||
| dataHash.channel_text = searchParams.query; | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't search by any terms anymore.
| attributes :id, :status, :viewable_by, :chat_channel_id, :last_opened_at, | ||
| :channel_text, :channel_last_message_at, :channel_status, | ||
| :channel_status, :channel_type, :channel_username, :channel_name, | ||
| :channel_image, :channel_modified_slug, :channel_discoverable, :channel_messages_count | ||
| :channel_type, :channel_username, :channel_name, :channel_image, | ||
| :channel_modified_slug, :channel_discoverable, | ||
| :channel_messages_count |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:channel_status was originally duplicated and I cleaned up the spacing/formatting a little bit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pulled down the branch, clicked around and everything looks good!
| [current_user.id] | ||
| end | ||
|
|
||
| result = Search::Postgres::ChatChannelMembership.search_documents( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I started refactoring everything, but it quickly got out of hand and out of scope for what this PR is intended to address.
👍 good call taking the simpler approach in this PR
With that said, since we have the ChatChannelsController and the ChatChannelMembershipsController each with index actions, I think the right move would be to move those JS components to them so we don't have multiple controllers performing the same actions. I also am always hesitant to leave code around with the idea we might use it. What do you think about making an Issue for it once this is merged so someone else can tackle the refactor at some point?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had a whole in-depth performance analysis written here and then GitHub was like "there was a problem submitting your review" and then threw it all away 😡
This was the TL;DR (too long; damn sure ain't rewriting):
- We're getting what looks like N+1 queries
- I think it's due to ActiveRecord's back-and-forth traversal of the associations
- I tried adding a bunch of
inverse_ofclauses to the associations to see if I could get it to go away and it wasn't working - Honestly, posting the queries is probably what broke submitting the review 😢
- Stats on a prod DEV snapshot:
- p50 = 8ms
- p95 = 136ms
- p99 = 395ms
- CCM stats:
- Only 15% of users have any CCMs at all
- 9.2% of users have > 5
- 0.4% of users have >= 10
If we can fix the N+1 queries trivially, that would be fantastic, but if not I'm not super concerned.
My personal feeling here is that we shouldn't announce this to the community to avoid getting more eyes on a part of the product that is going to likely be removed or at least is a bit in flux right now. Folks already don't really use Connect all that much (based on statistics that we've pulled in the past at least), so telling them about changes there will likely just drive people to look at it (and since this is removing functionality, getting user's eyes on it kind of feels like a moot point). That's just my personal opinion though, maybe Product folks will disagree with me 🤷🏽♀️ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good @atsmith813. If you can fix the problems @jgaskins mentions that'd be great but given the somewhat unclear future of Connect and its low usage I'd probably timebox the effort and just live with it if we can't find a solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with the idea! Thanks for following through with the idea!
One thing I'm not sure I understand: why are we adding code for Search::Postgres::ChatChannel if we are removing the search from the UI?
Isn't it redudant? I understand leaving the ES code in, but why are we adding the PostgreSQL version as well?
Thank you!
|
I left everything in the Search namespace (the route, the controller, and the service naming). I originally started removing However, I discovered there are some JS components that are using this endpoint as an "index". I started refactoring everything, but it quickly got out of hand and out of scope for what this PR is intended to address. I also realized it may actually be nice to leave everything in the search namespace so that when we re-do the search for Connect in the future, it's a smoother experience. |
|
@vaidehijoshi - great call WRT communicating this change! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah got it, sorry, I always get confused as we overload the term "search" with "search and filter" :D So Search::Postgres::ChatChannelMembership is only a "filter" :-)
😭 that's brutal! How did you investigate this? My first thought would be to hop in a prod console and run the same exact Active Record query, but I don't have access. I played around with it locally, no luck yet. Maybe the |
|
@atsmith813 I pulled a prod snapshot to benchmark changes against locally. At some point I'd like to set up something that lets all Forem devs pull sanitized prod snapshots (all PII overwritten with data from |
|
Mostly when I'm checking that stuff I'm just trying to make sure it's not going to put an unreasonable amount of pressure on the DB — hot endpoints should be pretty quick but infrequently used endpoints can be a little slow, as a treat. |
What type of PR is this? (check all applicable)
Description
This PR is part of the migration process from Elasticsearch to PostgreSQL FTS. TLDR - this PR removes search from Connect.
We started by exploring replacing Elasticsearch with PostgreSQL FTS for Connect. In doing so, we learned a few things and decided it would be better to scrap search within Connect all together, for now (the idea of removing search from Connect has product sign-off already).
ChatChannelMembership,ChatChannel,Message, andUser.I'm leaving all the Elasticsearch code for Connect in place for now. We'll remove it at the end in the PR where we take out everything Elasticsearch related.
Before

After

Related Tickets & Documents
RFC 0153: https://github.com/forem/rfcs/pull/153
https://github.com/orgs/forem/projects/29#card-57639173
QA Instructions, Screenshots, Recordings
Admittedly, testing Connect in development isn't the smoothest 😅 . Here's what I did:
bin/startup).admin_mcadmin).Added tests?
[Forem core team only] How will this change be communicated?
I'm not sure how best to communicate this change and need help - Do we need to include this change in a changelog post or announce this to the community in any way?