moleculerjs / moleculerjs/rfcs
Multiple named cachers
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 2
- Forks
- 4
- PR merge metrics
- No merged PRs in 30d
Description
- Start Date: 2019-09-04
- Target Version: 0.14 or 0.15
- Reference Issues: -
- Implementation PR: -
Summary
Add multiple cacher configuration feature.
Examples
Example to define two cacher.
// moleculer.config.js
module.exports = {
nodeID: "node-1",
cachers: [
"Memory",
{
type: "Redis",
options: {
ttl: 30
}
}
]
};
Access to the cachers:
// Backward compatible mode
this.broker.cacher.get(); // use the first cacher, in this case, the "Memory" cacher.
// New named path. Name comes from the lowercased type of cacher.
this.broker.cachers.memory.get();
this.broker.cachers.redis.get();
Example to define two named cacher.
// moleculer.config.js
module.exports = {
nodeID: "node-1",
cachers: [
{
type: "Redis",
options: {
name: "first",
ttl: 30,
redis: {
db: 0
}
}
},
{
type: "Redis",
options: {
name: "second",
ttl: 3600,
redis: {
db: 1
}
}
}
]
};
Access to the cachers:
this.broker.cachers.first.get();
this.broker.cachers.second.get();
Usage in services
//posts.service.js
module.exports = {
name: "posts",
actions: {
list: {
// It will use the `this.broker.cachers.memory`
cache: {
cacher: "memory"
}
handler(ctx) {
/// ...
}
},
find: {
cache: {
// Set cacher by name
// It will use the `this.broker.cachers.redis`
cacher: "redis",
keys: ["limit", "offset", "#user.id"]
},
handler(ctx) {
/// ...
}
}
}
}
Motivation
In the big projects, certain services need a centralized Redis cacher but some simple services need only a local memory cacher. So, it would be good to add capabilities to ServiceBroker to support multiple cacher configuration.
Detailed design
This is the bulk of the RFC. Explain the design in enough detail for somebody
familiar with Vue to understand, and for somebody familiar with the
implementation to implement. This should get into specifics and corner-cases,
and include examples of how the feature is used. Any new terminology should be
defined here.
Drawbacks
Why should we not do this? Please consider:
- implementation cost, both in term of code size and complexity
- whether the proposed feature can be implemented in user space
- the impact on teaching people Vue
- integration of this feature with other existing and planned features
- cost of migrating existing Vue applications (is it a breaking change?)
There are tradeoffs to choosing any path. Attempt to identify them here.
Alternatives
What other designs have been considered? What is the impact of not doing this?
Adoption strategy
If we implement this proposal, how will existing developers adopt it? Is
this a breaking change? Can we write a codemod? Can we provide a runtime adapter library for the original API it replaces?
Unresolved questions
Optional, but suggested for first drafts. What parts of the design are still
TBD?
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the ServiceBroker cacher configuration described in moleculer.config.js and the cache usage shown in posts.service.js. Define the unresolved behavior for multiple and named cachers, including backward-compatible access and service action selection; done requires an agreed design detailed enough to implement and validate, but no tests or implementation files are identified in the issue.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100