https://github.com/karimsa/caltracker
Calorie tracking application - built for an interview.
https://github.com/karimsa/caltracker
Last synced: 3 months ago
JSON representation
Calorie tracking application - built for an interview.
- Host: GitHub
- URL: https://github.com/karimsa/caltracker
- Owner: karimsa
- Created: 2019-09-08T02:12:18.000Z (almost 6 years ago)
- Default Branch: master
- Last Pushed: 2019-09-12T04:31:39.000Z (almost 6 years ago)
- Last Synced: 2025-03-11T21:03:58.011Z (3 months ago)
- Language: JavaScript
- Homepage:
- Size: 237 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# CalTracker
Web application to assist with calorie tracking.
## Setting up for development
1. Clone the repo locally (let's say into `caltracker`).
2. `cd caltracker && npx @karimsa/mono`
3. Start dev server for web: `cd caltracker/packages/web && npm start`
4. Start dev server for api: `cd caltracker/packages/api && npm start` (will use default env from `.env`)
## Deployment considerations
There is no other environment other than `local` configured for web yet, but can be done so by editing `packages/web/src/models/axios.js`. The publicly accessible domain name would need to be known for this. Toggling between environments is handled by the `ENV_TARGET` environment variable, which is currently always set to the value `local`.
## Running tests
To run integration tests for the API, simply run `npm test` in `packages/api`. Again, all environment bits are loaded from `.env` and the code has other defaults it applies for test environments.
To run E2E tests, run `npm test` in the project root. This will start the API server, the web server, and run tests with Cypress. To develop E2E tests, run `npm run cy:open` instead - it will open cypress in open mode and run the same api & web servers.
## Considerations
1. **Timezones:** Currently, the application assumes that the backend & frontend are operating under the same timezone and therefore have the same concept of a 'day'. One simple way to fix this assumption would be to introduce a second user setting for timezone, which would allow the user to specify their own timezone and the backend to utilize this when making daily calorie calculations.