wiki.ziemers.de

# Warum erstellen wir den Cache?

# Was soll der Cache können?

# Muss hier nicht viel sein denke ich…

• /CAF100/ The system must …
• /CAF100/ The system must …
• /CAF100/ The system must …
• /CAF200/ The cache must …
• /CAF200/ The cache must …
• /CAF200/ The cache must …

• /CANF100/ The system must …
• /CANF100/ The system must …
• /CANF100/ The system must …

• /CANF200/ The cache must …
• /CANF200/ The cache must …
• /CANF200/ The cache must …

# Brauchen wir hier glaube ich garnicht, bzw. sollte das mit den User Stories für den BeuthBot oder die Registry definiert werden…

"Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>"

• /CAUS100/ Als Student möchte ich …
• /CAUS101/ Als Student möchte ich …
• /CAUS102/ Als Student möchte ich …

Für Node.js existieren mehrere Caching Lösungen. Bei den ersten recherchen fielen die npm packages “memory-cache” und “node-cache” auf. Da “memory-cache” seit drei Jahren kein Update bekommen hat, haben wir uns letzten endes für “node-cache” entschieden.

“node-cache” ist eine simple Caching Lösung, die nach dem Key-Value prinzip funktioniert. Der Funktionsumfang besteht dabei aus den Methoden “set”, “get” und “delete”, wobei die Methode “set” einem zusätzlich erlaubt noch einen Timeout (“ttl” bzw. “time to live” genannt) zu übergeben. Ist der Timeout überschritten, wird der Eintrag automatisch aus dem Cache gelöscht. Der Nachteil dieser Lösung ist, dass nur eine Millionen einträge pro Cache Instanz eingetragen werden können. Da aber gleich viel in den Cache eingetragen wird, wie die Anzahl angebotener Funktionen aller Microservices, wird dieser Nachteil nicht eintreffen.

# An welcher Stelle wird der Cache in das System eingebaut? (Registry)

# Wie wird sie eingebaut?

# Wie sieht das Endprodukt aus?

# Was musst der Cache / die Registry können, damit wir das Projekt als erfolgreich definieren können?

# Was müssen wir also tun?

# Auflistung der Tickets die entstehen…

# Vielleicht lieber direkt bei GitHub