3 ms·

Are you referring specifically to separating the Serializer from the Model? Do you have links to that convo? I love to read how design choices like that are ma

Are you referring specifically to separating the Serializer from the Model? Do you have links to that convo? I love to read how design choices like that are made, and obviously that is one of the defining (correct) choices for DRF.

wahnfrieden 3y ago
it was a DM on Convore in 2011 so it is long gone. my name is also only credited in an old CREDITS file in the DRF git history (not sour grapes, just explaining where these credits are) I shared a prototype REST framework I'd built that separated Serializer from Model as inputs to views, yes, under different names, and he liked the idea and took it from there this is the prototype repo: https://github.com/aehlke/django-catnap https://github.com/aehlke/django-catnap you can see the RestResource, RestModelResource classes. this was distinct from tastypie's approach (popular at the time)
- jamestimmins 3y ago
  Excited to look, thanks for sharing!
- digdugdirk 3y ago
  Neat story! I design physical consumer goods products, and love seeing something I've worked on pop up into my "real life". Not being much of a programmer, do you think there's an equivalent feeling for coding? And was this one of those instances? I'll be honest, I'm getting 50/50 mildly entertained/mildly bitter vibes off your comment but only replying out of curiosity. Like I said, the intuitive understanding of "code" as a craft is somewhat foreign to me.
  - wahnfrieden 3y ago
    oh I'm glad someone else took the idea and made it work. I'm very glad to avoid the work that it took to build Django-REST-Framework :) I only prototyped my work originally because I couldn't find such a solution, not because I actually wanted to work on one. I just couldn't tolerate tastypie, and I was sick of people learning from Rails to design thin wrappers over their data models for APIs (because of how easy Rails made that), I wanted people to move on from coupling data layer to API representations in such a 1:1 way as the default.

wahnfrieden 3y ago

it was a DM on Convore in 2011 so it is long gone. my name is also only credited in an old CREDITS file in the DRF git history (not sour grapes, just explaining where these credits are) I shared a prototype REST framework I'd built that separated Serializer from Model as inputs to views, yes, under different names, and he liked the idea and took it from there this is the prototype repo: https://github.com/aehlke/django-catnap https://github.com/aehlke/django-catnap you can see the RestResource, RestModelResource classes. this was distinct from tastypie's approach (popular at the time)

jamestimmins 3y ago
Excited to look, thanks for sharing!
digdugdirk 3y ago
Neat story! I design physical consumer goods products, and love seeing something I've worked on pop up into my "real life". Not being much of a programmer, do you think there's an equivalent feeling for coding? And was this one of those instances? I'll be honest, I'm getting 50/50 mildly entertained/mildly bitter vibes off your comment but only replying out of curiosity. Like I said, the intuitive understanding of "code" as a craft is somewhat foreign to me.
- wahnfrieden 3y ago
  oh I'm glad someone else took the idea and made it work. I'm very glad to avoid the work that it took to build Django-REST-Framework :) I only prototyped my work originally because I couldn't find such a solution, not because I actually wanted to work on one. I just couldn't tolerate tastypie, and I was sick of people learning from Rails to design thin wrappers over their data models for APIs (because of how easy Rails made that), I wanted people to move on from coupling data layer to API representations in such a 1:1 way as the default.