Basic information

There will only be one team project in the second half of the semester. Each project will get developed by a team of three or four students (teams of four students are preferred). These students do not have to attend the same seminar. 

The purpose of the team project is to learn to work and cooperate in a development team. You will be developing a complex project from start to end. It will require you to divide work between team members, similar to real work scenarios.

The only deadline for the project is the date of your presentations. Presentation dates will be published towards the end of the semester / during the exam period.

After successful project development, you will present your project to teachers. During the presentation, all members of the team have to be present. The presentation will be roughly 10 minutes long, as there needs to be room for questions from teachers. The presentation consists of a project demo to showcase how the project fulfils the assignment requirements.

Project registration, topics

There is a list of project topics and their short specifications in the IS. You can find it in the section “Student” > “PB138” > “Lists”. 

The enrolment starts on 04/04/2023 at 8 pm. Only one student can enrol on each topic, so please, choose a single person from your team who will try to register on your chosen topic.

After 24 hours, we will make the topics available to 4 people each. That’s the right time for all team members to enrol on the topic your team leader has enrolled on before. If you haven’t found a team yet, you can use the “looking-for-team” channel on Discord. After 14 days, you will not be able to change topics/teams in the IS. Any later changes will need to be made with your tutor's approval, and they will be done by your tutor in the IS.

There are enough topics for all students of the course, but if you have your own idea (it can be inspired by some existing website or app), let your tutor know - best is to prepare your own assignment; the format needs to match the format of the assignments published by us. Your tutor will check your topic and (hopefully) approve it, or they will request some changes to the assignment. After approval, your requested topic will be yours - you will be automatically enrolled on it by your tutor.

Project requirements

Git remote location, teacher access

The projects must be hosted on faculty Gitlab. Your projects must remain private. Moreover, you need to add xgrolig, xorsula1, xwehrenb and xkastovs to your projects, so the reviewers can look into your code during/after the presentation. If you wish to use this project as a portfolio, we advise you to hook up a mirror repository somewhere else (often Github or a different Gitlab instance).

General requirements

We require your code to be written in a certain way. The code must be readable and up to standard with your code from iterations. This means you must be using TypeScript, have type definitions in your code (and avoid using any and unknown types), have strictly set linting (at least in the pipeline), use modern approaches in your code (such as functional paradigm in TS), and correctly use decomposition in your frontend and backend code (single-purpose files, modules, and layers [Such as database layer, REST layer, ...] in your apps). Every application's graphical design must be responsive - think mobile-first to allow at least core functionality to be user-friendly on mobile devices (smartphones, tablets).

We encourage you to set up CI/CD pipelines for your project (your pipelines should have at least lint and test stages).

If not said otherwise in the project topic/assignment description, you are required to use some form of data-persistency solutions (we suggest you stick to using databases) to save the user/admin data.

Tech stack

When selecting a tech stack for a project, it's important to consider your own expertise and skills, as well as the requirements of the project itself. However, in this course, we cannot allow complete freedom in this regard. Not only would this compromise the quality of project evaluations, but we also do not have expertise in every solution available in the rapidly expanding WebDev world.

Here is the approved Stack, in which we can provide advice, tips, and tricks, and you will definitely be able to build any of our listed projects using it. If you feel that a different stack would be better suited for your project, you can suggest it, and if it is approved, you can use it. However, these will be exceptional cases, and we will not approve, for example, a frontend in Angular when we are teaching React in this subject and similar proposals.

Frontend

You should develop the frontend primarily as a Single Page Application in React. For styling, you can use either plain CSS, some CSS preprocessors, or Tailwind. To assist with styling, you can use some pre-styled components, but only for inputs, dialogues, and notifications. The goal is to make it easier for you to develop inputs, which can be very demanding. We do not want to see complete layouts from libraries, however.

When selecting a framework for your team, it's important to take into consideration everyone's agreement and skill level in web development. While frameworks like Remix or NextJS can be viable options, it's crucial to ensure all team members can use them effectively, especially as they haven't been covered in the course. Ultimately, the goal is to select an option that will enable the team to work efficiently and collaboratively while also ensuring that everyone has the support and resources needed to succeed. Additionally, it's always a good idea to consult this with your tutor.

• React 18
• Styles - CSS, SCSS, Tailwind
• Styled components - MUI, Daisy UI, FlowBite, Headless UI…
• State management - Recoil, Jotai, Redux, Zustand…
• Client routing - React Router, Tannstack Router
• Backend communication: Axios, React Query, SWR
• Forms - Formik, React Form Hook

Communication

For communication between the backend and frontend, you should be able to manage with Rest API, GraphQL, or possibly tRPC (however, at your own risk, as it will not be covered in this course) - you will need the tutor's approval for this. If you need real-time communication in your project, use WebSockets, but most projects do not require this, so Rest API or GraphQL is a sufficient solution. For authentication during communication, you can implement it using Cookies (provided by us) or JWT tokens (if you have the knowledge).

• Rest API, GraphQL
• tRPC (with tutor's approval)
  
• WebSockets

Backend

The backend should be written in TypeScript, and we recommend using Prisma to connect to the database (or TypeORM if you have experience with it). If you have some very demanding queries in your project and know that you would encounter limitations with the ORM, you can use QueryBuilder KnexJS or another tool according to your experience. However, most projects can be handled very well using Prisma - and we recommend doing so to avoid learning another library/technology/paradigm.

• Express
• Connection to DB - Prisma, TypeORM, Kysely…

Database

Most of the projects are suited for a relational database, and in such cases, we strongly recommend using PostgreSQL. If your project really requires a NoSQL database, then we recommend MongoDB. They are both open-source databases, offer very high-quality documentation, and can be easily used in Docker.

• PostgreSQL, MongoDB

Other useful libraries for both the frontend and the backend:

• Datetime - DayJS, date-fns, Luxon
• Validation - Yup, Zod

Presentation

There will be time slots available in the IS for your presentations. Your team leader will enrol for a time slot of your team's preference. The presentations will be held online via Zoom or Google Meet (the link will be enclosed in the description of the time slot).

The presentation should be roughly 10 minutes long, but not longer. After your 10 minutes, there will be another 5-10 minutes for questions, discussion, code review and final evaluation.

Each member of the team has to attend your presentation.

Recommended structure of your presentation is as follows:

Introductory slides: briefly introduce your topic, selected technologies, as well as your team and responsibilities. A few slides (let's say 3-5 slides) are optimal. Do not make your slides too long; this is not the primary part of your presentation.

Demo of your application: show us your result, how it works, and the required functionality. Basically, show us how we can use your result and what your result is capable of.

Workflow/codebase: one after another, present your role in the project. Mention what part of the codebase you were working on. Feel free to show us your code; choose the most interesting part of your codebase => either the most challenging one or the one you are most proud of. You can also mention some problems you encountered and how you dealt with them.

Final notes: no need to be nervous about the presentation. Consider it a discussion about your project and (if there's enough time) things you learned during the semester. Remember, you don't need to show us everything - if there are parts of your code that need some additional work, you can just skip them or tell us how you would improve them in the future. This is not something we would penalize in the evaluation.

Recommendations

Work agile and iteratively. Choose your scrum master - the person with the best social skills in your team. This person will act as a mediator during discussions, manage tasks necessary to accomplish the project's assignment and keep the group going.

The next role in your team should be an infrastructure specialist. This person will prepare a docker development environment, set up a CI pipeline, and create a testing and deployment infrastructure.

In developer roles, you will need to cover both the backend and the frontend. Choose according to your preferences.

One person doesn't need to stick to one role. Discuss your roles in your teams and stay flexible. We do not require you to have fixed development roles. However, it is usually the best way of working in practice.

Never forget to test your stuff when you commit it. Pair review your code - use merge requests for reviewing your colleagues' work. Someone who has not worked on the feature should do the final testing rather than the one who developed it.

Leave yourself enough room to work on the project - it can take well over a month in some cases. Project management, honest expectations, and fair, periodical work is the correct way to approach this project.