PlatePal — Project Proposal

University project proposal (Exposé) for the PlatePal cookbook app — scope, architecture, and work program.

Task

Development of a cookbook database as a mobile application, as well as an accompanying service for transforming recipe texts into a uniform recipe format.

The mobile application can be considered an MVP for future developments.

Context

The ICW should serve as a starting aid for a larger development project, in which the developed cookbook database app should mature into a complete cookbook and meal-planning app. An important part of the already existing concept is the recipe recognition from different materials: normal text, photos, or websites. The conversion of text forms the basis, which is why it should be worked on first.

Topic Analysis

Market Analysis & Use Case

The idea for the planned application has mainly arisen from personal interest and demand. Although there are already some cookbook and meal-planning apps on the market (such as KptnCook, Whisk, Cookstash, and many more), no application was found that offers all desired features - not even for a fee. The goal is to fill this gap and provide the user with all online features as a paid option. In this way, cross-platform sharing functions - similar to those of Obsidian (https://obsidian.md/ ) - can also be implemented for people who do not want to invest money.

Literature Review

As this ICW is a practical project, little literature is required. However, documentation on frameworks and tools (such as Spring Boot, React Native, Docker, etc.) is likely to be frequently used. In addition, clean code guidelines should be followed during development, as described in “Clean Code,” “Clean Architecture” by Robert C. Martin, or “Effective Java” by Joshua Bloch.

Concept & Technical Implementation

Current Status

The development of the cookbook and meal planning app has already been divided into epics/features to provide an overview of the concept and necessary functions. The following graphic shows this planning.

The epics should be worked on from top to bottom because the included features build on each other.

The recipe recognition epics are shown somewhat separated in this graphic because they can and should be worked on separately. If possible, recipe recognition should be provided as a separate microservice and provide an API for the respective functions (text, web, image).

Epic division and hierarchy
Epic division and hierarchy

For the “recipe database” epic, a feature breakdown was already performed in the sense of MVP development, and a sorted backlog of tasks was created.

As the project has been worked on and planned alone so far, there are also tasks outside of the personal skill range ( especially design, sometimes frontend development). However, since these tasks are intended for an MVP, poor design and/or poor UX would be acceptable for the time being. If the project is continued at a later time, support from other people can also be called in.

Sorted backlog from YouTrack
Sorted backlog from YouTrack

As part of the task “CB-3 Recipe database,” a (not final) data structure for recipes was already planned, based on a random selection of recipes from the personal collection.

In addition, a user database and API security with JWT tokens were already developed in previous projects, so this implementation can be transferred to the tasks “CB-2 User database for email login” and “CB-11 Spring security with jwt” with little effort. Perhaps, over the MVP scopes, a social login via Google and Apple can also be provided through the implementation.

Planned data structure - recipes
Planned data structure - recipes

Delimitation of the Task

Since the development of the app in its entire conceptual scope goes beyond the time frame of an ICW, the focus should mainly be on two epics.

The “recipe database” epic should be implemented on a technical level. “Design” tickets, as described in the MVP feature breakdown, can be worked on but are not considered part of this ICW. This task includes a frontend and a backend application. The communication between these two applications should be implemented but not finalized in terms of a microservice architecture. Separation of, for example, user/auth service, recipe CRUD API, and a possible gateway service is not yet planned.

For recipe recognition from texts, a complete microservice should be created that has a documented and accessible API. Recipe texts should be transferred to the desired database structure through this API and returned in a JSON representation.

The two epics do not necessarily have to be connected, but it is important that the recipe recognition API is testable.

Epics to be implemented
Epics to be implemented

Technologies

As can be seen from the feature breakdown, certain technologies have already been selected for the development of the app:

  • Backend: Spring Boot with Java 11 & Maven
    • Libraries: Hibernate/JPA, Lombok, Mapstruct, Liquibase
  • Frontend: React Native with JavaScript
    • There is hardly any prior knowledge here, which is why any libraries, etc. are still unknown
    • Possible use of React Native Paper for simple initial design
  • Infrastructure:
    • Debian server
    • Postgresql database
    • Possibly Docker or Kubernetes
  • Tools
    • Jetbrains YouTrack for project management
    • Git and GitHub for version control
    • GitHub Actions for CI/CD
    • Jetbrains IntelliJ IDEA as a backend development IDE
    • Jetbrains DataGrip for local database management
    • Jetbrains Webstorm for React Native development
    • Postman for endpoint testing

Software Architecture

In general, a microservice architecture is planned for the entire project. However, Spring Boot microservices require a lot of configuration and server resources, which is why this will only be implemented to a limited extent for the time being. For future adjustments, the user/auth service should already be mostly separated from the recipe CRUD API.

In backend development, care should also be taken to separate the database, persistence, business, and presentation layers from each other. Since the backend mainly provides a REST API, there is no classic “presentation layer,” but rather the data returned by controllers in JSON (or possibly XML) format. The controllers initiate the business logic in services, which in turn communicate with the database layer via the persistence layer (JPA, Hibernate). This is a common structure in Spring Boot applications and ensures that no model objects (JPA entities) can be directly addressed by the client.

Time Frame & Work Program

Given Time Frame

The planned task should be completed during the SoSe 2023. This takes place from April 1st to September 30th, 2023, with the lecture period ending on August 5th, 2023. Therefore, there are 18 weeks available until the end of the first exam period. Approximately 1-2 weeks should be planned for writing a report and documentation.

Work Program

  1. 01.04.–09.04. Frontend and Backend setup for development environment and basic project
  2. 10.04.–16.04. Transfer the user/auth system from previous projects
  3. 16.04.–30.04. Create the recipe data structure and corresponding CRUD API
  4. 01.05.–28.05. Frontend: Login, recipe and collection view, form for recipe creation/editing (including initial design)
  5. 29.05.–25.06. Development of the recipe recognition service
  6. 25.06.–? Writing documentation and report

This work program is a rough guideline and deliberately contains more time (and a buffer) at the end of the semester to avoid collisions during the exam period. The development of the recipe recognition service is still unclear and has not yet been divided into individual tasks. This will be done later and communicated accordingly.