Avers objects Static<T> and Ephemeral<T>

Up until now Avers had just one object type which the storage layer managed: the Editable<T>. It represents an object whose properties can be individually edited, and those changes are automatically synchronized back to the server. However in many situations this single type is either insufficient or overly complex.

Consider for example a help text. It is not something that is needed right away when the application starts. It can be loaded on demand. But once it is loaded on the client it should be kept in the cache forever. Furthermore, it is not something that the user needs to be able to edit. These types of values is what Avers refers to as static.

Another example is the current server load. It again has an asynchronous component (i.e. it is unknown when the client starts and is updated in the background). But unlike a static it can change. It has an expiration time after which the value is considered stale and must be updated (e.g. by fetching it again from the server). Avers refers to these types of values as ephemeral. A static value can be viewed as a special case of ephemeral with an infinite lifetime.

Adding these new object types to Avers is exciting for two reasons. First, Avers now covers many more use cases straight out of the box 1. I can think of many exciting features which suddenly become so much easier to implement.

And second, it makes Avers useful in many more types of applications. Even if you don't need the full power of an Editable<T>, you most likely need some way to fetch data to the client. If your access pattern fits the static or ephemeral object types, then you can use Avers. Because in both these types of objects you can define the fetch function yourself, you can use whatever mechanism you like (even WebSockets). You don't even have to run an Avers compatible API server unless you are using Editable<T>.

I've started a wiki page describing the different object types and use cases where they are useful: Managed Object Types


  1. Some people may call it feature creep. But I was getting tired of implementing the same synchronization code in every application, so I decided to move it into Avers. There is still the option to move the implementation into separate files so users can include the feature only when need it. But someone would have to come to me with a compelling reason to justify the effort.