Backend application with an external REST API for the clients.
Technology used: Node.js, Express.js, MongoDB and mongoose.js.
To get the Node server running locally:
- Clone this repo
- Set up MongoDB locally. Link to get started (Click on 'Community Server' Tab to download)
If you have homebrew in your machine, use the following command in your Terminal:
brew install mongodb
. And then activate it with the command:brew services start mongodb
.
npm install
to install all the dependenciesnode index.js
to start the local server (You will see logged in your console 'Server listening')
This is only information about the dependencies used in the project. Using the command
npm install
they will all be installed, as they are already defined in the package.json file.
- expressjs - Light-weight web application framework
- mongoose - For modeling and mapping MongoDB data to javascript
- mongoose-validator - Validators for Mongoose schemas
- body-parser - Node.js body parsing middleware
- node-config - Organizes hierarchical configurations for your app deployments
- cookie-parser - Parses cookies and puts the cookie information on req object in the middleware
- faker - for generating fake data for seeding the database and tests
- pug - high-performance template engine implemented with JavaScript for Node.js and browsers
- ava - Test runner
- nyc - Command line interface to use with AVA
- supertest - Provides a high-level abstraction for testing HTTP
-
index.js
- entry point of our application. -
app.js
- defines our express server and the Error Handling middelware. -
database-connection.js
- defines the connection to our MongoDB database. -
routes/
- This folder contains the routes definitions for our API. -
models/
- This folder contains the models used in our application, using Mongoose schema definitions. -
services/
- Contains the files where we define the methods to connect to our database. -
views/
- The view files of our application using the pug template. -
ìndex.html
- This html file will define our main view structure to be afterwards modelated by our different pug views. Here we will also implement the axios script that will allow us to make real time post and get requests from the google chrome console.
In the file app.js
we define our error-handling middleware for handling any possible error in our application and be able to show error messages that the user/client can understand.
Every Error ocurred at the database or Schema level will be propagated until this stage to be properly handled.
We will consider different types of error:
-
409 - When the user creates an already existing user or tries to book a seat that is not available.
-
422 - When the user introduces empty or non valid data in the request.
-
500 - When any other internal error ocurrs.
GET
/theater/customer/all
POST
/theater/customer/
The information of the user will be defined on the body request. Example:
{ firstName: 'Joan', lastName: 'López', email: '[email protected]' }
firstName
, lastName
and email
are required fields. If any of the entries are empty or not valid, the user will receive a 422
response with the correct error message.
If there is already an user in the database with the same email, the user will receive a 409
response with the informative error.
GET
/theater/customer/detail/**THE_USER_ID**
GET
/theater/seat/all
GET
/theater/seat/available
GET
/theater/seat/detail/**THE_SEAT_ID**
POST
/theater/booking'
body: { userId: **THE_USER_ID**, seatId: **THE_SEAT_ID**}
userId
and seatId
are required fields.
If the customer attemt to book a seat, but he/she already has a seat booked or that seat has been booked for any other customer, there will be a 409
response showing the correct error message to the user.
Once the request is made, and if no error is encountered, it will reserve this seat to the sepecified user.