Giter Site home page Giter Site logo

monetr / rest-api Goto Github PK

View Code? Open in Web Editor NEW
3.0 3.0 2.0 3.9 MB

REST API powering our budgeting application.

Home Page: https://docs.monetr.dev

License: Other

Go 94.81% Dockerfile 0.15% Makefile 2.05% Shell 0.30% Smarty 0.28% PLpgSQL 0.19% HCL 0.49% HTML 1.73%
budgeting finance

rest-api's Introduction

monetr

GitHub FOSSA Status codecov Go Report Card DeepSource Discord

monetr is a budgeting application that aims to allow people to more easily plan their recurring expenses. It is completely free to self-host (documentation to come), but requires a Plaid account in order to communicate with banks.

monetr is currently still in heavy development, but working towards a v1.0.0 release. You can see what items are still outstanding before a v1.0.0 release for monetr will be published here: v1.0.0 Milestone

image

Contributing

In order to run monetr locally you will need sandbox credentials for Plaid, you can obtain your own credentials here: Plaid Sign Up. Once you have a Client ID and a Client Secret you can run the following command in the monetr project directory to start a local environment.

To start working on monetr, you can follow the Local Development documentation. Or if you want to just dive in you can run the following command in the project directory:

make develop

This will set pretty much everything up that you need to work on monetr. This also works out of the box inside GitPod or GitHub Codespaces.

Open in Gitpod

Open in GitHub Codespaces

Contributions are more than welcome!

License

FOSSA Status

rest-api's People

Contributors

dependabot[bot] avatar elliotcourant avatar fossabot avatar mend-bolt-for-github[bot] avatar renovate-bot avatar

Stargazers

avatar avatar avatar

Watchers

avatar avatar

Forkers

fossabot johndpope

rest-api's Issues

Allow Transaction Modifications

Transactions should be able to be modified with a PUT request to /bank_accounts/{bankAccountId}/transactions/{transactionId}.

If a transaction is from a manual link, then the following fields can be modified along with all the fields from the plaid version.

  • Amount
  • OriginalCategories (maybe just make these two fields match or just omit one?)
  • Date
  • AuthorizedDate
  • OriginalName (Same logic with categories, do we want to maintain two fields for this for manual transactions?)
  • IsPending

If a transaction was not created with a manual link, and was imported via Plaid then only the following fields can be modified:

  • ExpenseId
  • Categories
  • Name
  • MerchantName

A transaction cannot change its bank account.

Behaviors for expenses:

  • When an expense is added to a transaction: Update the transaction's expenseId field, deduct the transaction's amount from the expense's current amount (do not go negative).
    • This has an inherent flaw: If a transaction is for $10, and then is spent from an expense with a current amount of $5, the expense's current amount becomes 0. In this moment the safe-to-spend is correct. But if the user were to remove the transaction from that expense; we would have no way of knowing that we should only return $5 of the $10 spent on the transaction to that expense. We would need to keep track of how much money was on the expense before a transaction was allocated to it in order to compensate for this.
  • When a transaction is removed from an expense: Set the transaction's expenseId field to nil, return the amount of money spent from the expense to the expense's current amount. (see note above).
  • When a transaction changes from expense A to B; combine the operations above as described.

Build out way to test Plaid webhooks locally.

We should try to run the entire application stack in minikube. Then we can run an ngrok container in minikube and do something with this: https://ngrok.com/docs#non-local

Then we can have ngrok forward something like rest-api.default.svc.cluster.local:4000.

This should also be tucked behind a build flag maybe? Where the rest-api automatically reaches out to ngrok running in kube like ngrok.default.svc.cluster.local:4040 and requests the public ngrok domain https://ngrok.com/docs#client-api-base

Query transactions for expense.

Add an API endpoint /bank_accounts/{bankAccountId:uint64}/spending/{spendingId:uint64}/transactions that will return the last few transactions that were spent from the specified spending.

SMTP or SendGrid emails.

We need to be able to send users emails when they sign up or when they forget their password.

Transaction Webhooks From Plaid

https://plaid.com/docs/api/webhooks/#transaction-webhooks

These need to be implemented in order for the application to be aware of transactions that have been moved from a pending state to a complete state. As I understand it, a pending transaction is deleted and a new transaction is created with the same data but without the pending state.

LATER: Historical update: When we initially link with plaid we should wait for this webhook before performing our initial transaction pull.

Track how much was spent from an expense per transaction.

When a transaction is spent from an expense we need to keep track of how much was spent. For example; If a transaction is $10 and is spent from an expense that only has $5 allocated, then we cannot spend all $10 from it. We should thus keep track in a separate object, or as an additional field on the transaction itself for expenseAmount. This way if the expense a transaction is spent from changes we can easily revert the amount on an expense.

This solves an issue relating to #46

Create plans for the different types of accounts.

https://stripe.com/docs/api/products

https://stripe.com/docs/api/plans

https://stripe.com/docs/api/plans/create

Look into using this terraform provider to make managing the stripe resources and objects easier?
https://github.com/franckverrot/terraform-provider-stripe/tree/v1.8.0

  • amount; Integer in cents for how much to charge for the particular plan. (Will be 300/$3.00 or 100/$1.00)
  • currency; USD
  • interval; Will be month initially, will have other options later.

WIP

Create a stripe customer when a new user registers.

Use the following API to create a stripe customer when a new user registers for the application.

https://stripe.com/docs/api/customers/create

There don't seem to be any required parameters with this API, but we would want to include the user's name at the very least. We would also want to include their user Id in the metadata.

The customer Id would be then stored on a billing table, this table would reference both the user and the account object's in the application. If the user is deleted then the record in the table should be deleted as well.

Allow bank accounts to be modified.

Bank accounts (at the time of writing this) can't be changed once they are created.

Bank accounts should be able to be modified with a PUT request to /bank_accounts/{bankAccountId}.

If the bank account belongs to a Plaid link then only the following fields can be modified:

  • Name

If a bank account belongs to a manual link all the fields above and these fields can be modified:

  • AvailableBalance
  • CurrentBalance
  • Mask
  • Name
  • Type (No validation on what this can be yet though)
  • SubType

The user can never modify the following fields:

  • BankAccountId
  • LinkId
  • originalName
  • officialName

Goals

Goals are similar to expenses but are not recurring. They only fund until they reach their target, at which point they are complete.

Fields:

  • Target amount
  • Current amount
  • Used amount
  • IsComplete

These should largely function the same way expenses do, but do not reset once the target is reached.

Add support for PostgreSQL read replicas.

Long term the REST API should use two different connections to the database. When any write might be performed during a request or an action; then the primary database connection needs to be used. When only reads will be performed during a request or action, either a replica or the primary connection can be used. To simplify logic it might be best to always use a replica for reads.

This has the potential to cause some issues with stale reads. When completely deployed the database the REST API will be using will be using asynchronous replication. So if something like an expense were created and then the user tried to see that expense in a different browser or device shortly after, its possible that the user won't see it. I do not have any numbers at the time of writing this for what to expect for replication lag with PostgreSQL. But at the time of writing this I feel that even a replication lag of a few seconds is acceptable (even if it's not ideal). This is because any action that can be taken by the API that would modify any data; will always be served by the primary. Which will always have the most up-to-date data.

I plan on using pgo to deploy a high-availability PostgreSQL cluster to Kubernetes for the REST API. go-pg (the ORM used by the REST API) already has some basic connection pooling built into it. So I'm not sure how much the API might benefit from something like pgbouncer. pgpool is another alternative that is aware of primary and replica nodes.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.