hord VS automated-garden

In an effort to provide actual persistent storage out of the box, the babyapi/storage package uses madflojo/hord to support a variety of key-value store backends. Additionally, babyapi/storage provides helper functions for initializing the hord client for Redis or file-based storage.

Determined to implement generics and delete some lines of code, I turned my sights to the storage layer of my application. I designed my storage around key-value pairs since I started by storing resources in YAML files. This eventually evolved to use madflojo/hord to interact with key-value data stores like Redis. The function to read a *pkg.Garden from storage looks like this:

I created babyapi with the goal of providing the simplest path to a full REST API. It started as a humble package that used generics to reduce code duplication in my automated-garden API. After breaking it out into its own repository, I added the optional HATEOAS extension which sets up automatic hypermedia linking. Now you can easily create a REST API which achieves all levels in the Richardson maturity model using babyapi.

When thinking about duplicated code in my automated-garden project, the first thing that comes to mind is all of my API handlers. The server side of this application implements a few straightforward CRUD APIs following RESTful principles. Each resource type implements handlers for the different HTTP verbs and mostly interacts with the storage layer. I created a very simple setup for the API handlers following this formula: