Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Full Stack Assessment Project v2 upgrade #454

Merged
merged 43 commits into from
Apr 3, 2024
Merged

Conversation

sztupy
Copy link
Contributor

@sztupy sztupy commented Jan 27, 2024

This is the proposed v2 update to the Full Stack Assessment Project. Main changes:

  1. Use a monorepo approach based on textbook/starter-kit/v2, but stripped down with some parts removed to make it lighter and easier to navigate. These includes a much smaller package.json file with less available commands, no support for test coverage, plain console.log logging instead of morgan, no built-in support for helmet, and removed most of the deployment targets, keeping Netlify only.
  2. Reorganized the assessment based on features instead of splitting it alongside frontend and backend. Week 1 is an MVP, Week 2 adds video embedding and the add/remove functionality, while Week 3 ends with ratings support
  3. Optional features have been reorganized and expanded, one part code style improvements: linting, unit tests, e2e tests. The other part are better error handling. There are still a couple small optional product features as well.

Note that the scope of the mandatory part of the project mostly remains the exact same as before, but there are some new requirements:

  1. Deployment is now mandatory, with most of its setup happening during Week 1. Deployment setup is toward Netlify and Supabase using the proposed updates to the deployment section in our curriculum: Add guides for deployments curriculum#515
  2. Data validation is now mandatory on the backend side for the "Add video" feature. (It is technically still optionali, but strongly recommended through the frontend)
  3. Ratings now have to be persisted to the database through the API (this was theoretically already a requirement, however due to how the assessment was worded on the backend side it effectively became an optional feature accidentally)

The core repository also contains some predefined files for the frontend, backend and e2e tests to get the trainees a starting point, especially as we don't really teach them how this is done.

To check how the solution could be done I have prepared a repository, including all potential PRs between levels to assess difficulty:

Thanks to Netlify this also allows one to check each of the levels separately as deployed, which is cool:

This is the proposed v2 update to the Full Stack Assessment Project. Main changes:

1. Use a monorepo approach based on `textbook/starter-kit/v2`, but stripped down with some parts removed to make it lighter and easier to navigate. These includes a much smaller `package.json` file with less available commands, no support for test coverage, plain `console.log` logging instead of morgan, no built-in support for helmet, and removed most of the deployment targets, keeping Netlify only.
2. Reorganized the assessment based on features instead of splitting it alongside frontend and backend. Week 1 is an MVP, Week 2 adds video embedding and the add/remove functionality, while Week 3 ends with ratings support
3. Optional features have been reorganized and expanded, one part code style improvements: linting, unit tests, e2e tests. The other part are better error handling. There are still a couple small optional product features as well.

Note that the scope of the mandatory part of the project mostly remains the exact same as before, but there are some new requirements:

1. Deployment is now mandatory, with most of its setup happening during Week 1. Deployment setup is toward Netlify and Supabase using the proposed updates to the deployment section in our curriculum: CodeYourFuture/curriculum#515
2. Data validation is now mandatory on the backend side for the "Add video" feature. (It is technically still optionali, but strongly recommended through the frontend)
3. Ratings now have to be persisted to the database through the API (this was theoretically already a requirement, however due to how the assessment was worded on the backend side it effectively became an optional feature accidentally)

The core repository also contains some predefined files for the frontend, backend and e2e tests to get the trainees a starting point, especially as we don't really teach them how this is done.
db/initdb.sql Outdated Show resolved Hide resolved
package.json Outdated Show resolved Hide resolved
server/api.js Outdated Show resolved Hide resolved
@Dedekind561
Copy link
Contributor

Dedekind561 commented Apr 3, 2024

Hi @sztupy ,
Many thanks for all your thorough hard work on this PR! 🙌 The way you've revamped this project to focus on features and deployment is exactly what we needed! As this needs to be used soon, I've committed some grammar changes, copy edits and general reformatting directly to this branch. I've also added acceptance criteria to the level 2** features for consistency and clarity of requirements.

Copy link
Contributor

@Dedekind561 Dedekind561 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀 An excellent revamp on our old project. Let's start iterating...

exercises/100.md Outdated

## Monorepo

The project is set up to run as a monorepo, where both the client's and the server's code are in the same git repository and are linked together. When doing monorepos there are some boilerplate code required to make sure both the frontend and the backend application can work at the same time and on the same URL. To kickstart your development we have set up this boilerplate code for you already. Feel free to look at the code, but generally you won't need to edit them at all if you follow the proposals on this guide.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The project is set up to run as a monorepo, where both the client's and the server's code are in the same git repository and are linked together. When doing monorepos there are some boilerplate code required to make sure both the frontend and the backend application can work at the same time and on the same URL. To kickstart your development we have set up this boilerplate code for you already. Feel free to look at the code, but generally you won't need to edit them at all if you follow the proposals on this guide.
The project is set up to run as a monorepo, where both the client's and the server's code are in the same git repository and are linked together. When using monorepos, some boilerplate code is required to ensure both the frontend and the backend application can work simultaneously and on the same URL. To kickstart your development we have set up this boilerplate code for you already. Feel free to look at the code, but generally you won't need to edit them at all if you follow the proposals in this guide.

server/api.js Outdated Show resolved Hide resolved
@Dedekind561 Dedekind561 merged commit ec777b3 into CodeYourFuture:main Apr 3, 2024
1 check failed

**Overview**

Following feedback on the MVP, this iteration focuses on enhancing user experience through embedded videos, improved design, and accessibility considerations.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be good to know whether we want to have a "dry" approach to the descriptions and user stories or a more example based approach. The old level 200 description (and the original PR) aimed more for the example based approach like the following:

Your MVP has been well received by your friends, but they found it lacking in some regards. The main comments you received were:

- They found clicking on the link and getting redirected was not convenient, they got lost while opening up the tabs
- They said the styling of the page was not too welcoming, and suggested you add some colours to it.

This has been retained in later levels, like the one in level 210. I generally feel we should keep a more lighthearted style, but if that's not how we should do we should change the other levels to be more dry as well.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keep the jokes ;)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll create a PR to get them back in

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sztupy The requirements you documented in levels have now been captured as issues on this board, in line with the structure of the other module products: https://github.com/orgs/CodeYourFuture/projects/169/views/2
I've put some of the lighter material back into the issues but if you want to check/add more, add them back to the issues, thankyou!

"id": 523523
}
```

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would retain the old note here:

**Note:** You don't need to adhere to the examples above. In fact if you started working on the level 199 feature "Proper error handling" you will likely going to use a different response.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants