fafabc6e4a
After some toil and lots of learning, monzo_ynab is receiving access and refresh tokens from Monzo. I can now use these tokens to fetch my transactions from the past 24 hours and then forward them along to YNAB. If YNAB's API requires OAuth 2.0 login flow for authorization, I should be able to set that up in about an hour, which would be much faster than it took me to setup the login flow for Monzo. Learning can be a powerful thing. See the TODOs scattered around for a general idea of some (but not all) of the work that remains. TL;DR - Package monzo_ynab with buildGo - Move some utility functions to sibling packages - Add a README with a project overview, installation instructions, and a brief note about my ideas for deployment Note: I have some outstanding questions about how to manage state in Go. Should I use channels? Should I use a library? Are top-level variables enough? Answers to some or all of these questions and more coming soon...
41 lines
1.4 KiB
Markdown
41 lines
1.4 KiB
Markdown
# monzo_ynab
|
|
|
|
Exporting Monzo transactions to my YouNeedABudget.com (i.e. YNAB) account. YNAB
|
|
unfortunately doesn't currently offer an Monzo integration. As a workaround and
|
|
a practical excuse to learn Go, I decided to write one myself.
|
|
|
|
This job is going to run N times per 24 hours. Monzo offers webhooks for
|
|
reacting to certain types of events. I don't expect I'll need realtime data for
|
|
my YNAB integration. That may change, however, so it's worth noting.
|
|
|
|
## Installation
|
|
|
|
Like many other packages in this repository, `monzo_ynab` is packaged using
|
|
Nix. To install and use, you have two options:
|
|
|
|
You can install using `nix-build` and then run the resulting
|
|
`./result/bin/monzo_ynab`.
|
|
|
|
```shell
|
|
> nix-build . && ./result/bin/monzo_ynab
|
|
```
|
|
|
|
Or you can install using `nix-env` if you'd like to create the `monzo_ynab`
|
|
symlink.
|
|
|
|
```shell
|
|
> nix-env -f ~/briefcase/monzo_ynab -i
|
|
```
|
|
|
|
## Deployment
|
|
|
|
While this project is currently not deployed, my plan is to host it on Google
|
|
Cloud and run it as a Cloud Run application. What I don't yet know is whether or
|
|
not this is feasible or a good idea. One complication that I foresee is that the
|
|
OAuth 2.0 login flow requires a web browser until the access token and refresh
|
|
tokens are acquired. I'm unsure how to workaround this at the moment.
|
|
|
|
For more information about the general packaging and deployment strategies I'm
|
|
currently using, refer to the [deployments][deploy] writeup.
|
|
|
|
[deploy]: ../deploy/README.md
|