Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use of Django Rest frameworks serializers? #1001

Open
Charlisim opened this issue Mar 5, 2017 · 3 comments
Open

Use of Django Rest frameworks serializers? #1001

Charlisim opened this issue Mar 5, 2017 · 3 comments

Comments

@Charlisim
Copy link

I'm starting to get used with the project and after making other projects in django I feel weird not use Django Rest framework serializers for REST API. The only thing that I realized that may be can't be achieved out of the box with DRF serializers is bulk updates. There is any other reason to not use them?
I think that can improve the API and separate logic, not having view logic on the model.

@davidmiller
Copy link
Member

Hi @Charlisim - thanks for checking out Opal and for getting in touch !

I know what you mean about use of DRF Serializers - me and @fredkingham have discussed this before :)

The reason we are where we are is that our to_dict serialization on the models pre-dates the use of DRF in Opal, and we've never quite transitioned it. We switched to DRF with a view to using their permissioning, API Keys, and to promote discoverability of the JSON APIs via the DRF browser - which is great.

I think there's definitely a case for moving the serialization into a DRF style serializer/renderer. The potential complexities are probably less to do with bulk updates, and more to do with some of the more esoteric use cases.
(I imagine bulk updates can be wrapped in the Django @transaction.atomic decorator, and then routed to the appropriate serializer).

There are some use cases where we override these methods quite extensively to implement unusual and complex requirements - for conditional logic related to values in the data, interactions with other models et cetera.

We'd want to make sure that you didn't have to hand-code a serializer for every model - that they were generated for you by default, but also that you could easily override serialize/update methods for individual subrecords.

It's really useful to hear that you found this weird - we definitely appreciate this kind of feedback :)

At this stage, I suspect that we're unlikely to get around to this particular refactoring very soon - but we'd happily merge a PR that refactored the serialization to use DRF style serializers !

Is the refactor something you might be interested in doing?

Also - are you thinking of using Opal for a project in particular or just exploring ?

@Charlisim
Copy link
Author

I can do the refactor, but as you'll understand will take some time to refactor all the project, but I think is something that can help me to get used with all the internals of the project.

I'm exploring the possibilities that the project have to be implemented in a clinic of Neurology that may be will open in Guatemala in a couple of years.

@davidmiller
Copy link
Member

@Charlisim Sounds great and an exciting potential project!

It's always good to hear how people are using Opal :)

Do feel free to get in touch if you want to talk things over or have any questions etc - either here or on the mailing list: https://groups.google.com/forum/?ohc-dev#!forum/ohc-opal

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants