-
Notifications
You must be signed in to change notification settings - Fork 67
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
Provide persistent context options #212
Comments
Initial user feedback is showing strong support for this feature |
Another request from a user for this mentioned as a blocker for migrating Node-RED projects to flowforge |
What should happen to persistent context data when a project is suspended, should we clear the data or not? |
There are three key design points for this item:
We added the File Server component to the platform in 1.1.0. This already solves the authentication question and I propose we extended it to also provide a Context API. That solves item 2. For item 3, Devices should be configured with a standard built-in file based context - they do not need to access the File Server. That leaves Item 1 - what backend storage we use for context requests. When running locally, it can still be a local file based implementation. When running in the cloud, I don't think it make sense to leverage the S3 api - S3 isn't really suitable for the sort of traffic context could generate and would get expensive. Redis has long been the assumed best service for Context - what options are available for the k8s and docker deployments? |
What if (similar to the NR file backed context) we use a memory cache & flush every 30? Is that still too frequent? |
It depends on what quality of service we want to provide. Having a potential 30s data loss window could be a problem. But equally, for an initial iteration, it could be okay if it removes the need to introduce another data service. Before we commit to a path however, we should understand the $ costs of S3 - it isn't really intended for this type of usage so its pricing could well penalise us quite heavily. We can make a start on all the other bits whilst we validate the choice of service. |
(thinking out loud / definitely lateral / one for discussion?...) I wonder if we could utilise persistent MQTT topics in the (existing) broker as the cache & flush less frequently? NB: Will be speaking with Ben very shortly (slack huddle) about this epic. |
MQTT brokers should not be used as ad-hoc object stores Current consideration is to build something very similar to the file-server, but using Redis (or similar) as the backend |
Will look at the 2 different AWS services that provide Redis support https://aws.amazon.com/redis/
Also need to have another look for Postgres HStore client for NodeJS, all the ones I've found so far are abandonded. After talking to Nick, I will add some more endpoints to the file-server rather than start another new project |
EDITED 12/08/2020 See latest thread |
First pass at context api https://github.com/flowforge/flowforge-file-server/tree/persistence-context |
@Steve-Mcl I'd rather not have more options. Either this improves something and it's the only way forward, or we don't build the feature at all. |
ZJ, This is referring to how we enable / disable the context plugin automatically due to env (e.g. cloud vs device) - not a user option. The above points were only ever intended to be be reminders for myself and @hardillb to come back and pad these out with details once the initial "first pass" was done. Will try to be more explicit in future. |
|
As this issue is in the Done column on the dev board and was delivered in 1.2 can it be closed? Any follow-on items should be raised as separate issues at this point. |
Yes, I believe now is ok - we have raised issues for the timeout problem and s3 tests (which are now in a PR & I am currently testing the minio stuff locally) |
Description
The default Context storage in Node-RED is memory only.
A value-added feature is to support persistent context storage options - such as via Redis.
A possible extension would be to support sharing the context store between two projects in the same team - useful for high-availability type scenarios.
Which customers would this be availble to
The text was updated successfully, but these errors were encountered: