FunctionStore uses fileStore for function code and resourceStore for
the Function's metadata. Environment- and HTTPTrigger- Store are just
thin wrappers on resourceStore.
There is probably a better way to organize this code, maybe with
reflection.
- A generic Resource interface, which is serializable and has
a key() method to get an identifying key.
- A resourceStore, which has create, read, update, delete and list.
This wraps etcd key operations and serialization/deserialization in
a convenient service. Serialization is provided to the
resourceStore as a 'serialization' interface. This can be JSON or
anything else.
- The resourceStore also has file operations -- this has read, write
and delete operations. The general idea is to store metadata in
etcd and data on the fileStore (which could also be an object store,
we don't really use any file-specific properties). Files are also
versioned -- each writeFile writes to a new UUID and that UUID is
stored in an etcd in-order list. readFile can retrieve an arbitrary
version by UUID, or just get the latest contents.
Soam Vasani