This is a Game of Thrones inspired REST API game. You are responsible to create the engine of the game.
- ✅ Implement the endpoints in ./src/api.js file with the most suitable code for players and objects management REST API. You will find detailed instructions in this file.
- ✅ Write some tests for your code. Use test folder for this purpose.
- ✅ Answer all commented questions you find in the code.
You have to create endpoints (as many as you consider) to support the following functionality:
- ✅ List all players.
- ✅ Create player: adds a new player to data source.
- ✅ Get player by id: returns the player for the given id.
- ✅ Arm a player with an object in its bag.
- ✅ Kill a player: sets player health to 0.
- ✅ Create object: adds a new object to data source.
- ✅ Get object by id: returns the object for the given id.
- ✅ Upgrade object: increase/descrease the value of the object given by id with a new value
- ✅ Destroy object: remove an object from available objects
Bonus:
- ✅ Include a postman collection in utils folder to test the app.
- ✅ Add basic authentication to /api path.
- ✅ Implement pick up item endpoint: one player add to its bag one item that doesn't belong to any other player.
- ✅ Implement attack player endpoint: one player attacks another player using an object from its bag. Adjust health accordingly
- ✅ Implement steal bag from player endpoint: one player steals everything from another player. Bag objects are moved from one player to another.
- ✅ Implement resurrect player endpoint: bring back to life a dead player using its id.
- ✅ Implement use object endpoint: a player use an object against another player or itself.
- ✅ Are you having fun? You are free to extend the game with new functionality.
- You are free to implement as many endpoints as you need.
- You can use inline comments, git commits or readme file to justify your decissions.
- Bag size is unlimited.
- Bear in mind RESTful API concepts.
- One object can be used by multiple players
Use your own criteria for any rule that is not clear. Justify it.
I've build a API bearing in mind the time I have to complete all task. For that reason:
- All the logic is in the controllers. That is not a great architecture if the app have to scale. With more time I will apply DDD and an hexagonal architecture. You can find a example that I've build for practise these architecture here: shopping-list
- I've decide to write acceptance test. It is a good aproach for test all the routes but not the logic. With more time I would write unitary test for this porpouse.
- I am feel more confortable with typescript. For that reason I feel free to migrate it.
- I've implemented persistante. A file is saved on ./cache/data.json. You can restart the database removing this file and restarting the server.
- For a bigger and scalable API I would use Event Sourcing and save every action (attack, steal, use-object, ...) as an event (transactions). And for example /players/:id/attack would be /actions/.+
- I've build a super basic auth on /api routes using a cookie.
To run the project, open a terminal and execute the following command from project root path:
Install dependencies
yarn
Start a local server
yarn start
A local server will start on port 8080.
Build the image:
docker build -t /payvision-frontend-castleblack .
Run the image on localhost port 8081:
docker run -p 8081:8080 -d /payvision-frontend-castleblack
Enter the container:
docker exec -it sh
Print logs:
docker logs docker logs -f --tail 10
To test the project, open a terminal and execute the following command from project root path:
Install dependencies
yarn test
If you want watch it run
yarn test:watch
Using the endpoint /auth/signin with the body params username and password. You can define this envirioment variables with the same name or use the default ones: admin and secret respectively