Best practice for syncing multiple redux stores
up vote
1
down vote
favorite
We have an application that been managed across multiple teams, we would like to create the flexibility and isolation between the apps by using micro frontend approach, each application will have its own store.
some of the apps are using the same data, we would like to reduce the number of duplicate data been fetch from the server.
I know that it sounds like we should use a single store in that case, but the chose all ready to use multiple stores.
What and how should be the best way to sync data between the stores?
Few points:
- All data have been fetch from our backend services
- The data structure is the same, but not all apps using the same data, some using subset of the datam
- Inorder to reduce the duplication of API calls we would like that "small stores" will be able to sync the data from the "main" store
reactjs redux redux-store micro-frontend
asked Nov 18 at 10:09
USer22999299
1,48722252
add a comment |
up vote
1
down vote
favorite
We have an application that been managed across multiple teams, we would like to create the flexibility and isolation between the apps by using micro frontend approach, each application will have its own store.
some of the apps are using the same data, we would like to reduce the number of duplicate data been fetch from the server.
I know that it sounds like we should use a single store in that case, but the chose all ready to use multiple stores.
What and how should be the best way to sync data between the stores?
Few points:
- All data have been fetch from our backend services
- The data structure is the same, but not all apps using the same data, some using subset of the datam
- Inorder to reduce the duplication of API calls we would like that "small stores" will be able to sync the data from the "main" store
reactjs redux redux-store micro-frontend
asked Nov 18 at 10:09
USer22999299
1,48722252
1
The question isn't specific enough. It's unknown whether data structures are the same. It's unknown how data is handled. If I know that it sounds like we should use a single store in that case, but the chose all ready to use multiple stores. - a good thing about apps is that they can be refactored to solve design problems.
– estus
Nov 18 at 11:11
@estus thank you for the comment, regarding the refactoring point - will add the relevant info. currently, we are not able to do so. its to expensive
– USer22999299
Nov 18 at 12:05
Possibly a middleware that will listen for changes in one store and dispatch updates to another one. This will be hacky and possibly expensive too. But again, this totally depends on specific case. If it's initial data that needs to be synced, that's one thing. If data changes with time, that's another thing. The question will likely be closed any way. I suppose that you've been on SO long enough to see that such broad questions cannot get constructive answers.
– estus
Nov 18 at 12:08
The data structure is the same, but not all apps using the same data, some using subset of the data - yes, this looks like a good use case for single store.
– estus
Nov 18 at 12:12
@estus that's true if i'm waving back to my question - that's the case, i need to sync between multiple stores - looking for the best solution. currently the refactoring of the app will take to much time to have a single store. if we had the time - we would do it.
– USer22999299
Nov 18 at 15:08
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
We have an application that been managed across multiple teams, we would like to create the flexibility and isolation between the apps by using micro frontend approach, each application will have its own store.
some of the apps are using the same data, we would like to reduce the number of duplicate data been fetch from the server.
I know that it sounds like we should use a single store in that case, but the chose all ready to use multiple stores.
What and how should be the best way to sync data between the stores?
Few points:
- All data have been fetch from our backend services
- The data structure is the same, but not all apps using the same data, some using subset of the datam
- Inorder to reduce the duplication of API calls we would like that "small stores" will be able to sync the data from the "main" store
reactjs redux redux-store micro-frontend
asked Nov 18 at 10:09
USer22999299
1,48722252
We have an application that been managed across multiple teams, we would like to create the flexibility and isolation between the apps by using micro frontend approach, each application will have its own store.
some of the apps are using the same data, we would like to reduce the number of duplicate data been fetch from the server.
I know that it sounds like we should use a single store in that case, but the chose all ready to use multiple stores.
What and how should be the best way to sync data between the stores?
Few points:
- All data have been fetch from our backend services
- The data structure is the same, but not all apps using the same data, some using subset of the datam
- Inorder to reduce the duplication of API calls we would like that "small stores" will be able to sync the data from the "main" store
reactjs redux redux-store micro-frontend
reactjs redux redux-store micro-frontend
asked Nov 18 at 10:09
USer22999299
1,48722252
asked Nov 18 at 10:09
USer22999299
1,48722252
edited Nov 18 at 12:04
asked Nov 18 at 10:09
USer22999299
1,48722252
asked Nov 18 at 10:09
USer22999299
1,48722252
asked Nov 18 at 10:09
USer22999299
1,48722252
1,48722252
1
The question isn't specific enough. It's unknown whether data structures are the same. It's unknown how data is handled. If I know that it sounds like we should use a single store in that case, but the chose all ready to use multiple stores. - a good thing about apps is that they can be refactored to solve design problems.
– estus
Nov 18 at 11:11
@estus thank you for the comment, regarding the refactoring point - will add the relevant info. currently, we are not able to do so. its to expensive
– USer22999299
Nov 18 at 12:05
Possibly a middleware that will listen for changes in one store and dispatch updates to another one. This will be hacky and possibly expensive too. But again, this totally depends on specific case. If it's initial data that needs to be synced, that's one thing. If data changes with time, that's another thing. The question will likely be closed any way. I suppose that you've been on SO long enough to see that such broad questions cannot get constructive answers.
– estus
Nov 18 at 12:08
The data structure is the same, but not all apps using the same data, some using subset of the data - yes, this looks like a good use case for single store.
– estus
Nov 18 at 12:12
@estus that's true if i'm waving back to my question - that's the case, i need to sync between multiple stores - looking for the best solution. currently the refactoring of the app will take to much time to have a single store. if we had the time - we would do it.
– USer22999299
Nov 18 at 15:08
add a comment |
1
The question isn't specific enough. It's unknown whether data structures are the same. It's unknown how data is handled. If I know that it sounds like we should use a single store in that case, but the chose all ready to use multiple stores. - a good thing about apps is that they can be refactored to solve design problems.
– estus
Nov 18 at 11:11
@estus thank you for the comment, regarding the refactoring point - will add the relevant info. currently, we are not able to do so. its to expensive
– USer22999299
Nov 18 at 12:05
Possibly a middleware that will listen for changes in one store and dispatch updates to another one. This will be hacky and possibly expensive too. But again, this totally depends on specific case. If it's initial data that needs to be synced, that's one thing. If data changes with time, that's another thing. The question will likely be closed any way. I suppose that you've been on SO long enough to see that such broad questions cannot get constructive answers.
– estus
Nov 18 at 12:08
The data structure is the same, but not all apps using the same data, some using subset of the data - yes, this looks like a good use case for single store.
– estus
Nov 18 at 12:12
@estus that's true if i'm waving back to my question - that's the case, i need to sync between multiple stores - looking for the best solution. currently the refactoring of the app will take to much time to have a single store. if we had the time - we would do it.
– USer22999299
Nov 18 at 15:08
1
1
The question isn't specific enough. It's unknown whether data structures are the same. It's unknown how data is handled. If I know that it sounds like we should use a single store in that case, but the chose all ready to use multiple stores. - a good thing about apps is that they can be refactored to solve design problems.
– estus
Nov 18 at 11:11
The question isn't specific enough. It's unknown whether data structures are the same. It's unknown how data is handled. If I know that it sounds like we should use a single store in that case, but the chose all ready to use multiple stores. - a good thing about apps is that they can be refactored to solve design problems.
– estus
Nov 18 at 11:11
@estus thank you for the comment, regarding the refactoring point - will add the relevant info. currently, we are not able to do so. its to expensive
– USer22999299
Nov 18 at 12:05
@estus thank you for the comment, regarding the refactoring point - will add the relevant info. currently, we are not able to do so. its to expensive
– USer22999299
Nov 18 at 12:05
Possibly a middleware that will listen for changes in one store and dispatch updates to another one. This will be hacky and possibly expensive too. But again, this totally depends on specific case. If it's initial data that needs to be synced, that's one thing. If data changes with time, that's another thing. The question will likely be closed any way. I suppose that you've been on SO long enough to see that such broad questions cannot get constructive answers.
– estus
Nov 18 at 12:08
Possibly a middleware that will listen for changes in one store and dispatch updates to another one. This will be hacky and possibly expensive too. But again, this totally depends on specific case. If it's initial data that needs to be synced, that's one thing. If data changes with time, that's another thing. The question will likely be closed any way. I suppose that you've been on SO long enough to see that such broad questions cannot get constructive answers.
– estus
Nov 18 at 12:08
The data structure is the same, but not all apps using the same data, some using subset of the data - yes, this looks like a good use case for single store.
– estus
Nov 18 at 12:12
The data structure is the same, but not all apps using the same data, some using subset of the data - yes, this looks like a good use case for single store.
– estus
Nov 18 at 12:12
@estus that's true if i'm waving back to my question - that's the case, i need to sync between multiple stores - looking for the best solution. currently the refactoring of the app will take to much time to have a single store. if we had the time - we would do it.
– USer22999299
Nov 18 at 15:08
@estus that's true if i'm waving back to my question - that's the case, i need to sync between multiple stores - looking for the best solution. currently the refactoring of the app will take to much time to have a single store. if we had the time - we would do it.
– USer22999299
Nov 18 at 15:08
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
As @estus noticed
The data structure is the same, but not all apps using the same data, some using subset of the data - yes, this looks like a good use case for single store.
... but for me this is a perfect case for graphQL/Apollo.
You can move/delegate data fetching (or even entire local app state) to one 'engine' and it will work exactly the same for all application parts (the same API endpoint).
There are many good things with this approach:
- separation data from app state(-s);
- cache and query batching (not only removing duplications but 'gluing' many queries in one);
- cache policies (only network, only cache);
- API stitching (future extensions, wrapping external services) ...
There is a nice starter for Apollo (contains redux parts).
PS. Apollo can work with REST APIs
answered Nov 18 at 13:39
xadm
1,560148
This is just an improvement to the single store or i missing something :) ?
– USer22999299
Nov 18 at 15:52
This is 'just' an solution to shared data fetching w/o single store refactoring, syncing and future problems ;) IMHO it's far more than improvement. Using HOCs (not query/mutation components) you can enhance existing components (redux connected) in the same way as with redux.
– xadm
Nov 18 at 16:34
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
As @estus noticed
The data structure is the same, but not all apps using the same data, some using subset of the data - yes, this looks like a good use case for single store.
... but for me this is a perfect case for graphQL/Apollo.
You can move/delegate data fetching (or even entire local app state) to one 'engine' and it will work exactly the same for all application parts (the same API endpoint).
There are many good things with this approach:
- separation data from app state(-s);
- cache and query batching (not only removing duplications but 'gluing' many queries in one);
- cache policies (only network, only cache);
- API stitching (future extensions, wrapping external services) ...
There is a nice starter for Apollo (contains redux parts).
PS. Apollo can work with REST APIs
answered Nov 18 at 13:39
xadm
1,560148
This is just an improvement to the single store or i missing something :) ?
– USer22999299
Nov 18 at 15:52
This is 'just' an solution to shared data fetching w/o single store refactoring, syncing and future problems ;) IMHO it's far more than improvement. Using HOCs (not query/mutation components) you can enhance existing components (redux connected) in the same way as with redux.
– xadm
Nov 18 at 16:34
add a comment |
up vote
0
down vote
As @estus noticed
The data structure is the same, but not all apps using the same data, some using subset of the data - yes, this looks like a good use case for single store.
... but for me this is a perfect case for graphQL/Apollo.
You can move/delegate data fetching (or even entire local app state) to one 'engine' and it will work exactly the same for all application parts (the same API endpoint).
There are many good things with this approach:
- separation data from app state(-s);
- cache and query batching (not only removing duplications but 'gluing' many queries in one);
- cache policies (only network, only cache);
- API stitching (future extensions, wrapping external services) ...
There is a nice starter for Apollo (contains redux parts).
PS. Apollo can work with REST APIs
answered Nov 18 at 13:39
xadm
1,560148
This is just an improvement to the single store or i missing something :) ?
– USer22999299
Nov 18 at 15:52
This is 'just' an solution to shared data fetching w/o single store refactoring, syncing and future problems ;) IMHO it's far more than improvement. Using HOCs (not query/mutation components) you can enhance existing components (redux connected) in the same way as with redux.
– xadm
Nov 18 at 16:34
add a comment |
up vote
0
down vote
up vote
0
down vote
As @estus noticed
The data structure is the same, but not all apps using the same data, some using subset of the data - yes, this looks like a good use case for single store.
... but for me this is a perfect case for graphQL/Apollo.
You can move/delegate data fetching (or even entire local app state) to one 'engine' and it will work exactly the same for all application parts (the same API endpoint).
There are many good things with this approach:
- separation data from app state(-s);
- cache and query batching (not only removing duplications but 'gluing' many queries in one);
- cache policies (only network, only cache);
- API stitching (future extensions, wrapping external services) ...
There is a nice starter for Apollo (contains redux parts).
PS. Apollo can work with REST APIs
answered Nov 18 at 13:39
xadm
1,560148
As @estus noticed
The data structure is the same, but not all apps using the same data, some using subset of the data - yes, this looks like a good use case for single store.
... but for me this is a perfect case for graphQL/Apollo.
You can move/delegate data fetching (or even entire local app state) to one 'engine' and it will work exactly the same for all application parts (the same API endpoint).
There are many good things with this approach:
- separation data from app state(-s);
- cache and query batching (not only removing duplications but 'gluing' many queries in one);
- cache policies (only network, only cache);
- API stitching (future extensions, wrapping external services) ...
There is a nice starter for Apollo (contains redux parts).
PS. Apollo can work with REST APIs
answered Nov 18 at 13:39
xadm
1,560148
edited Nov 18 at 14:03
answered Nov 18 at 13:39
xadm
1,560148
answered Nov 18 at 13:39
xadm
1,560148
answered Nov 18 at 13:39
xadm
1,560148
1,560148
This is just an improvement to the single store or i missing something :) ?
– USer22999299
Nov 18 at 15:52
This is 'just' an solution to shared data fetching w/o single store refactoring, syncing and future problems ;) IMHO it's far more than improvement. Using HOCs (not query/mutation components) you can enhance existing components (redux connected) in the same way as with redux.
– xadm
Nov 18 at 16:34
add a comment |
This is just an improvement to the single store or i missing something :) ?
– USer22999299
Nov 18 at 15:52
This is 'just' an solution to shared data fetching w/o single store refactoring, syncing and future problems ;) IMHO it's far more than improvement. Using HOCs (not query/mutation components) you can enhance existing components (redux connected) in the same way as with redux.
– xadm
Nov 18 at 16:34
This is just an improvement to the single store or i missing something :) ?
– USer22999299
Nov 18 at 15:52
This is just an improvement to the single store or i missing something :) ?
– USer22999299
Nov 18 at 15:52
This is 'just' an solution to shared data fetching w/o single store refactoring, syncing and future problems ;) IMHO it's far more than improvement. Using HOCs (not query/mutation components) you can enhance existing components (redux connected) in the same way as with redux.
– xadm
Nov 18 at 16:34
This is 'just' an solution to shared data fetching w/o single store refactoring, syncing and future problems ;) IMHO it's far more than improvement. Using HOCs (not query/mutation components) you can enhance existing components (redux connected) in the same way as with redux.
– xadm
Nov 18 at 16:34
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53359742%2fbest-practice-for-syncing-multiple-redux-stores%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
The question isn't specific enough. It's unknown whether data structures are the same. It's unknown how data is handled. If I know that it sounds like we should use a single store in that case, but the chose all ready to use multiple stores. - a good thing about apps is that they can be refactored to solve design problems.
– estus
Nov 18 at 11:11
@estus thank you for the comment, regarding the refactoring point - will add the relevant info. currently, we are not able to do so. its to expensive
– USer22999299
Nov 18 at 12:05
Possibly a middleware that will listen for changes in one store and dispatch updates to another one. This will be hacky and possibly expensive too. But again, this totally depends on specific case. If it's initial data that needs to be synced, that's one thing. If data changes with time, that's another thing. The question will likely be closed any way. I suppose that you've been on SO long enough to see that such broad questions cannot get constructive answers.
– estus
Nov 18 at 12:08
The data structure is the same, but not all apps using the same data, some using subset of the data - yes, this looks like a good use case for single store.
– estus
Nov 18 at 12:12
@estus that's true if i'm waving back to my question - that's the case, i need to sync between multiple stores - looking for the best solution. currently the refactoring of the app will take to much time to have a single store. if we had the time - we would do it.
– USer22999299
Nov 18 at 15:08