Why my django test project is rejected?

My client rejected my Django test project for reasons I find unacceptable. I feel very low.

Django community, please help me improve my project.

Please guide me or suggest what I did wrong and what I should avoid.

Here the information

Client Feedback 1

The code related to the recipe was looking fine but the use register and login code is good. It seems those API’s will not even work well. So, I think we should not move forward.

Client Feedback 2

Code structure does not looks good. Authentication is not implemented correctly. So, we should not move forward.

Here the test project information:

Build a Recipe Sharing Platform

  1. Framework:- Use Django framework to build the REST APIs.
  2. User Authentication:- Implement user authentication and authorization to allow users to sign up, log in, and manage their recipes securely.
  3. CRUD Operations: Enable users to perform CRUD operations (Create, Read, Update, Delete) on recipes they own.
  4. Recipe Details: Include fields such as title, description, ingredients, preparation steps, cooking time, and serving size for each recipe.
  5. Recipe Categories: Allow users to categorize recipes into different categories (e.g., starter, main courses, desserts).
  6. Search and Filter: Provide functionality to search and filter recipes based on various criteria (e.g., category, ingredients, cooking time).
  7. Rating and Reviews: Allow users to rate and review recipes, and display average ratings for each recipe.

Here’s my GitHub repo: GitHub - Keerthanamurugesan2001/recipe_radar: Recipe Sharing app

Please someone suggest:

  1. What mistake I made
  2. Why the client feels it’s not in standard
  3. Which part I can improve in this project

I used the PEP 8 standards, Django REST Framework, simple-jwt.

If any have Django project in your github repo if its opensource please kindly share for my reference

If you are looking for comments from people here, please post the story here. Do not expect people to go to another site and then come back here to comment.

Sorry For the inconvenience please check the post again.

Can I get your github django project repo for a reference please.

Clearly, I can’t speak for the reviewers. I don’t know exactly what they’re looking for, or the criteria they are using to evaluate the code.

I don’t know if this is the complete description, or if there was more information provided than shown here.

I also don’t know whether or not there was any additional communications requesting clarification or interpretation of these items. If there were, my comments here become completely invalid.

So, working under the assumption that this is the complete description and that no additional clarifications exist, I would make the following comments.

Side note: These reflect my personal biases. These aren’t hard rules, and there are arguments to be made to the contrary. But if I were reviewing this project, this is what I would note.


  1. Excessive number of files and directories for the functionality provided, making the project difficult to navigate and follow. I have written many times here that I am not a fan of trying to subdivide apps into subdirectories and needlessly creating excess files. Specific example: I find no value in creating a “filter” directory to contain a single “recipe_filter.py” file along with a “permissions” directory for the “permission.py” file.
    If I were implementing this, there’d be at least three fewer directories and five fewer files.

  2. I see no reference above to using swagger. The case could be made that you’re extending the bounds of the requirements. (This would be a marginal item, and why I was asking about clarifications above. Part of the duties of a developer are to identify what’s in or out of scope for a task, and to seek clarifications when necessary. As a junior developer it is expected that you would ask more when these types of issues arise. Knowing the internal formal and informal standards within an organization are part of that as well.

  3. I’m not a big fan of listing my apps below the system apps in the INSTALLED_APPS setting. There are very few cases where it truly matters - but when it does, it’s important.

  4. Your databases settings both require too much and too little. By this I mean that not every engine uses all the same settings, and some may not apply. (This is a tough one. Making a truly generic set of settings for all database engines is difficult. Things get a lot easier if you can identify which engine is being used.)

  5. I don’t like seeing STATIC_ROOT set to a directory within the project. There is no deployment environment that I use where that would be valid. At a minimum, it would be another environment variable to be set.


I’m not knowledgeable enough about DRF to make any comments about your API itself, or the authentication process. Perhaps someone else might be able to help there.


Thank you very much for your opinion I appreciate for time spent with this issue.

I provided all the information that I had in my hand. About DRF I will check with someother person also. Thank you very much once again for your valuable time.