Milestone 2 Report - bounswe/bounswe2023group7 GitHub Wiki
- Fatma Sena Alçı
- Yunus Emre Altuğ
- Ömer Şafak Bebek
- Melih Gezer
- Muhammet Tayyip Kamiloğlu
- Hakan Karakuş
- Elif Kızılkaya
- Marcel Namyslo
- Mehmet Tuluyhan Sözen
- Furkan Ülke
- Güney Yüksel
As Group 7, our project is a gaming community platform designed for users, including developers, gamers, and e-sports players, to connect and collaborate. It offers a forum for users to create posts, and share game guides, tactics, and reviews. Developers can promote their upcoming titles, and users can find friends and form teams through a group-finding feature. The platform facilitates the organization and promotion of online and offline gaming events. It includes a search function with semantic search capabilities for posts, users, developers, and e-sports players. The platform also provides personalized recommendations based on user activity and interests. Additionally, there is a native Android application with a user-friendly design. Users can annotate content with text or image annotations, and ethical considerations such as privacy, copyright, and licensing are prioritized, following GDPR/KVKK regulations.
As a team, in this milestone, we worked together to develop a web application utilizing APIs. Our main objective was to gain practical experience in team development practices using GitHub. Each team member is tasked with selecting and integrating at least one API of their choice while also creating an API function. Throughout the development process, we collaborated closely, extensively utilizing our project repository. By working together and leveraging our collective skills, we developed the web application and API with a simple user interface, creating a valuable tool for collaboration. We planned diligently, communicated effectively, and supported one another to achieve our shared goals.
Since the beginning of this term, we worked on our Game Community Platform step by step. We began by identifying the requirements and categorizing them into sections. Whenever there were questions regarding the requirements, we asked our teacher and teaching assistants to clarify. Subsequently, we created mockups and scenarios to illustrate the basic user interactions within our app. For a detailed implementation plan, we developed class-user-sequence diagrams. To monitor our progress, we devised project plans and a Resource Allocation Matrix (RAM). All of these works can be seen on our Milestone 1 Report.
A significant research aspect of our implementation involved becoming proficient in Git and GitHub, considering the multitude of pull requests, issues, and merges. As a team, we learned how to use Git as many of us were not experienced with it in this sense. Also, everyone did research on APIS, and selected frameworks. Additionally, we conducted meetings to determine the most optimal tools for our app, ultimately selecting React and Node.js frameworks. Each team member chose a public API as their desired, if there is any unclarities, we asked our teacher and teaching assistants. Some of our team members chose not to participate in the project because of personal reasons. Starting with the backend, each team member decided and implemented their own required endpoints. Afterwards, everyone made their unit tests for each endpoint. We conducted thorough testing, including manual tests using Postman, to ensure the functionality of our endpoints. Subsequently, each team member focused on implementing the user interface for their respective endpoints. Finally, we diligently documented the API and summarized our achievements in the Milestone report.
In our practice app, everyone chose a public API and decided their functionalities on their own. We will explain chosen APIs and functionalities separately.
-
Location: The Abstract API’ IP Geolocation API has been implemented, allowing users to retrieve their location (city, country, region, postal code, current time, country flag) based on their IP address. Additionally, functions have been developed to add this location to the user's location history and enable users to view their location history upon request. In order to access the location history and add location information to the history, users are required to log in with their email address. However, it is possible to view the current location without logging in. You can access the page using the button named Elif Kızılkaya from our home page.
-
Event: Since our practice application is some sort of Game-Event Platform, there are main components included alongside the user such as games and events. Each user can create an event by providing required fields and then list events created throughout the application. To create an event providing valid event time, event date, and event location is enough. Our application connects to Geocoding API to fetch coordinate addresses and stores provided information and returned API response in database to further retrieve and list the entries.
-
Favorite Games: The user should go /favorite-games page in our application and he/she should be authenticated to use favorite games feature. If the user is not authenticated, the user is navigated to sign in page.The user can search games in this page and can click on the games which come from search to add the game to his/her favorite games. Favorite games of the user are listed on the right of the page. The user can click on the games to remove the game from his/her favorite games.
-
Authentication: The user can register to our application by using signup page. The user should provide a valid email, username and password. The user can be authenticated if the user logins to the application. The user can use login page to login to the application. The user should provide his/her username or an email besides the password.
-
Streaming Games: The chosen API is the Twitch API, which provides access to data related to Twitch's streaming platform. With the Twitch API, developers can interact programmatically to retrieve information about games, streams, users, and more. The implemented functionalities in this code focus on retrieving and storing data about the most viewed games on Twitch. The first function retrieves data about the currently most popular game on Twitch. The second function saves the retrieved data along with the current date and time. The third function retrieves all previously saved games from the database, including their saving dates.
-
Game Platform: Also mentioned in the interface: "Game Platform by Altug". At this platform you can get platform of the game you searched. First user sees two buttons which are "search game" and "post platform". If user clicks "search game", user will encounter a form and button. At this time, the user should enter which game he or she searched. If system finds game at least one, new page will be loaded. On the page, there will be 1-10 buttons. The user should pick one of them and wait for the platforms. If the user has one of the seen platforms, there will be a message like that "You have these platforms to play this game:{platform}. Otherwise, there will be a message like that "You do not have any". To add the platform, "post platform" enables the user to add a platform to his or her account. A user can add more than one platforms. By clicking "post platform", the page loaded with search form and submit button. If the user gets "submission successful" message, the platform is added to account.
-
Genres of Games: RAWG Video Database API helps to reach a lot of data about video games. Genre API is also one of them. Using Genre API, registered or non-registered users can reach game genres and a number of games for each genre. In addition to being useful for professionals in the gaming industry, the Genre API can also be a valuable resource for gamers themselves. By accessing this API, gamers can easily find games that fall within their favorite genres, and discover new genres; all she has to do is click the box on the frontend page!
-
Game Prices and Stores: CheapShark API helps to a variety of data of both games and game stores. You can search for available game markets and also the games they are selling. It compares the game prices and finds the best price among them. In addition to being useful for professionals in the gaming industry, the CheapShark API can also be a valuable resource for gamers themselves since one can buy the game he/she wanted at the lowest price possible. By accessing this API, gamers can easily find games, their sale ratios, etc. You only need to be signed in, then you search for a game, you add it to your cart, you can view this cart and also you can check the current active stores in the market. All of them take only one click!
-
Random Game: This API suggests a random game using the Steam API. When a POST request is sent to the "/random-game" endpoint, the API selects a random game from the Steam library and adds it to the user's history using the "randomGame" schema. This endpoint also saves the game to the database. In addition, when a GET request is sent to the "/random-game/history" endpoint, the API retrieves a list of the user's previous random game suggestions from the database. This API can be a perfect choice for gamers, as it provides them with an opportunity to discover new and interesting games by offering random game suggestions. By storing the user's history, previously experienced games can be listed, and suggestions can be further personalized. Developed using technologies such as the Steam API and MongoDB, this API has a modular and easily expandable structure, making it easy to integrate and customize to suit the needs of different applications
-
URL of practice app code: https://github.com/bounswe/bounswe2023group7/releases/tag/Group7-Practice-App-Release-v.0.1
-
The tag: Group7-Practice-App-Release-v.0.1
-
URL of the deployed application: http://52.59.238.73:3000
-
Any information that you may need to test our application:
- You can test our application simply by going to the URL that is provided above. Some of the api functions can be used only by authenticated users. You can use signup and login pages to authenticate yourself. If you want to run our application in your environment, you can follow the instructions below.
-
Instructions for building the application with docker:
- You should install the Docker Engine.
- Clone our repository.
- Add appropriate .env files to server and client folders which are in the practice-app folder. (You can inform us if you need this files.)
- Run
docker build -t practice-app-backend .command in the server folder and rundocker build -t practice-app-frontend .command in the client folder. These commands are used to build images for backend and frontend. - Run
docker run -d -p 8080:8080 practice-app-backendanddocker run -d -p 3000:3000 practice-app-frontend. These commands will run two containers. These commands are used to run our application and api. - You can access to our api by localhost:8080 and our application localhost:3000 base urls. The swagger documentation will be available in localhost:8080/docs
-
Base URL of our API: http://18.185.125.88:8080
-
Swagger Docs URL of our API: http://18.185.125.88:8080/docs
In addition to these meetings, we met face-to-face to code together.
We had to utilize a variety of tools as we were creating our project to accomplish our various goals. There were several factors to consider when deciding which tool to utilize for a task. We always had to divide duties amongst ourselves so that each member could contribute, thus it was crucial that the tool allow us to work together and quickly see each other's work. Since we had no prior knowledge and had to learn as we went, another requirement was usability. A brief overview of the tools we utilized, their function, and our evaluation will be provided in the subsections that follow.
Our primary means of contact were Discord. We set up various text channels for purposes such as meeting notes, research materials, general conversation, and random talk for all team meetings. Discord is simple to use and many of us were already familiar with it, so we found it to be helpful as our primary communication medium. Particularly helpful features included having distinct text channels and several audio channels within the same group. In addition to these, creating distinct threads within a single text channel for each meeting or study topic made our channel simple to navigate and structured. Overall, Discord offered all the fundamental attributes we needed in a team communication setting.
Our progress and deliverables can be accessed on the GitHub repository, which serves as a comprehensive portfolio of all the work we have accomplished. Within the repository, you can find information about our team, as well as the design and research we have conducted, which is in the wiki section. The repository also provides insight into what to expect from our project and who has worked on each task through the regularly updated issues. We have found GitHub to be an indispensable tool for our project because it allows us to collect all our work in one location, including tasks related to design, documentation, research, assignment tracking, and reviews. As the project progresses, we plan to utilize GitHub's version control features, such as committing changes and merging branches. We have found that GitHub is particularly valuable during the design phase, and we anticipate it will be essential during implementation. Although other tools, like Bitbucket, offer similar features for version management, we prefer GitHub because it allows us to merge version control and information wiki in one location and provides excellent user interaction for both contributors and observers.
In terms of project documentation tasks, we utilized the Wiki section of our GitHub Repository. This allowed us to work on our individual parts and check change history easily. Since most of our documentation deliverables were meant to be published on the Wiki, this made our task easier, and we didn't have to migrate to another platform. However, for more detailed reporting tasks like the Milestone report, GitHub Wiki was not sufficient. We required a platform where all team members could work simultaneously for longer periods without version conflicts. Therefore, we found Google Docs to be the most suitable tool for such tasks. Google Docs is easily accessible, and we are all familiar with its use, which provided excellent collaboration with synced work and commenting features. One drawback of Google Docs was that with tables and images, we encountered the issue of position stability. As more content was added above, the design changed, but given that 11 people worked on the same document simultaneously, this was an understandable issue and did not pose a significant problem for us.
Node.js is a back-end JavaScript runtime environment that is open source, while Express.js is a free and open-source back-end web application framework designed for use with Node.js. When developing the back end of our application, we decided to use Node.js and Express.js for the following reasons: both technologies are highly prevalent in the industry, resulting in an abundance of resources such as tutorials, Q&A forums, code examples, and implementations. Furthermore, since we were new to the realm of real-world server implementation, we opted for comparably simpler technologies for the back end. Our team members initially familiarized themselves with JavaScript syntax, then learned about the Node.js runtime environment before gaining practical experience with the Express.js framework, including its routings and controllers. Additionally, we utilized the modularity of the project setup to separate models, controllers, validators, routers, and so on. We also made use of external packages, such as Joi for model validation, in required places. The availability of many helpful packages and features is a direct result of the widespread use of Node.js and Express.js (which are based on JavaScript).
React.js is an open-source front-end JavaScript framework that uses a model-view-view model architecture for developing user interfaces in web applications. Initially, we narrowed down our options for front-end development to two choices: React.js and Vue.js. After discussing it among us, we eliminated Vue because it had fewer functionalities compared to React. Although none of us had experience with React.js before, we decided to challenge ourselves and learn it. We believed that learning it would be beneficial for our future careers since it is a popular and growing framework. We created a main app and routing file at the core of the project, and then created separate branches for each unique feature, implementing these screens under the '/client' directory. We mostly used JavaScript to create the corresponding components and screens.
Postman is a platform that developers use to design, build, test, and improve their APIs. With over 20 million registered users and 75,000 open APIs, Postman is a popular and widely used application. We chose to use Postman to test our APIs for several reasons. Firstly, it is free to use individually, which was a big plus for us. Additionally, Postman provides easy documentation, which helped us prepare our documentation. As the most popular API testing application, many of our team members already had experience with Postman and those who didn't learned how to use it quickly. We tested our APIs using Postman and shared Postman documentation links in our issues. We also plan to create a wiki page where we will include those Postman documentation links. These links include examples of failing requests, successful requests, and corresponding request bodies. Every request also includes an example response, making them easy to understand and use.
We required a database management system to store and manage our data to make sure that our practice app was useful and maintainable. We compared options like MySQL, MongoDB, and PostgreSQL before settling on MongoDB because of its widespread use and powerful features. While some team members were already comfortable with MySQL and SQL, many of us were eager to learn MongoDB due to its widespread use in the sector. Additionally, MongoDB is more adaptable than other database management systems, enabling us to deal with document-oriented data rather than tables and rows and to store lists as fields. We eventually completed our sample project by employing MongoDB's document-based collections, even though it took some time to get used to using it.
In our project, we utilized Docker as a containerization tool. Docker proved to be highly beneficial, simplifying deployment and scalability while ensuring consistent environments across platforms. Its isolation capabilities enhanced security, and the extensive repository of pre-built images expedited development. Docker greatly contributed to the success of our project, allowing us to efficiently manage our application stack and streamline the overall process.
By utilizing the EC2 service provided by AWS, we successfully deployed two instances for the backend and frontend in the Frankfurt region to host our practice application. EC2 (Elastic Compute Cloud) offers scalable computing capacity in the cloud, allowing us to provision virtual servers and run our application on demand. Additionally, when setting up our MongoDB database, we chose the AWS Frankfurt option for hosting. By selecting Frankfurt as the region for our MongoDB deployment, we benefit from localized infrastructure and reduced network latency for our database operations. AWS offers a reliable and scalable database service with MongoDB, allowing us to seamlessly manage our data in a secure and high-performance environment. Leveraging the Frankfurt region provided by AWS, we ensure efficient data storage and retrieval for our practice application, meeting the needs of our users in that specific geographic area.
Throughout the semester, we maintained our consistent communication plan for the development and planning of our practice project. After the spring break, we convened weekly on our Discord channel or face-to-face to discuss the project's progress and upcoming tasks. Prior to each meeting, we prepared an agenda outlining the topics to be addressed, forming a structured meeting plan. We commenced by reviewing the previous week's work, and evaluating the current state of the project. To facilitate better visualization and collaboration, we utilized Discord's screen-sharing feature whenever necessary. During these sessions, we effectively collaborated on tasks requiring joint effort. To ensure comprehensive documentation, one team member took meeting notes, which were later uploaded to our GitHub repository for easy reference. It was during these team meetings that we made important decisions for our project, including the selection of technologies to be employed. Furthermore, we fostered a peer learning environment, providing support and assistance to one another in areas where challenges arose. When implementing the practice application, we organized coding meetings to code and learn together.
Whenever we encountered questions or uncertainties regarding our tasks or completed work, our teaching assistants and teacher were readily available to address our queries and provide clarifications. We had the opportunity to ask our questions either in person or through our dedicated Discord channel. Following these discussions, we incorporated the necessary changes and updates to our project based on the feedback provided by our teaching assistant. Specifically, for the practice app, our TA shared online videos focusing on Docker and deployment, allowing us to gain valuable insights and guidance. Although the feedback received was more general in nature, it provided us with helpful tips to progress further with our project.
Our team has successfully employed GitHub issues as a robust task management system for our project. By assigning dedicated reviewers to each issue and applying colored tags based on various criteria such as type, status, priority, and effort, we have streamlined the tracking and management of our progress. Furthermore, we have implemented a standardized issue template, created by Melih Gezer, to maintain consistency in the reporting and handling of issues by adding issue descriptions, tasks, extra comments, the final step, deadline, reviewer, and deadline of review. Overall, our utilization of GitHub's issue management features has proven to be well-structured and efficient, catering to the specific requirements of our project.
As our project became more focused on code implementation, pull requests played a significant role in our project management approach. To maintain a systematic structure, each team member created their own branch with a predetermined name format, such as "practice-app/feature/." This practice of creating separate branches for each feature and enhancement proved invaluable in organizing our work and minimizing conflicts. Additionally, we linked issues with pull requests to further enhance our project's organization. We found GitHub's pull request system to be highly beneficial for version control and particularly effective in managing a project with multiple contributors working on overlapping areas.
Initially, we faced a significant obstacle in learning new concepts, libraries, and programming languages that were necessary to develop the practice app. This was mentally exhausting and time-consuming, but we were able to overcome it by effectively communicating with each other using various technologies and holding productive meetings.
The second major challenge we encountered was deciding which framework to use for the project. Since there was no framework with which we were all familiar, we decided to go with Node.js for the backend. However, this required a lot of research and practice, and we had to rely on more experienced members of our group to teach and demonstrate how to work with the framework. In addition to this, we encountered some difficulties while working with external APIs.
Finally, we faced issues while implementing the frontend part, which was designed to present our work in a visually appealing manner using React.js, a progressive JavaScript framework. In addition to the technological challenges, we also had to deal with an increase in workload per group member as the number of group members decreased from 11 to 9 over the course of the project.
In general, we encountered these issues because the subject matter and tools were all new to us, and we had to venture out of our comfort zones to learn new things. We were able to overcome these challenges by working together and supporting each other. Although it was a difficult journey, we ultimately achieved a very satisfying outcome.
-
Hakan Karakuş
-
Marcel Namyslo
-
Güney Yüksel