Skip to content
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

InstantSearch migration #706

Draft
wants to merge 30 commits into
base: master
Choose a base branch
from
Draft

InstantSearch migration #706

wants to merge 30 commits into from

Conversation

royduin
Copy link
Member

@royduin royduin commented Jan 15, 2025

ReactiveSearch is within Rapidez from day 1, but the current status is unclear and there isn't much activity on Github. We choose this as Magento requires Elasticsearch / OpenSearch, so no additional requirements.

In the past we've worked with InstantSearch from Algolia which supports more search engines which is a good alternative and it integrates with multiple search engines:

With this migration; we could migrate to Laravel Scout so we can get rid of our custom indexer, use a first party Laravel package, get batch imports out-of-the-box and more advantages. Laravel Scout also supports multiple search engines; Algolia, Meilisearch and Typesense out-of-the-box. There are some custom drivers for Elasticsearch:

This current proof of concept is using Meilisearch, but I'm not yet convinced as locally (on a M1) I can't get it faster than 300ms where Elasticsearch responds within 50ms. Not sure yet how easy it is to switch between engines; maybe it will be configurable with Elasticsearch as default; so you can use the same infrastructure.

To be continued 🚀

Oh and yes; we're also going to migrate to Vue 3; but after this within a separated PR.


Update: Switched to Elasticsearch using Searchkit. Performance is back to what we're used to and within the core (but also within some projects) custom query DSL is used; so sticking to Elasticsearch is preferred.

src/Models/Product.php Outdated Show resolved Hide resolved
Comment on lines +51 to +54
// TODO: Not sure if this is the right place,
// the autocomplete also needs this but
// we don't want to load everything
// directly due the JS size
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest creating another js file with exports to import in the listing and autocomplete for the basic functionality needed everywhere.

If you look at the current situation we also have a similar file for the base of reactivesearch.

If you open the autocomplete you'll see it also downloads a "Container" js file
image

This also happens when you open a category page:
image

Vite will automatically recognise and create a separate bundle if it notices multiple other bundles require it.

Comment on lines +25 to +28
TODO: Double check this, the data updates,
but the component doesn't. Tried to
make everything working recursive
plus keep it renderless.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This usually is solved by adding a :key that will change depending on the data so the element is forcibly rerendered: https://vuejs.org/api/built-in-special-attributes#key

// will be used resulting in all attrs.

// Customize the data array...
// cast to the correct types! (int), etc
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Casting to the correct types should already be handled by the $casts right?

I do agree that it might be a good idea to pass the data through an eventy filter(?) so it can be changed as desired.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants