Sagas Microservice Architecture Patterns
sagas on backend, & frontend, via redux.
- touches on & illustrates how choreography (event-based) vs orchestration (command-based) architecutures would look, when attempting to solve the same problem.
Redux-sagais a middlewear that helps us get a more async looking style of code
our sagas are split into 2 categories, watchers & workers.
- this is just convention, not necessarily the only way to do it.
- watcher sagas see every action that is dispatched to the redux store, if it matches the action they are told to handle, they assign it to their worker saga
- is this a form of orchestration? as seen & explained in the first backend video
call: runs a function. if it returns a promise, the saga is paused until it’s resolved.
put: dispatches an action.
takeEvery: takes every matching action and runs the matching saga, can run concurrent tasks.
takeLatest: takes every matching action and runs the matching saga, but cancels any previous saga task, if it is still running.