Skip to content

Implementation

Implementation

Please Note

  • This whole section of the documentation is for reference when building the entire application from the ground up and details a logical approach to developing and integrating each of its constituents.

The application is designed to be implemented following the Walking Skeleton approach, allowing for a minimal end-to-end version to be completed early before then expanding upon it, a logical sequence of development is laid out below.

Preliminary

Info

  • A Linux based operation system will be required that has PostgreSQL & pgAdmin installed alongside UV and NPM for package management of Python and JavaScript libraries respectively.
  • A GitHub and Render account will also be required for version control and hosting of the application.
  • A code editor will also be required.

Skeleton

  1. Scaffold Code Repository Structure

    • The code is to be placed under version control in GitHub with a repository that includes the backend and frontend folders as well as a .github/workflows folder to hold infrastructure as code files plus a docs folder to house supporting documentation.

      Please Note

      i.e. this design document, which is a MkDocs application hosted via GitHub pages.

  2. Server Side Initial Setup

    • A Minimal FastAPI application is to be implemented with a health check endpoint.
      • Pydantic, Ruff and MyPy can be integrated at this point.

  3. Database Integration

    • SQLAlchemy is to be used to setup and migrate the database schema for the User table to a PostgreSQL database used for development.
      • Pytest can be utilized at this point to allow for the automated integration testing of the server and database layers.

  4. Authentication

    • The User registration and login endpoints are to be created, allowing for the implementation of the JWT authentication solution using the Authlib and fastapi.security libraries.
      • This is also an ideal time to setup structlog as a logging system.

  5. Client Side Initial Setup

    • A React application is to be initialized with TypeScript & Vite using React Router to create an initial dashboard, allowing for the introduction of Tailwind CSS and Shadcn UI components.
      • Biome can be integrated at this point

  6. User Registration & Login + User Logout Interface

    • A login form is to be created, requiring the implementation of Axios for API queries along with an authentication context using the ContextAPI and the storing of JWT tokens using React Query. A registration form is to also be created, requiring ZOD and React Hook Form for validation.
      • MSW can be utilized now for API integration testing.
      • Initial setup of Workbox for offline capabilities can also be setup now.
      • A hook for logging out users on the frontend should also be implemented at this point as it offers the ability to manually test the registration flow and authentication state of the UI.

  7. User Password Reset Interface

    • As the skeleton of the application offers little in terms of user functionality a password reset method is to be implemented in order to prepare for the likely event of returning users once the app becomes feature rich.

      Future Improvement

      Gmail SMTP is sufficient to handle the email confirmation and password reset flows in the products infancy but as the application scales solutions like SendGrid or Postmark will need to be explored.

  8. CI/CD

    • GitHub actions are to be setup in order to automate builds and release pipelines to production. These pipelines are to ensure Docker containers, that have passed all required validations, are registered on GitHub and then deployed to a hosting provider that offers managed PostgreSQL solutions.

      Info

      Further detail on the required validations can be found in the CONTRIBUTING.md file at the root of the repository.

      Please Note

      The current hosting provider is Render.

Meat

  1. Botanical Group List Interface

    Info

    Will require the implementation of the Family tables: Family, Botanical Group, Antagonist & companion.

  2. Family Information Interface

    Info

    Will require the implementation of the Disease & Pest group of tables.

  3. User Allotment Interface

    Info

    Will require the implementation of the User Allotment table.

  4. User Preference Interface

    Info

    Will require the implementation of the Feed and User Feed Day tables.

    Future Improvement

    This is the first point where offline data synchronization would offer tangible benefit. Cross tab sync for authentication could also be considered here.

  5. Grow Guide

    Info

    Will require the implementation of the: Day, Week, Month, Lifecycle, Planting Conditions and Frequency tables followed by the Variety and Variety Water Day tables.

  6. User Owned Grow Guide Interface

    Info

    Will require the implementation of the User Active Varieties table.

  7. Weekly ToDo

  8. User Profile Interface

  9. User Notification Interface

    Info

    This will require a database migration in order to store a users notification preference.

  10. Public Grow Guides

  11. Monthly ToDo

    Info

    Will require the implementation of the Country Season and Season tables.