Skip to content

Project Listing App's Backend: A powerful NodeJS environment (v18.16.0) for an all-in-one project listing app. Enables CRUD operations for developers, organizations, projects, proposals, and reviews. RESTful API, sorting/filtering, and robust security measures. Extensive documentation and thorough API testing.

Notifications You must be signed in to change notification settings

open-xyz/project-listing-backend

Repository files navigation

A Project Listing App's Backend

Developing NodeJS environment v18.16.0

Alt text Alt text Alt text


What is Project Listing App ?

An all-in-one project listing app with a powerful backend, enabling seamless browsing of projects, businesses, and developers while offering extensive project details and developer profiles.


What are the basic functional requirements of the app ?

A functional requirement (FR) defines the specific services and behaviors that the software system or its components must provide, encompassing inputs, system behavior, and corresponding outputs.

  1. Developer -
    • Developer should be able to do CRUD operation on their profile
  2. Organization -
    • Organization should be able to do CRUD operation on their profile
  3. Project -
    • Organization should be able to do CRUD operation on their listed projects
  4. Proposal -
    • A developer should be able to do CRUD operation on their proposals made to organization's project.
  5. Review
    • A developer should be able to create, delete review on the organization they've worked with.
    • A organization should be able to create, delete review for the developer they've worked with.

Schema diagram


API Index

Developer

  • Retrieve all Developers - GET /developers
    • SORT asc/desc based on 'any' parameter - GET /developers?sort=city or =-city for descending.
    • SEARCH based on 'fname, lname, city, qualification' parameter of schema - GET /developers?city=mum
      • Or something more complex like ?fname=me&city=che
      • Or ?qualification=BE+in+Comp&sort=fname
    • FILTER based on 'openToWork' - GET /developers?openToWork=true
  • Register new Developer - POST /developers/auth/register - generates authToken too.
  • Login Developer - POST /developers/auth/login - generates authToken too.
  • Retrieve specific Developer - GET /developers/:id
  • Update specific Developer - Protected PATCH /developers/:id
  • Delete specific Developer - Protected DELETE /developers/:id

Organization

  • Retrive all Organization - GET /organizations
    • SORT/FILTER asc/desc based on 'any' parameter - GET /organizations?sort=name or =-name for descending.
    • SEARCH based on 'name, domain' parameter of schema - GET /organizations?domain=it
      • Or something more complex like ?domain=it&name=raw
  • Register new Organization - POST /organizations/auth/register - generates authToken too.
  • Login Organization - POST /organizations/auth/login - generates authToken too.
  • Retrive specific Organization - GET /organizations/:id
  • Update specific Organization - Protected PATCH /organizations/:id
  • Delete specific Organization - Protected DELETE /organizations/:id

Project

  • Retrive all Projects - GET /projects
    • SORT asc/desc based on 'any' parameter - GET /projects?sort=createdAt or =-createdAt for descending.
    • SEARCH/FILTER based on 'title, techStack' parameter of schema - GET /projects?title=edu
    • FILTER based on 'featured' - GET /developers?featured=true
      • Or something more complex like ?projects?projects?board=kan&featured=false
  • Create new Project - Organization Protected POST /projects
  • Retrive specific Project - GET /projects/:id
  • Update specific Project - Organization Protected PATCH /projects/:id
  • Delete specific Project - Organization Protected DELETE /projects/:id

Proposals

  • Retrieve all proposals - Dev+Org Protected GET /proposals
  • Create new proposal - Dev Protected POST /proposals
  • Update specific proposal - Dev Protected PATCH /proposals/:id
  • Delete specific proposal - Dev Protected DELETE /proposals/:id

Review

  • Retrieve all reviews - GET /reviews
    • SORT asc/desc based on 'any' parameter - GET /reviews?sort=rating or =-rating for descending.
  • Create new review - Dev+Org Protected POST /reviews
  • Update specific review - Protected PATCH /reviews/:id
  • Delete specific review - Protected DELETE /reviews/:id

Some Standard HTTP codes used throughout the project :

  • 201 - Create/Register Resource.
  • 200 - OK for Updating/Deleting Resource.
  • 400 - Bad Request due to possible syntax errors/invalid request payload/failed the request validation like if the data is missing or if it has a wrong type, etc.
  • 422 - Server understands but Unprocessible due to business-logic/input validations related issues.
    • 422 is less severe than 400. The request has reached the server. The server has acknowledged the request has got the basic structure right. But the information in the request body can't be parsed or understood.
    • Difference between the above two is that the syntax of a request entity for a 422 error is correct whereas the syntax of a request that generates a 400 error is incorrect.
  • 401 - Unauthorized access to Resource used in access_token verification
  • 404 - Resource not found.

Application's capabilites :

  1. Daatabases : MongoDB Atlas is used to house data of Developers, Organizations, Projects, Proposals and Reviews with appropriate Schema. Apart from MongoDB, Cloudinary web service is used to handle and store multimedia.
  2. RESTful API : The express API of the application follows all the REST API rules and provides CRUD operations on the API's entites.
  3. Sorting & filtering : Approtiate endpoints are powered with the sorting and filtering quering parameters.
  4. Verify user paramters : Specific fields like email and password and verified by express-validator.
  5. Security : The API's routes are protected with authentication middlwares and SSL by hosting service.
  6. Documentation with developer guide and learnings.

RESTful API

The backend follows the concept of RESTful(Representational State Transfer) APIs

  • Accept and respond with JSON
  • Standard HTTP status codes
  • No use of verbs in URL. Use nouns.
  • Plural nouns to name a collection in URL
  • Use resource nesting
  • Use filtering, sorting to retrieve data
  • Well compiled documentation
  • Return error details in response body
  • Use SSL (done with the help of hosting)
  • Secure the API (with several middlewares)

API Testing :

The API is tested with mocha, chai and supertest libraries with overal coverage of more than 90%.

🛠 Here is the detailed result of the testing.


👉🏻👉🏻 Please refer guide for getting started with the application development


Todo :

  1. Standardized response messages.
  2. Ask sir about async/await vs done promises in testing and veirfy the usage of aysnc/await in delete test cases.

About

Project Listing App's Backend: A powerful NodeJS environment (v18.16.0) for an all-in-one project listing app. Enables CRUD operations for developers, organizations, projects, proposals, and reviews. RESTful API, sorting/filtering, and robust security measures. Extensive documentation and thorough API testing.

Resources

Stars

Watchers

Forks