This is a rewrite of my Rails-based book review app in rom-rb, dry-rb, (some parts of) Hanami, Sidekiq, GraphQL, React, Reach Router, Apollo, TypeScript, GraphQL Code Generator, Tailwind, and whatever other Cool Hipster Tech™ I can get my grubby hands on.
I am currently using this application to let early reviewers read my books and to leave comments on them.
Structure / Philosophy
My philosophy for developing this app revolves around separating two main parts of the codebase:
- The backend: retrieves data from data sources (GitHub / the database), and presents it for frontend consumption
- The frontend: retrieves data from the Backend, has no idea where it came from, and presents it to the user
I'm hoping with this app to demonstrate that it is possible to separate these two layers into two separate applications. My mental map of data flow within the application goes something like this:
DB <-> Backend Repositories <-> Backend GraphQL endpoint <-> Frontend <-> Browser
I want to demonstrate with this app that it's possible to build a frontend that only has knowledge of how to find data, not how it is constructed. In this app, the
frontend component knows only that it can find data at
/graphql. It has no knowledge at all about how the backend collects that data for presentation.
I want to also demonstrate that it's possible to build a backend app that is data-store agnostic. With the use of the Repository Pattern, the backend application knows only that it can talk to the repositories to collect the data. The backend application knows nothing about how that data is collected. Today, the repositories talk to a PostgreSQL database, but tomorrow it could just as easily be a Redis store and (assuming the data returned is the same), the backend app wouldn't know the difference.