szattila98 / veryrezsi Goto Github PK

Our actions which use docker should use jobs provided by the Docker team. This would be good because like this we can take advantage of its caching, and our build and publishing pipeline would run much quicker. Refer to the links for more info.

https://docs.docker.com/build/cache/backends/gha/
https://depot.dev/blog/docker-layer-caching-in-github-actions

Hey @szattila98, feel free to submit a PR to showcase your project!

• SeaQL/sea-orm#403

A page, nested page or modal that should contain a form to record a new expense. User should be able to enter all relevant information, and also there would be a list of predefined expenses to choose from.

This depends softly upon issue #6 , as a dashboard is needed for it to be usable, altough not mandatory at the time of dev.

Description

Return the list of transactions inside expenses response.

It is required before integrating client and server side

Implement an extractor which instead of only getting the userId from the cookie of the request, should also query the whole user from the db.
This may not be an easy task, as some kind of caching may be needed so not every request makes a database query, where it is used (but maybe not, this needs more discussion).
This would be nice because sometimes the whole user is needed and it would spare us the code duplication.
AuthenticatedUser extractor should be renamed then to AuthenticatedUserId and this should be the AuthenticatedUser. Both should remain as both will probably be needed.

• submit button prevent default works strangely before hydration, it is not disabled and submits the form without the js preventing the default behavior
• bottom scrollbar on login fadeout
• regex password validation rework
• account activation page and endpoint that proxies the activation request to the backend. A link to this should come in the activation email, but that also needs some backend config
• eslint does not work on some TS files
• the 'me' hook should call the sveltekit endpoint, not the server directly
• technical error alert component, in case something goes wrong server side we can show the same message everywhere
• make server email configurable

Tests in files are nice as unusual as they may be, but there is a sea_orm mock feature error because of it which is not nice. Try to extract these into a different module.

Create an API endpoint that lists available predefined expenses, currency types and recurrence types. This is a prerequisite to adding new expenses and transactions.

Integrate the client side and the server side, weed out mocks and make changes that need to be made because the logic of the backend differ from the mocked logic.
This is dependant on having a business logic, so on issues #21 #22 #23 #24

Use a library for deriving dtos or do it manually. Clean up serde from the entity workspace member.

When trying to develop with Node 14, login shows this error.

I read somewhere that btoa is being deprecated, maybe the effect of that is this.
Or maybe the app should not even run on Node 14? If so somewhere in the readme we should specify.

Types should be organized into a types directory in src root, from whence they would be imported.
The folder structure in types should resemble the directory structure of routes, with files for every page's types.

In the future there might be individual components that are not routes, those might need types, so maybe the typesdirectory should contain a routes and a components directory. @djavorek Whatcha think?

All requests should be implemented on the client side in an API, with their correct typings.

Out sveltekit auth is strange with no redirects and hacky cookie handling. We should make it more idiomatic.

Updating to the latest version of SvelteKit requires some code changes. (Even npm i will fail otherwise)

See sveltejs/kit#5774, for the required changes

Dependant on

#26

https://carlosmv.hashnode.dev/how-to-monitor-your-axum-app-with-prometheus-and-grafana

I wanted to view your work so I started up everything in docker and I saw this when I wanted to login.

Locally it works fine, I will be opening an issue to resolve this.

The design looks so cool! 🤩

Originally posted by @szattila98 in #72 (comment)

The page should contain information like, username, password and e-mail.
Other settings-like functionalities should be here in the future like credential changes, and other account management stuff.

I think we should root out these jsdoc typings, they look look wrong, idk why.
This link should help in this case, but this comment can be made into it's own separate issue, what do you think about all this?

Stop using ugly jsdoc type descriptions, that are there just for intellisense.

There are some dependency vulnerability errors reported by GitHub, upgrading dependencies should fix that.
cargo update && cargo upgrade command should take care of it. (the latter is provided by the cargo-edit plugin).
Also the dotenv dependency should be changed to dotenvy as the former is not maintained actively. (this page clears up why, nice touch at the bottom btw).
Also put the email template into a static string in email.rs, it does not work any better that way but it is a little more visible.

Write Rust tests on the server side, so we don't carry that technical debt with us forever.

This can be an all rounder issue, that is always commented on when server tests are needed.

Create an activation email template that is nice to look at. The current template is very basic. Spice it up!

The first step in writing the server should be to start writing the entities the business logic is dependant on.
The harder part would be the relationship between entities because there is no example inside the app but the sea-orm documentation should give adequate pointers.
As our functionalities are quiet interconnected I think these should all be created before writing the individual use-cases.

The functionality of sending an email on registration and activating the account is not implemented, but should be. Also configure mailhog in the docker-compose so we can develop without the hassle of creating a dummy email.

Also the password checker regex is missing because the vanilla regex crate did not implement lookarounds, search for another regex crate that does and add the validation.

Our error names have a MethodName+Error pattern, and it kinda ruins readability where it is long or does not match it's API endpoint handler. Refactor them to a more readable form.

Create an API endpoint that lists the expenses for the current user. Authentication is already handled at the server, the cookie contains the id of the current user.
This also includes getting and adding the transactions that are connected to the expenses.

We have all the necessary data on the Dashboard page to visualize the cashflow for each Expense (and of course we can sum these).

How

starting date +
recurrence +
price
= All outgoing +
Transactions values
= Cashflow

This is something that would be really cool with a fancy visualization. I will try to draft my thoughts in Figma.

Problems

• As an expense is not editable, the user is expected to open a new one when the Price of the expense change. But there is no way to close an old expense, so it will go on forever. This will really mess up visualization.
  • This is a separate feature to develop.

Keep the conversation going, long way to go in this area

A header should be designed and created that fulfills all our needs as of now, and it is stylish to look at.

A page, nested page or modal should be added, where user can add a transaction to a listed expense, and enter all relevant information.

Also, transactions should be shown under relevant expenses.

This depends heavily on #6 , as an expense is needed to initiate the addition of a transaction to it.

Implement server side logging. There is a wide variety of crates available for this purpose.

Create API endpoints for adding new expenses and transactions. Make sure that users can only add transactions to their own expenses.
This is dependant on #23.

What needs to be done

• Add a field for preferred currency info into our user table.
• Modify migrations to provide base data
• Modify registration process to either default to a curreny (probably EUR) or ask it from the user
• Create an endpoint to be able to modify it
• (If profile page exists by that time) It would be good to add it there as well, with the option of changing it

(Needs to be defined)

• How to use this info to avoid curreny conversion at the most places

Why

• Subscription prices are one of our main topic. Showing them in a foreign curreny is really bad UX

There was an idea that predefined expenses should be extendable. Make it so.
In the future we will decide whether we give users the power to do these or just admins.

There is no CORS configured yet, and it would be nice if there was.

Problem

I just realized, I used the AuthenticatedUser object to get the user id, instead of the path variable.
It does not matter much as for now authenticated users should only be able to access their own expenses.
However it can change in the future and we can also avoid later confusion this way.

Solution

Use Path(userid) and check it against the userid coming from AuthenticatedUser object.
Return 403 (Forbidden) if those differ.

The page should contain all expenses for the current user, and transactions that are connected to them.