Open theadell opened 1 year ago
@adel-habib great idea with the usage of postgres, i have read all of the draft and all of the entities and i would say they would serve as a good start, what we can do even to improve our efficiency is start from frontend and design, at the end of the day we are going to serve the frontend whatever it needs , and to keep the whole app user focused i would suggest we start with frontend designs first to have a clear picture of the APP and then we will modify the models you suggested according to what the frotnend needs , for example by understanding how the frontend looks like , you can have a very good idea about will the queries will look like and therefore have a scalable db design that doesn't only facilitate ATOMIC transactions but also helps in a db design that would make db queries fast and scalable looking forwards to hear what you think about this
Good idea. I will try to prepare something for Monday. On Monday we can have a Slack huddle to put everything together. I think once we decide what pages/components/forms we need, it should be easy to start developing the API and the front end simultaneously. I agree with you that we should keep it very user-focused.
Hey there! @abdelrahman543873
This Github issue is intended to be our open forum for brainstorming and hashing out our design decisions for the Refundly app. It's just the first draft of what I think our application architecture could look like, and I'm open to refining this model with your valuable input. So, let's dive in!
Database Schema
We're going to stick with PostgreSQL for our database - it's scalable, robust and super reliable. I've thought up a few tables that we might need:
The detailed schema proposal is listed below. Let me know what you think!
Session Management
Our users should be able to log in using Google (OpenId Connect), Github, Gitlab, Atlassian (OAuth 2.0), or just a simple Form Login (basic Auth). After a successful login, I propose we use JWTs with Refresh Tokens for session management. We issue a short-lived access token for requests and a long-lived refresh token to obtain new access tokens after the short ones expire.
Storage
We need to handle file uploads for receipts, so I suggest we use an S3 bucket for storage and just keep the links in our PostgreSQL database. Simple and functional, right?
REST Endpoints
User-related endpoints:
POST /api/users
: Register a new user.POST /api/users/login
: Authenticate a user and return a token.GET /api/users/me
: Get the authenticated user's details.PATCH /api/users/me
: Update the authenticated user's details.DELETE /api/users/me
: Delete the authenticated user's account.GET /api/users/{id}/expenses
: Get all expenses of a specific user.Company-related endpoints:
POST /api/companies
: Create a new company.GET /api/companies/{id}
: Get a company's details.PATCH /api/companies/{id}
: Update a company's details.DELETE /api/companies/{id}
: Delete a company.GET /api/companies/{id}/users
: Get all users of a specific company.GET /api/companies/{id}/expenses
: Get all expenses of a specific company.Expense-related endpoints:
POST /api/expenses
: Create a new expense entry.GET /api/expenses
: Get all the expense entries of the authenticated user.GET /api/expenses/{id}
: Get a specific expense entry.PATCH /api/expenses/{id}
: Update a specific expense entry.DELETE /api/expenses/{id}
: Delete a specific expense entry.Payments-related endpoints:
POST /api/payments
: Create a new payment entry.GET /api/payments
: Get all the payment entries of the authenticated user.GET /api/payments/{id}
: Get a specific payment entry.PATCH /api/payments/{id}
: Update a specific payment entry.DELETE /api/payments/{id}
: Delete a specific payment entry.Notifications-related endpoints:
GET /api/notifications
: Get all the notifications of the authenticated user.PATCH /api/notifications/{id}
: Mark a specific notification as read.AuditLogs-related endpoints:
GET /api/companies/{id}/auditlogs
: Get all the audit logs of a specific company.User Stories
To keep us user-focused, I've drafted a few user stories. Here's what I've got so far:
So, that's what I've been thinking about so far for Refundly's design. This is just a rough draft, and I'm sure we'll make plenty of tweaks along the way. Later, we might think about adding features like budgets and project tracking.
I'm excited to hear your thoughts and ideas on this. We're going to learn a lot and build something useful together. Feel free to critique or add to this proposal. Let's start refining this and make Refundly a reality.
Looking forward to your feedback!