352 Milestone‐2 Report

Milestone 2 Report

1. Executive Summary

1.1 Summary of project and current status

1.1.1 Summary

The "Semantic Browse for Cuisines" project is designed to discover, share, bookmark, and comment on the recipes of the cuisines. In a world where the exploration of global cuisines plays a significant role in cultural exchange, our project stands as an inspiration for people who are seeking to expand their culinary knowledge and connections. Our project's goal is to create a user-friendly platform that not only makes it easier to find diverse recipes but also encourages a community of culinary enthusiasts excited to share their culinary experiences.

The core of our project is its innovative method of compiling and displaying recipes from all around the world, making it simple for users to sort through a wide variety of cuisines. Semantic web principles are incorporated into the platform to guarantee that users can find recipes that meet their nutritional requirements, culinary interests, and dietary preferences. This innovative method goes above and beyond simply sharing recipes; it allows users to add comments, ratings, and bookmark recipes which expands the collective knowledge base.

The main goal of "Semantic Browse for Cuisines" is to create a friendly informative, and enjoyable platform where people are able to interact together via their shared love of food and cooking, regardless of their location or cultural background.

1.1.2 Status

In the current stage, we are in the implementation phase of the project lifecycle. Since the first customer milestone, the requirements specification has been updated according to the given feedback and the design phase in the project lifecycle completed by creating class, use case, sequence and activity diagrams. After the completion of these parts, we have focused on the implementation. The team has been divided into sub-teams for development as backend, frontend and mobile teams. Team members with knowledge in these subjects started coding whereas others started learning them.

In the implementation phase, the web and mobile application with user authentication and authorization (including register, login/out) and search functionalities have been implemented, dockerized and deployed. The links for the released repository, the deployed application are available below in the deliverables list.

• Link to the Release Tag for the Application 🔗: https://github.com/bounswe/bounswe2024group1/releases/tag/Group1-Practice-App-Release-v0.1
• Link to the Deployed Application 🔗 : https://semantic-cuisine-wh4f2.ondigitalocean.app/

1.2 List the status of deliverables

Deliverable	Status
Github Repository	Completed ✔️
Deployed Application	Completed ✔️
Class Diagrams	Completed ✔️
Use Case Diagrams	Completed ✔️
Sequence Diagrams	Completed ✔️
Activity Diagrams	Completed ✔️
Project Plan	Completed ✔️
Responsibility Assignment Matrix	Completed ✔️
Meeting Note 8	Completed ✔️
Meeting Note 9	Completed ✔️
Meeting Note 10	Completed ✔️
Meeting Note 11	Completed ✔️
Backend Meeting Note 1	Completed ✔️
Backend Meeting Note 2	Completed ✔️

1.3 Lessons Learned

1.4 Challenges

1.4.1. Frontend

For the frontend, we've decided to use Vite for its speed and excellent developer server. We bootstrapped the project using create-vite with the react-ts preset and started configuration from there.

• We've decided to set up ESLint and Prettier to ensure code quality and consistency.
• We've added Husky to ensure that the codebase is linted and tested before being committed.
• The Boilerplate: We've decided to use shadcn-ui for the UI components and TailwindCSS for styling. We've also added React Router for routing. As shadcn-ui is a custom UI library, we've also added the necessary types for TypeScript.
• For the production setup, we've decided to go with the battle-tested Nginx web server. We have a classical SPA setup where the frontend is served by Nginx.
• For tests, we've decided to use vitest which relies on vite as its backend. This enabled us to have tests run in the same build environment as all the other versions of the application.

Some of the challenges for the frontend were deciding how to write tests. The frontend is hard to test, as its contract is to the user and not explicitly defined. Since our Requirements have no specific UI requirements, testing the UI is done by carefully deciding the contracts of the components and the best ways to test them.

For this, we've decided to go with basic interaction with the UI and observing the effects on global state and the UI again. This created the most reliable and relevant testing environment for our current frontend development process.

1.4.2. Mobile

• Choosing a mobile framework: We chose expo as a mobile framework for our mobile project as it's easy to intialize and configure. Plus it does not require the installation of a mobile device emulator which can be a very tedious proccess.
• Choosing a css framework: Next challenge was to choose a good css framework. Eventually we decided on tailwind because of it's ease of use.
• Typescript or Javascript: We were conflicted between using javascript or typescript for the mobile project. We ended up using typescript because it has a type system.

1.4.3. Devops

The software development lifecycle of a project has a big impact on the efficiency of engineers. Code reviews are a powerful tool for building a shared understanding of the codebase and ensuring that the codebase is of high quality. This is why we've created a Contribution Guide that explains in detail how contributions will be reviewed and merged into the project.

We believe that any time put into DevOps is time well spent in the long run. In this milestone, We've aimed to achieve a multitude of goals in the DevOps domain.

To ensure that developers have the resources to develop efficiently and deploy confidently, a locally reproducible production environment and an easy-to-set-up development environment is paramount. In addition, a well-documented deployment workflow and preferably a CI/CD pipeline reduces the room for mistakes and allows developers to focus on code. It is also generally preferred that infrastructure is declared as code, both to serve as documentation and to allow a project to easily scale/replicate.

We believe that we've achieved most of these goals in this milestone.

We've created a production-like compose setup with an nginx server that serves the frontend static files and reverse-proxies the /api path to the backend server. The backend is compiled into a jar file and served by a java container. The frontend is compiled into static files and served by an nginx container.

We've created a development compose setup with the frontend's vite dev server which reverse-proxies /api to the backend container. The backend uses a maven image to install dependencies and serve a development server (which updates on recompile). The frontend's development server has hot reloading enabled which enables fast iteration.

We've declaratively created our infrastructure for staging and production. We've ensured reproducibility by using docker images for all environments.

Some of the challenges were finding the best practices in the ever-changing landscape of software engineering. There are many articles with old tooling and configuration that is no longer best practice. We've had to sift through these to find the best practices for our project.

1.4.4. Backend

• Choosing a framework: We have chosen Spring Boot as a backend framework because of the fact that most of us prefered Spring Boot over django in poll.
• Ease of setting up and building backend project: For efficient development and test purposes, everyone in the group should have ability to handle the building and setting up development environment of backend project. So our project includes documentation in md format for instructions of setting up and building project
• Determining the version of Java, Spring Boot : As a backend team, we determined the versions as following:
  • Java 17 (More stable and reliable compared to newer ones)
  • Spring Boot 3.1.11 (Well documented and ease of implementation of Spring Security)
• Periodic Wikidata SPARQL Query: Backend team planned to fetch data with using Wikidata Query Service peridically and store these datas in database. So, this periodic data fetching mechanism handled with @Scheduled annotation in Spring Boot which also provides options for time interval between process.
• API Specification : We have defined an API Specification to ensure consistency and clarity in the development of RESTful endpoints, enhancing communication and collaboration among team members.
• Spring Boot Guide and Documentation: General information and configuration documentation about Spring Boot has been prepared to explain the general concepts to team members who lack experience. Documentation Link 🔗

1.4.5. Diagrams

1.4.5.1. Class Diagram

During designing class diagram, we must consider the future development and ensure consistency between diagrams and future backend code structure. So, it took a bit longer time because we reviewed requirements many times and set meetings for get feedback for designed class diagram and rearragned it according to these feedbacks.

1.4.5.2. Use Case Diagram

The main challenge while creating the use case diagram was the looking at the project from the user's perspective. Switching from the system developer approach point of view to the user point of view was a little bit confusing for designing some parts of the diagram. Another challenge was assuring the consistency between the requirements and the diagram, we have made these two consistent via reviewing mechanism within the team.

1.4.5.3. Sequence Diagram

1.4.5.4. Activity Diagram

2. Contributions

2.1 Mehmet Efe Akça

For this milestone, I've tried to contribute to as many areas of the project as possible. I will split my contributions into subsections to delve into them in more detail.

Design - Class Diagrams

As one of the authors of the Requirements, I've worked on the Class Diagrams with Enes. I contributed to the diagrams by cross-referencing and ensuring consistency between the diagrams and the requirements.

SDLC - Contribution Guide

I've written the contribution guide for the project. I've included information about the project's architecture, the development environment, the coding style, and the process of submitting a pull request. It is available here

DevOps

Local docker compose

• I've built the development and production Dockerfiles for the frontend.
• I unified the frontend and backend dockerfiles into two Compose files, one for production and one for development. In the process of doing so, I maintained contact with the backend team to ensure that we were on the same page about the process of setting up the development environment.
• I've done research on the best practices for setting up a development environment with Docker Compose. I've also written the docker-compose.yml files for both the production and development environments. I've also written the Dockerfile for the frontend and the backend.
• I've also ensured that the production environment's Dockerfiles are used in the production-like setup.

Deployment

For the deployment, we've built our infrastructure on DigitalOcean using their Container Registry, App Platform, and Droplets services. I've taken on the role of building the deployment workflow and the infrastructure.

• I've created two environments on DigitalOcean which are the staging and production environments.
• I've set up the infrastructure by creating two droplets where I deployed the database for the staging and production environments.
• I set up the Container Registry for our images.
• After that, I set up the staging environment using the UI and pulled the definition to the Github repository to ensure we comply with Infrastructure as Code principles.
• I then wrote the documentation on the deployment procedures of the application

Frontend Contributions

All of the following configuration items were tracked in this issue:

• I've configured the frontend repository to use ESLint and Prettier to ensure that the codebase is consistent and of high quality.
• I've added husky for git hooks to ensure that the codebase is linted and tested before being committed.
• I've created the boilerplate of the project by installing TailwindCSS, shadcn-ui for UI components, and React Router for routing.
• I've configured vitest for testing the frontend.

I've also implemented the following items in the frontend:

• I've implemented the Authentication logic.
• I've implemented the Search page, and the search bar.
• I've fixed a bug in the login page.

Backend Contributions

I've worked on the SparQL query in the backend to improve the search capability of the project. This was also done in tandem with the development of the API specification in the next section.

API Specification

To ensure that development is smooth and that the frontend and backend teams are on the same page, I've written the API specification for the project.

• There are more details about the standards for this specification in the issue. A summary:
  • The API specification is written in OpenAPI 3.1.0.
  • The specification is based on the Requirements.
  • The specification is hosted in the docker compose setup using Swagger UI.
  • The specification contains the various environments (development, production-like local compose, staging, production) that the application lives in.
  • The specification describes errors and responses in detail.
  • The specification is tracked in the Git repository.

UI Design

I've worked on the UI Design in tandem with Nazire. We re-designed the UI to be more user-friendly and modern. We worked off of the mockups that Asli and Enes had created.

2.2. Ufuk Altunbulak

I've worked on preparing class diagram.

2.3. Nazire Ata

• I worked on UI Design with Mehmet Efe, I was responsible for creating the icons, profile pages, search page, and recipe creation page #64.
• I was not experienced in front-end development, I needed to do comprehensive research on JavaScript and React. The most challenging part was to get used to working with front-end but with the help and patience of my teammate Mehmet Efe, I managed to learn with a hands-on approach. I implemented the signup and login pages #91.
• I wrote most of the Meeting Notes and wrote the template for Milestone 2
• I updated the Requirements based on the feedback for Milestone 1 #67.

2.4. Enes Başer

• Led the backend team, determining the future development plan and code structure.
• Initialized the backend project and implemented configurations for Authentication and Authorization, including Spring Security and JWT configurations. Issue Link : #74
• Developed endpoints and services related to login and signup.
• Implemented JUnit Tests for authentication and authorization.
• Created the Search controller and Wikidata Service, enabling data searches through the Wikidata SPARQL Service. Issue Link : #81
• Implemented Request, Response, and Entity models for the MVP. To manage data updates, implemented a scheduling mechanism for periodically retrieving and checking data from Wikidata for any changes or updates.
• Alongside Mehmet Efe, prepared and added Docker configurations for both development and production environments. Issue Link : #76
• Prepared README.md for setting up and building backend app. Issue Link : #88
• Prepared Backend Roadmap and Resources for Spring Boot Issue Link : #87
• Created the class diagrams Issue Link : #71
• Commit history for implementation tasks : Commit history link 🔗

2.5. Çağatay Çolak

2.6. Aslı Gök

• Created the use case diagram and finalized according to the review feedback of Mehmet Efe. Issue link : #79
• Reviewed the UI Design prepared by Mehmet Efe and Nazire.
• Updated the Responsibility Assignment Matrix for the milestone. Issue link : #109
• Haven't involved in the code implementation yet, still in the learning phase.

2.7. Boray Kasap

2.8. Yiğit Memceroktay

• For milestone 2, I mainly worked with the mobile project. I was responsible for configuring expo and implementing the designs for the mobile pages and adding functionality to them. I was also responsible for creating the activity diagrams for the workflow of the project.
• I initialized and configured the expo framework for the mobile project (language, folder structure, linting tools, file management system).
• Implemented the design for the Registration, Sign Up, Home and Search pages.
• Added login functionality, registration functionality and search functionality to the corresponding pages.
• Initialized and configured nativewind as a css framework for the design of the project.
• Implemented the design of react navigation to navigate between tabs for current and future use.
• My issues: 68,78, 84, 85, 86, 99, 106
• My pull requests: 97, 98, 100, 107
• Created the activity diagrams for cases such as: login, registration, user interaction (like, bookmark etc.), search function, recipe management, feed management.

2.9. Yüksel Eren Şen

2.10. Atakan Yaşar

• As a part of the backend team, discussed about backend implementations, tried to solve bugs with Enes Başer.
• Contributed and reviewed class diagram.
• Arranged Project Roadmap
• Researched on Docker to build backend on local environment.
• Set up Github Action workflows to automate the build