Project Design
- Table
Programmes Offeredshall be prepopulated. - Every Member to be onboarded shall have a pre-existing entry in the
membertable (to be done by admin).
Dotted lines and boxes represent that the specific activity is optional.
The following table thoroughly evaluates and compares two backend technology stacks, Django and Nest, to determine the most suitable framework for developing the portal considering various aspects.
| Framework | Django | Nest |
|---|---|---|
| Ease of Development | ||
| Code Reusability (reuse code components) | Allow custom decorators, middlewares, post and pre hook classes and methods | Allowed(Can be done by creating functions or custom decorators)Plus it is highly modular and components can be created using injectables. |
| Rapid Development (speed at which key features can be implemented) | Easy and rapid development because of many inbuilt modules and easily integrable 3rd party modules + lot of resources. | Typescript makes it difficult to work at high speed. Type defining however helps in keeping the code clean and error-free.Making it error free is time saving during running and testing |
| Authentication and Authorization (security features available for user authentication and access control) | out of box support for roles, permissions, authentication + easy to integrate social oauth login using djago-oauth. | Authentication and authorization(role-based or permission-based) can be done using custom made decorators(need to be defined only once in a separate file) |
| Data Protection: Evaluate data encryption, secure data storage, and protection against common vulnerabilities. | configurable in the project settings | Request Security can be implemented in middleware.Invalid data access can be prevented in interceptors(ig) |
| Data Modeling (framework's support for creating complex data models) | ORM using python classes. Supports OOPS like Inheritance and abstraction as well. | Sequelize or TypeORM are available to easily create complex data models using decorators and it also provides keywords to create relations between various tables. |
| API Development(ease of building RESTful APIs) | default support to implement custom logic.Standard crud operations can be auto implemented using django-rest-framework | Yes easily supported with some additional features |
| Community Support: | High community support | Moderate to high |
| Third-party Libraries | Yes | Yes |
| Maintainability (ease of maintenance) | ||
| Developer (feature addition, logic modification, schema change) | Easy to maintain the config changesSchema changes are also viable but the data migration is one’s own responsibility | Very easily maintainable |
| Admin (Manual override) | Out of the box support using django admin | Admin.js library can be injected directly giving proper admin portal |
| Deployment and Hosting | Can be easily dockerised and hosted using some standard wsgi server | Can be easily dockerised and hosted using some standard wsgi server |
| Customization and Extensibility (how well the framework supports adding custom functionality) | Overriding default behaviour is possible, although for some frameworks it might not be that trivial | |
| Custom Modules (ability to create custom modules or plugins) | Can create standalone “apps” which can be imported/exported from other projects and published as separate packages | High |
Django: Django Signals for connecting between different applications. Session management in Django like last page viewed, staying logged in, companies to look into later, etc
After a comprehensive evaluation of the two technology stacks, it has been determined that Nest.js, while slightly trailing behind Django in certain aspects, presents a viable and promising choice for our project. The decision to opt for Nest.js as the backend framework is primarily influenced by the proficiency and expertise of our initial team members in this technology.
It was decided that we will be continuing with NextJS because it is similar to ReactJS in its overall functionality and it will make the project more maintainable and easy to modify for future maintainers. Following points were evaluated.
| Pros | Cons |
|---|---|
| Difficulty in using frontend frameworks such as materialUI. | Server side rendering and SEO integration. |
| Unfamiliarity of the team with nextjs 13 (app router system) | Better routing and file structure. |
| Requires more client-server boundary error resolution. | Better framework for future improvement, considering the fact that this project will be used for a long term. |
- POST: add student list
- GET: get student(s) (with params) (add interceptors for conversion)
- PATCH: update student(s) (with params)
- DELETE: delete student(s) (with params)
- Query params supported: {name, category, gender, branch, graduation year, CPI, total Penalty, email}
- POST: add faculty list
- GET: get faculty(s) (with params) (add interceptors for conversion)
- PATCH: update faculty(s) (with params)
- DELETE: delete faculty(s) (with params)
- Query params supported: {email, department}
- PATCH: Approve
- POST: add recruiter
- GET: get student(s) (with params) (add interceptors for conversion)
- PATCH: update student(s) (with params)
- DELETE: delete student(s) (with params)
- POST: Add a JAF
- GET: List of JAF Id’s
- Delete: Delete the set of Id’s.
- PATCH: Change the status
- GET: Get a jaf.
- POST: Add a JAF (Corresponding apply event is made).
- GET: List of JAF Id’s
- Delete: Delete the set of Id’s.
- PATCH: Update the JAF. (JAF Approval and Public Access (cannot be public without approval trigger) will be handled here.
- GET: Get the JAF.
- DELETE: Delete the Jaf
- PATCH: Update the JAF.
- GET: Get the JAF.
- DELETE: Delete the JAF
- GET: Get the companies open for the student and the latest event corresponding to the JAF.
- GET: Get the details of the JAF and the events corresponding to the JAF applicable to the student.
- POST: Apply to the JAF. (Find the event with the status: Application corresponding to the JAF and create a corresponding entry in the rounds table).