# :gem: Collectrader :gem:

> Developer challenge

## Intro :bookmark:

From collecting post stamps, gaming cards, toys, all the way to trading these unique items, collectables have reached a significant point to collectors around the world.

People collect anything from and search for items that they need to finish their high prized collection, but there is no way of finding these items, categorizing it or buying them online.

In most cases, manufacturers that build and distribute those collectables wish to sell and market their products as fast as possible. Also, they value information like tracking their collectables, who owns them, which groups of people like wearing or collecting their items.

**Collectrader** is the unique online platform for distributing, marketing,
posting, buying and trading collectables.

## System Description :white_check_mark:

- System roles
- _End user_ - consumer of the platform, the ones posting their collectables, buying and selling them, and trading
- _System admin_ - users managing the platform itself, platform administration (ex: adding new manufacturers, suspending users, etc.)

- Functionalities
- Registering on the platform
- Searching through collectables, filtering, ordering
- Posting collectables for purchase
- Buying collectables from other _end users_

- Non-registered users
- Users that aren't registered can only view and search for collectables and register on the platform as _end users_

- User management
- _End users_ need to register on the platform with their email, leave personal information which we need to store
- _System admins_ are "hardcoded" or pre-registered on the platform (that would be developers maintaining the platform) and they have the ability to see all _end users_, their information and suspend them from the platform

- Collectables
- Items or products that the system promotes on behalf of _end users_ and gives the ability to search, buy and sell these items
- Collectables are mostly unique, meaning that there is only one instance of that item, but some collectables aren't that rare (i.e. you can find a batman toy in almost every pawn shop) so that means they can have quantity
- _End users_ can search, buy and post their collectables that they own on the platform

## Specification

### Data

For _end users_ the system needs to store:
- full name
- email
- country, city, address
- date of registration
- date of birth
- IP address
- ID number (format is `ddMMyyyyXXXXXXX` - `ddMMyyyy` is date of birth, `XXXXXX` are 6 random digits)

For _collectables_ the system needs to store:
- name
- brand
- code (auto generated, format `XXXXXXX`)
- category
- date published
- short description (3-6 words)
- full description (10-20 words)
- image URL
- quantity (how many items are in existence)
- price

The system needs to store ownership of a specific _collectable_ for a particular _end user_.

### FRONTEND

**Collectrader**

Use ReactJS for development of frontend.

- Home
- Collectable Details (review, new & edit)
- Payment Page
- Admin panel

Every page has a default header (**Collectrader** label linking to homepage, login/logout button) and footer.
You can find the mockup for each page in this repo.

#### Authentication

This app distinguishes 3 types of users:

- **Non-registered** users can only see the home page and do a basic search (just searching items by their name). They can also register on the platform by clicking the `Login` button. When the user registers, the system needs to log his public IP address, country and city at the time of registering. For this task, please consume the [IPInfo](https://ipinfo.io/) JSON API.

- **Registered** users can do advanced search with more options, they can view item details, buy and post their own collectables.

- **Admins** can review users and ban them for inappropriate behavior. Admins cannot register themselves, they are kind-of hardcoded in the platform itself.

You can use auth0 or some other user service provider or create your own(bonus).

#### Home Page

The homepage has a search field where users can type the collectable that they want to search for. The request should make an call to the backend which needs to search for the items containing the search words.

Additionally, there must be options for **filtering** the results by category, **ordering** by date published and price and **pagination** (`pageNumber` and `pageSize`). These options should be done on the server side.

#### Collectable Details

Collectable details show more details about a particular item.

Collectable details page has 3 modes:
- **review** (just displaying the details about an existing collectable)
- **new** (empty input form for creating a new collectable)
- **edit** (filled input form containing details about a collectable that we want to update)

In **review** mode, every registered user should see the **BUY** button which redirects to the Payment Page.

When a user successfully buys a collectable, he should get an email like this:

Congratulations!

You've bought a(n) {item.Name}. Payment details are:

Item code: {item.Code}
Owner: {item.Owner}
Date: {today}
Price: {item.Price}

If you have questions or aren't satisfied, please send us a message at
[e-mail].

#### Payment Page

The payment page displays a form where the user can input his username and password and confirm the transaction. After that the payment is confirmed and the ownership should change (the payer is the new onwer of the collectable).

#### Admin Panel

The admin panel page is authorized only for _system admins_ (i.e. the link can be `.../admin`). This page shows a table of all _end users_ registered on the system. Every information should be displayed in a separate column. Additionally, there is a **Action** column with **Ban** option to ban a user from the system (because of inappropriate behavior or user is a bot):

|Name|Email|...|Action|
|---|---|---|---|
| Iggy | [e-mail] | ... |`Ban`|
| Samuel | [e-mail] | ... |`Ban`|
| Popay | [e-mail] | ... |`Ban`|

## Create a mock of API for bank (Bonus)

## Technical requirements (IMPORTANT!)

- For storing data use SQL (Postgres,MSSQL,MySQL)
- Queries to the database should be optimized as much as possible (prior to searching)
- Avoid unnecessary data redundancy (storing the same information multiple times without a reason)
- No logic on the frontend part is allowed, only templating and repeating patterns are allowed (listing a list of items with `for` loop, conditional rendering with `if-else`)
- Frontend templating should be done with React

- API specification
- Response body should be JSON formatted
- Status codes need to be appropriate on the corresponding errors (404 if user cannot be found, 409 if he already exists, 422 on failing validation, etc.)

## Bonus Feature

It would be nice to have realtime notifications using websockets.
Design and notification message are up to developer to create.

## FAQ

**Q**: How detailed should the frontend part be? :sweat_smile:

**A**: Not detailed at all :+1:. It would also be nice with plain text displaying the items returned from the backend, like:

- Batman toy
	- Description: blah blah...
	- Price: blah blah...
	...
    
- Mark Twain post stamp
 	- Description: blah blah...
	- Price: blah blah...
	...
    
...

The mockups show an interface which is nice to have. Making the frontend part nice and styled gives bonus points. Of course, frameworks like Tailwind or Bootstrap are desirable, but not required. (see it as additional bonus points)

---