# An update about Redis developments in 2019

DevFeed: [An update about Redis developments in 2019](<https://devfeed.tech/articles/an-update-about-redis-developments-in-2019-20617.md>)

Original publisher: [Read original article](<http://antirez.com/news/126>)

Published: 2019-02-20T12:14:11Z

Content type: article

Language: en

Sources: [Antirez](<https://devfeed.tech/sources/antirez.md>)

Topics: [Redis](<https://devfeed.tech/topics/redis.md>), [Protocol (disambiguation)](<https://devfeed.tech/topics/protocol.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [client](<https://devfeed.tech/topics/client.md>), [Library](<https://devfeed.tech/topics/library.md>)

Tags: [caching](<https://devfeed.tech/tags/caching.md>), [client-library](<https://devfeed.tech/tags/client-library.md>), [development](<https://devfeed.tech/tags/development.md>), [library](<https://devfeed.tech/tags/library.md>), [protocol](<https://devfeed.tech/tags/protocol.md>), [redis](<https://devfeed.tech/tags/redis.md>)

## AI overview

This Redis blog post responds to community concerns about Redis development in 2019. It explains that RESP3 is intended to simplify client handling and that its reply attributes support server-assisted client-side cache invalidation.

## Source excerpt

Yesterday a concerned Redis user wrote the following on Hacker News: -- https://news.ycombinator.com/item?id=19204436 -- I love Redis, but I'm a bit skeptical of some of the changes that are currently in development. The respv3 protocol has some features that, while they sound neat, also could significantly complicate client library code. There's also a lot of work going into a granular acl. I can't imagine why this would be necessary, or a higher priority than other changes like multi-thread support, better persistence model, data-types, etc. -- end of user comment -- I've the feeling she/he (not sure) is not the only one that looks at ACLs as some sort of feature imposed by the Redis Labs goals, because "enterprise users" or something like that. Also the other points in the comment are interesting, and I believe everything is very well worth addressing in order to communicate clearly with the Redis community what's the road ahead. For simplicity I'll split this blog post into sections addressing every single feature mentioned in the original comment. ## RESP3 The goal of RESP3, as I already blogged in these pages, is to actually simplify the clients landscape. Hopefully every client will have a lower layer that will not try to reinvent some kind of higher level interface: redis.call("get","foo"). There is no longer need to orchestrate conversions because now the protocol is semantical enough to tell the client what a given reply should look like in the hand of the caller, nor any need to know beforehand the command fingerprint for the majority of commands. What I think the user is referring is RESP3 support for out of band communications, that is the reply "attributes". I really believe that in the future of Redis "client side caching" will be a big thing. It's the logical step in every scalable system. However without server assistance client side cache invalidation is a nightmare. This is the reason why RESP3 supports attributes in replies, mainly. However probably