agusx64/flavorwell_app

1. Overall shape

Flavorwell App is a Node.js + Express application that serves a mostly static, page-oriented web UI and also ships as an Android app wrapper via Capacitor. The core product is a social recipe-sharing experience with login, user profiles, recipe browsing, saved items, and recipe submission.

2. Server boundary

The backend appears to be the Express app rooted at app.js, with bin/www as the launch entrypoint. Server-side concerns are split into three route/controller modules under routes/: usersController, dashboardController, and listController.

3. Presentation layer

The UI is organized as a set of HTML pages in public/html/, styled by page-specific CSS in public/stylesheets/. The app uses a traditional multi-page structure rather than a single-page framework. Pages cover onboarding, authentication, dashboards, recipe views, profile screens, settings, and list views.

4. Client-side logic

Most interactivity lives in public/javascripts/, with one script per page or feature area. Examples include login_UI.js, signup_UI.js, user_dashboard_UI.js, recipe_register_UI.js, and recipe_viewer_UI.js. This indicates a front-end architecture where each page loads a targeted behavior module rather than sharing one large client bundle.

5. Feature modules / user flows

The main functional flows are:

- onboarding and language selection

- sign up, login, password recovery/restoration

- dashboard and recipe discovery

- recipe detail viewing and saving

- recipe creation/registration

- user profile and settings

- category/library browsing for breakfasts, desserts, dishes, and vegan recipes

6. Internationalization / localization

There is explicit Spanish/English support in views/en and views/es, plus client scripts like translations.js, choose_language.js, and choose_language_settings.js. Language choice appears to affect both the UI and server-rendered verification/status pages.

7. Data layer

The repository includes flavorwell_db.sql, which is the primary schema artifact for the application’s MySQL database. The DB likely stores users, recipes, categories/lists, saved recipes, and verification/reset-related state. The SQL file is the clearest source of persistent domain structure in the repo.

8. Media and external storage

Recipe and profile imagery are likely stored in Cloudinary, as documented in the README. The presence of public/images/_img_recipe and UI image folders suggests some local assets, but Cloudinary is the main external media backend for user-uploaded content.

9. Mobile packaging

The android/ directory is a full Capacitor Android shell around the web app. MainActivity.java and capacitor.config.json indicate the same web UI is packaged for mobile execution, with Android-specific assets, manifest, and Gradle build configuration.

10. Native/mobile boundary

The Android app is mostly a thin wrapper over the web application. The architecture boundary is therefore: web app logic in Express + browser-based UI, with Capacitor bridging that into a native Android container. The native code footprint is minimal and does not appear to hold core business logic.

11. Recipe/list content structure

The public/html/libraries/ pages and matching scripts in public/javascripts/books/ imply curated recipe libraries by category. This is a separate browsing subsystem from user-generated content, likely used for recommendation or prebuilt collections.

12. Supporting automation and maintenance

tools/ingredient_updater.py suggests an offline maintenance script for updating ingredient data. This is a secondary operational tool, not part of the runtime request path.

13. Deployment

.github/workflows/fly-deploy.yml and the public Fly.io URL in the README show the app is deployed via Fly.io with CI/CD automation from GitHub Actions. That makes deployment a distinct concern from the app runtime, but still part of the repo’s operational architecture.

14. How data flows through the system

A typical request path is: browser or Capacitor webview loads an HTML page → page-specific JS calls into the Express backend → controller logic processes auth/content actions → MySQL persists or reads domain data → responses update the page, with image/media references resolved through Cloudinary where applicable.