The solution proposed was a single-page application that relied on a Postgres database for persistence.


One of the challenges of the project was coordinating the work between two front-end developers while I developed the backend and part of the front-end. To this purpose, we used Apiary to simulate a REST API interaction. Then, we just swapped Apiary’s URI with our backend.

I discovered Nir Kaufman’s design patterns, and decided to try them out, ditching redux-thunk in favor of middlewares. Centralizing all of our API calls in one middleware proved to be a good decision. The only thing I changed was that in Nir’s examples, the actions triggered by an API call are constructed from a constant that holds the name of the action instead of building it from an action creator function.

To be able to parameterize the responses generated from our API calls, I modified his middleware design to accept action creators. In the process, I decided to add yet another layer of abstraction to some action creators and ended up with something you might call an action creator creator in React parlance:

export const fetchPublicationsSuccess = filter => data => ({
	payload: normalize(data, publicationsSchema)

In this way, middlewares were able to parameterize the actions triggered by API responses.


Local development was done via docker-compose while, deployment was handled by Heroku. I followed the 12 Factor app recomendations and had two similar environments in a Heroku Pipeline.