|Devin Dooley 98d5456b73||1 year ago|
|api||1 year ago|
|clients||1 year ago|
|config||1 year ago|
|db||1 year ago|
|.air.conf||1 year ago|
|.gitignore||1 year ago|
|Makefile||1 year ago|
|README.md||1 year ago|
|go.mod||1 year ago|
|go.sum||1 year ago|
|me.go||1 year ago|
Me is a personal data aggregator.
In fact, it's so personal that it really will only work for me, it's creator (and even for me, it doesn't do nearly as much as I would like).
This has included on-and-off work over a couple iterations. My inspiration was to work against my terrible memory by answering to the best of my ability: "What the hell was I doing?" for some given time frame.
Architecturally, this is a Golang/Gin server, a ReactJS web client, and a React Native client, all wrapped into one repository (kids these days seem to call it a monorepo). The server is designed to communicate with a Postgres database, and for most client views will simply act as a proxy server to Plaid, Dark Sky, CTA Train Tracker, or whatever else ends up getting integrated. The intention is to only store in the database what cannot be retrieved from someone else's API for free, because I am cheap and my homelab has too few 9s of availability to justify anything more involved.
At the time of writing, MVP is still not complete, but will include:
Last time this README was updated, I had an API that proxies requests to those services, and a web client that supports logging in and viewing account balances. We'll see how much more I get before my focus gets drawn elsewhere.
This application is dependent on Plaid's API to retrive account information from financial institutions. Because this is intended to be used for a single user, it is assumed that this is deployed using their development API keys.
Keys for client_id, public_key and secret_key can be obtained from Plaid's website after registration. Rather than tie this into their Plaid Link code, I've chosen to clone their quickstart repository and retrieve an access_token by running the Plaid Link code locally to retrieve the access_token. These tokens never expire, so this is a one-time process.
Dark Sky is used to gather weather information and forecasts. You will need to get a Dark Sky API secret key by registering for a free account on their website.
A configuration file needs to be created and stored in the main directory as
.config.yml. The file
should have the following format:
me: port: ":PORT_TO_SERVE_ON" environment: BUILD_ENVIRONMENT web_dir: ./web/public cta: secret_key: CTA_KEY home_station: 12345 work_station: 12345 dark_sky: secret_key: DARK_SKY_SECRET_KEY db: address: ADDRESS_OF_POSTGRES_DB plaid: client_id: PLAID_CLIENT_ID public_key: PLAID_PUBLIC_KEY secret_key: PLAID_SECRET_KEY environment: development version: 2019-05-29
The general idea for managing the database schema is to ignore all best practices I am aware of, as I have found it extremely tedious or messy in every instance I've come across.
Instead of storing schema patches, my intention is to directly apply updates to the schema from
the psql command line interface during development, and commit the updated schema to the repository
pg_dump -s. Progressive updates will be applied to the server's database upon deploy,
regressive updates will be managed by diffing schema versions via a tool akin to migra,
then patched manually.
For now, this is all just my idea of how it will work. It would obviously never scale well, but for a single developer project I'm excited to see how this workflow holds up.