Mongo, normalization/denormalization and Elastic search

help
1

Hello,

so we were again discussing our data model for e-commerce app.
Problem was that we had some data per product, but than many relations pointing to other products, similar products etc.
It does not felt very good to copy most of user facing data accessories[] and variants[] arrays and keep them consistent all the time.
Especially when our prices need to change a lot as a response to outer inputs.

Than we identified that for every product we want to have relations based on variant to variant basis and querying such thing become nightmare.

Now we are considering that most of our data we would keep normalized and mongo will be used as data store to keep them consistent.
And most of views etc will be generated using ElasticSearch outputs where we want to utilize parent-child relationships.
Subscription updates sounds kinda counterproductive anyway, as you dont want to shuffle items in user view while he is trying to click it.
And some live graphs etc could be done responsive way, but that is admin interface stuff and other story.

Any1 else went this way and have some hints?
Or we will hit some hidden wall which we do not see now ?

2

Meteor doesn’t provide any control over the way the local database is updated. Also, Meteor does not allow you to change the local database, for example to add a local-only field to documents (useful for UI states).
To solve those issues, I use the following pattern: a local-only collections that mirrors a standard collection using observeChanges. It perfectly solves issue 2 and helps somehow for issue 1.

3

Well, we dont have much state in there other than route and few objects can be kept in ReactiveDict to prevent hot push messing view.
Same as reactive:false for data context as we dont need to change info presented to user.
Route changes are easy to detect, same with routeSearchParams which enable us to switch between product variants wiithout actually changing route and re-rendering only template helpers which watch for changes in template level ReactiveVars (and these are updated using template.autorun watching routeParams/routeSearchParams). :smiley: Sounds simple haha