Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Django REST framework 3.1 released

django-rest-framework.org

Post reply on HN
Print view View original

21–30 of 46 posts

Re: Django REST framework 3.1 released

#21

Post by the_vincedent »

tomchristie wrote: post #3
the_vincedent wrote: post #2

Still no M2M for ModelSerializer..? Guess I'll have to just keep using a ton of shitty hacks.

Of course you can use many to many fields with ModelSerializer. I'm not sure what you mean here, but I'd suggest opening an issue if you believe there's a problem - we're pretty comprehensive about dealing with incoming issues.

An issue that I've consistently run into is being able to write to related models. I can serialize them just fine, but without being able to write, it forces users to come up with nasty work arounds. To be fair, I hate having to write resources that handle writing nested objects, but there are some many front end use cases where multiple writes is not ideal.

Re: Django REST framework 3.1 released

#22

Post by chucksmash »

vosper wrote: post #15
chucksmash wrote: post #12

Super useful tool, thanks to Tom and everybody who contributes. When we began moving some of our APIs from Django to Flask at my company, djangorestframework was the single tool/package that I missed most. It's lovely. What are the plans (if any) for continued development on Flask-API?

I'm curious why you decided to move APIs from Django to Flask? We've built our APIs on Flask, and, though I like Flask a lot, the major complaint is that there's no real story around user authentication and authorization, endpoint versioning, and a handful of other things that aren't directly serving the purpose of the API, but are important nonetheless. There are a hodge-podge of plugins to do various things, but th…

We're not building from scratch. The constraints imposed by the pre-existing stuff mean we can't really take full advantage of the upsides of Django.

Re: Django REST framework 3.1 released

#24

Post by tomchristie »

aidos wrote: post #19
tomchristie wrote: post #14

Earlier quoted context omitted.

At the moment it's on hold - I certainly won't be doing anything with Flask until the Kickstarter work is all complete. I'm undecided after that. It'd be interesting to get your opinion on what your take would be on using Django/Django REST framework if it had decent built-in support for use with SQLAlchemy.

EDIT this conversation came up while I was writing this comment on another thread. Some of my questions have already been answered so I've reworded it. Said it before, and I'll say it again - DRF is one of the few things that makes me wish I was on Django. Is the newer DRF code abstracted nicely to make a port to Flask easier? It's something I actually looked at doing myself a year ago but there looked to be a lot of…

Well actually no, it'd be very feasible to re-write Django REST framework as a framework agnostic core. I've done a bit of exploratory work with this and there's nothing there that I think would be particularly fiddly.

The main questions would be how we'd manage support, packaging, documentation etc. Also is the benefit worth it if it means an extra level of indirection for our existing user-base? Right now focusing on Django REST framework in it's current form feels like the best effort-reward, but there's no fundamental architectural reasons stopping us from moving to a more decoupled core, with a Django specific integration layer on top of that.

Re: Django REST framework 3.1 released

#25

Post by tomchristie »

the_vincedent wrote: post #21
tomchristie wrote: post #3

Earlier quoted context omitted.

Of course you can use many to many fields with ModelSerializer. I'm not sure what you mean here, but I'd suggest opening an issue if you believe there's a problem - we're pretty comprehensive about dealing with incoming issues.

An issue that I've consistently run into is being able to write to related models. I can serialize them just fine, but without being able to write, it forces users to come up with nasty work arounds. To be fair, I hate having to write resources that handle writing nested objects, but there are some many front end use cases where multiple writes is not ideal.

Oh right, writable nested serializations, sure. I won't rehash the reasons that we don't support that in core (ill defined what behavior the user should expect) but yeah it'd still be good to have a third party package that does a decent "best effort" job of that.

My personal take on this is forget about "shitty hacks" or trying to handle this automatically, and just write the serializer create and update methods explicitly.

Re: Django REST framework 3.1 released

#27

Post by chucksmash »

tomchristie wrote: post #14
chucksmash wrote: post #12

Super useful tool, thanks to Tom and everybody who contributes. When we began moving some of our APIs from Django to Flask at my company, djangorestframework was the single tool/package that I missed most. It's lovely. What are the plans (if any) for continued development on Flask-API?

At the moment it's on hold - I certainly won't be doing anything with Flask until the Kickstarter work is all complete. I'm undecided after that. It'd be interesting to get your opinion on what your take would be on using Django/Django REST framework if it had decent built-in support for use with SQLAlchemy.

I'm personally working with a lot of hand-rolled SQL/stored procedures but I know there are people within the organization using SQLAlchemy's schema reflection to work with the legacy tables. Being able to use something like Django Rest Framework to build an API on top of that would be nice indeed.

Re: Django REST framework 3.1 released

#28

Post by ballpark »

hoprocker wrote: post #26

Has anybody used both Django REST and restless[0]? My company's starting to migrate a Django-based system towards something more REST-full. [0] http://restless.readthedocs.org/en/latest/

I've got a little experience with both. I went full bore into DRF, and found myself wrestling with the framework too much. I wanted to use the framework (ModelSerializer), but found it difficult to find the hooks to customize some behavior. Then going down a layer of abstraction felt like I had to do too much. This is probably the reality of any framework, not necessarily the fault of DRF.

Right now I'm using django-restless. I'm sticking with it for now. It uses Django forms for validation, which works ok even though they weren't meant for validating json input. Now I'm wondering if it would be best to just use Django, and be restless in style. Perhaps DRF, restless or some other libraries would have some pieces that I could use in a more library fashion if I wanted them.

Re: Django REST framework 3.1 released

#29

Post by aidos »

tomchristie wrote: post #24
aidos wrote: post #19

Earlier quoted context omitted.

EDIT this conversation came up while I was writing this comment on another thread. Some of my questions have already been answered so I've reworded it. Said it before, and I'll say it again - DRF is one of the few things that makes me wish I was on Django. Is the newer DRF code abstracted nicely to make a port to Flask easier? It's something I actually looked at doing myself a year ago but there looked to be a lot of…

Well actually no, it'd be very feasible to re-write Django REST framework as a framework agnostic core. I've done a bit of exploratory work with this and there's nothing there that I think would be particularly fiddly. The main questions would be how we'd manage support, packaging, documentation etc. Also is the benefit worth it if it means an extra level of indirection for our existing user-base? Right now focusing…

Interesting. Thanks for the info. Definitely understand not wanting to muddy the waters. Especially at this stage, the new Django version obviously has to be the focus.

That said, if the core was sufficiently decoupled that you could split it out, that would be a major win for the Flask guys. pip install djangorestframework could work just as it does (by installing drf_core). The Flask community could then create flaskrestframework which also installs the core and uses that. I guess the djangorestframework project could even contain everything, so long as the core module didn't depend on django.

Then the Flask guys could maintain a wrapper and some lightweight Flask specific documentation with references back to the main docs.

As I say, it would be silly to do it now, but if it turned out to be easy to do in the long run, it wouldn't have to impact on the work you're doing too much.

As ever, even though I'm not even using the project, thanks for the work. I spent a long time reading through your code a couple of years back. It was really enlightening and I learnt a lot. Thanks again.

Post reply on HN