cookiecutter / cookiecutter-django

Cookiecutter Django is a framework for jumpstarting production-ready Django projects quickly.
https://cookiecutter-django.readthedocs.io
BSD 3-Clause "New" or "Revised" License
12.16k stars 2.91k forks source link

Adding django-ninja options to building REST APIs #4923

Open TGoddessana opened 8 months ago

TGoddessana commented 8 months ago

Description

I'd suggest to add the django-ninja option to the project creation options.

Instead of using the use_drf option in the current template, it would be nice to have an option like the one below.

in cookiecutter.json:

...
"api_framework": ["Django REST Framework", "Django ninja"],

The current template has a good separation of the api-related code under api, so I think we could substitute schemas.py for serializers.py and so on to put the django ninja related code there.

Rationale

Now that version 1.0 of django-ninja has been released, and it seems to have matured quite a bit, I think it's worth adding it to the template.

foarsitter commented 8 months ago

A PR is more than welcome

TGoddessana commented 8 months ago

I wanted to get the maintainers' views before I started working on it, so I'll get to it :)

browniebroke commented 8 months ago

Although I don't have any experience with Django-ninja, I've heard about it in a few places and it looks really good. I would be interested to learn more about it and see what it would like to reproduce our simple DRF endpoints.

Accepting such change would however depend on how maintainable it is in the long run, so it would be ideally be covered by automated tests and not too intertwined with the DRF code.

If it's easier for you, perhaps try to generate a vanilla cookiecutter-django project with DRF, push it GitHub somewhere, open a pull request to migrate it to django-ninja and send us the link here? That would give us an idea of the differences between the 2 frameworks and maybe we could make a more informed decision?

TGoddessana commented 8 months ago

Great. I've been looking into what the current DRF implementation looks like for endpoint reproduction, and it appears that token authentication is not provided by ninja.

I'll try to create a simple demo and upload it soon :)

TGoddessana commented 8 months ago

OK, i created some demo for this.

In my opinion, the biggest decision to make about adding options is how much you want to implement the APIs that are currently in your template.

So, I would like to suggest that...

The other issue, in my opinion, is that..

foarsitter commented 8 months ago

From my point of perspective there is no need to align the DRF functionality with the one provided by django-ninja. What is important to me is that there is 100% test-coverage for what is provided out of the box.

What kind of authentication you would suggest to replace the token auth?

TGoddessana commented 8 months ago

https://django-ninja.dev/guides/authentication/

There are several third-party packages that support authentication in django ninja, but personally I think we should wait until they are mature enough and can be evaluated.

My suggestion is to use Django Session based authentication, which is supported by Django Ninja.

for example, view can see like below:

@api.get("/pets", auth=django_auth)
def pets(request):
    return f"Authenticated user {request.auth}"
browniebroke commented 8 months ago

That's a great start, although it would have been a bit easier to follow the changes if you had a pull request with ALL the changes required. The PR that you linked seems to build upon other changes that added django-ninja already. Also, if the PR was still open we could collaborate and suggest improvements...

From my perspective, I don't really mind if the API responses are slighly different between DRF and django-ninja, or that error are reported differently. I'd rather have a project as close as psosible to what each framework considers the "best practice".

Once the project is generated, if the user opted for django-ninja, they shouldn't have any custom code that is just to make it look like DRF (or vise-versa).

TGoddessana commented 8 months ago

it would have been a bit easier to follow the changes if you had a pull request with ALL the changes required.

Can you tell me a little bit more about this? First of all, I reverted the merged PR and recreated it.

From my perspective, I don't really mind if the API responses are slighly different between DRF and django-ninja, or that error are reported differently. I'd rather have a project as close as psosible to what each framework considers the "best practice".

I agree with the above comment. Making the responses, URL namespaces, etc. the same as DRF provides adds unnecessary and minor changes.

The package itself is mature, but finding best practices for using it is not as easy as I thought it would be. I'd love to discuss this with some of you who are more experienced - certainly better developers than I am.

browniebroke commented 8 months ago

Can you tell me a little bit more about this? First of all, I reverted the merged PR and recreated it.

The PR changes the file config/ninja_api.py, but clearly this file isn't present with DRF. So I would expect this file to be created by your PR, not edited. Basically having a PR with installation and configuration of django-ninja, not just adding the endpoints. If we add it to the template, we'll have to maintain the whole thing... No need to change it now though. Thanks for opening this.

TGoddessana commented 8 months ago

(Add ninja_api file, remove api_router file) https://github.com/TGoddessana/cookiecutter_django_ninja_example/commit/77fedd74fa0d7f448657719059657af952cf30fb

(Add requirements) https://github.com/TGoddessana/cookiecutter_django_ninja_example/commit/1938cacec2bd0d7546efa7b71f57e88ee9732dfb

The only commits I made to install Django ninja were adding requirements and creating the ninja_api file. you can check the main branch commits 😀

Me too, thanks for looking into the suggestion

bgervan commented 3 months ago

Now the allauth package provides endpoints out of the box, so making django-ninja extension to cookiecutter-django is much easier. Is there any ongoing progress on this topic since the last discussions?