andersbandt / Financial-Analyzer

Analyzes spending, budget, and investment data in a CLI
GNU General Public License v3.0
17 stars 4 forks source link

Project definition, frameworks, and structure #18

Closed andersbandt closed 11 months ago

andersbandt commented 1 year ago

Project Definition

I will be defining two aspects of the project that I think are the most important, useful, and interesting.

Part 1 - Analyzing personal spending data

This part of the project will focus on storing personal spending data in a database and the ability to perform analysis on that spending data - including things such as trends, visualizations, and comparisons to preset budget goals.

Loading in data

The user will be able to load in spending data, process that data through a categorization process, and store data on user's machine.

To start, I think using local file data will be the easiest. I'm open towards adding cloud capability later depending on complexity.

The categorization process will be based on the "category tree" concept that I defined in the roadmap.MD. Currently in the code there is some "automatic" categorization happens based on if a certain keyword is in the transaction description. This categorization process can be improved and is very primitive now, but it's been working decently ok for me so far. We could also go so far as to add something like a NN modeling system, however that will be almost a whole project in itself.

Then the data will have to be stored in the database so that analysis will become much easier on standardized data.

Data analysis

A separate part of that project will focus on taking in that stored data and doing a broad range of analysis on the data

This includes things such as

Part 2 - Analyzing investment/balance data

This aspect of the project is not really fleshed out well in the code as it stands today. However, I think this will be an important aspect of the project. In order to provide a comprehensive view of personal finances I think balance and investment data will be critical in looking forward towards long term savings goals.

Features to add are portfolio tracking, producing allocation amounts to various asset categories, and viewing balance data across accounts.

There is likely already lots of code out there for investment tracking and modeling capabilities as it is a popular topic.

To list a few key aspects

Division of frameworks

The code today is incredibly merged between the front end Tkinter GUI aspect and the "backend". Some work will have to be taken to separate the code and create a proper API.

Front end

I have been experimenting with Vue.js and have built a basic skeleton on the feature/vue branch. I am open to switching between frameworks but there's already some groundwork laid for Vue.js and it was received well in some conversation on the Discord.

I think a good starting point would be to basically replicate the Tkinter GUI in a web based framework.

Back end

The back end was chosen to be using Flask.

I think a decent starting point for working on the back end is to slowly remove any GUI related aspects and increase the separate code into even smaller modules. I will make a draft outline of the modules/functionality needed here, but think it should be a group discussion on the optimal breakdown

lordlabakdas commented 1 year ago

Thanks for the writeup.

The way I see the solution from the technical perspective: a front end for visualization and beyond (Vue or similar) -> Flask API Layer -> Current (modified) backend -> DB ORM (such as SQLAlchemy if db is relational) -> db (do we want to stick with SQLite)

To achieve this, the immediate tasks in order of priority IMO are: decoupling of analysis and visualization decision on the database and associated ORM and its side effects Flask API layer front end work

Of course, the above are only major tasks. Other tasks such as tests, logging reman.

Let me know your thoughts

andersbandt commented 1 year ago

I think that's a good technical solution. Database discussion should definitely be had - earlier than later. I am not too familiar with database stuff, I've only ever used SQLite. I just had to look up what an ORM as well haha. So I think that discussion should be had by people with more experience in it than me.

I will also do research into best practices for the Flask API layer - maybe I can make a separate write up on the roadmap for that aspect of the project

andersbandt commented 11 months ago

Closing this issue as I have moved forward with a CLI based application