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

Persist data on our Backend IO Apps (graphql or node API) #19

Open
guilhermebruzzi opened this issue Jan 14, 2020 · 6 comments
Open

Persist data on our Backend IO Apps (graphql or node API) #19

guilhermebruzzi opened this issue Jan 14, 2020 · 6 comments
Labels
discussion Something isn't working practices/patterns stale This will not be worked on

Comments

@guilhermebruzzi
Copy link
Contributor

What is to be discussed?

For GET request, should we only use the HTTP Cache-control headers and trust the browser?

For caching values, should we use Master Data, VBase that comes with IO, or In-memory DataStores like our Redis clusters?

For persisting values that we would like to retrieve after should we use Master Data, VBase that comes with IO or our Redis clusters?

Describe the solution you'd like

It depends on each case.

If to assemble the response is fast enough, don't even persist or cache anything.

HTTP Cache-control is good enough for resources that don't change based on the url (not suited for graphql) and which is fast enough to assemble the response.

Redis is more suitable for caching instead of persisting values and is faster than persist on VBase, but I've never used on a IO App because it wasn't possible when I wanted (but if it makes sense to be a pattern, we should demand it)

VBase is good enough when you want to store data based on key / value

Master Data is more suitable for complex data with relations that you want to do a search and bring related data

@lucis
Copy link
Contributor

lucis commented Jan 14, 2020

@saviofelixmuniz has solid plans on doing a default MasterData client to be exported from @vtex/api, what would help a lot. He also have been talking about plans to create a UI admin to MasterData, what I think that, when done, could put MD closer to almost all solutions

@guilhermebruzzi
Copy link
Contributor Author

@luciannojunior Redis is still better than MD for caching key-value based values. But for all other cases this would make MD way better than VBase for persisting data

@stale
Copy link

stale bot commented Jan 22, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If this is a discussion thread, the most voted option will be final. Thank you for your contributions.

@stale stale bot added the stale This will not be worked on label Jan 22, 2020
@mcandeia
Copy link

mcandeia commented Jan 27, 2020

Is this topic really related to js-standards?

@stale stale bot removed the stale This will not be worked on label Jan 27, 2020
@guilhermebruzzi
Copy link
Contributor Author

@marcosvcp No, but I think the original idea were also about patterns that the frontend teams would follow on their products, including on the graphql stack, right @kaisermann ?

@stale
Copy link

stale bot commented Feb 7, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If this is a discussion thread, the most voted option will be final. Thank you for your contributions.

@stale stale bot added the stale This will not be worked on label Feb 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Something isn't working practices/patterns stale This will not be worked on
Projects
None yet
Development

No branches or pull requests

3 participants