On Tue, Jun 3, 2014 at 7:23 AM, Sanjay Bhangar <sanjaybhan...@gmail.com> wrote:
> Hey, > > (apologies for the top-post) > > Am excited about this thread and it's great to see an official > 'blessing' from you, Stephen, for an integration of > Django-Rest-Framework into Mezzanine. I've been playing around a lot > with DRF recently and am really excited by it. > > I wish I had the time to be able to commit to doing this, but > realistically, 'real work' will probably over-run me :/ -- I'd > definitely be happy to lend a hand any way I can if someone starts a > branch or so for this. I think the approach of first creating a REST > API is probably a good one, and DRF as a Rest frame-work has blown my > mind of late and Mezzanine + DRF seems like a really exciting thing. > > Once the API piece is in, I think there can be a lot of debate of how > much integration with a specific front-end framework Mezzanine should > provide and to what extend (a full CRUD, just the front-end? how > customizable will it be, etc.), but I think if Mezzanine provides a > robust REST API, third party packages with integration at various > levels with various front-end JS / Single-Page-App frameworks would be > possible to build and it would be fun to see what the ecosystem throws > up. > > What's the best way to go ahead with this? I earlier mentioned creating a separate repo called mezzanine-rest-api or something similar, but I've been thinking about this a bit more and have some other possible ideas. Mezzanine has always had a "kitchen sink" philosophy, in as much as if a particular feature is arbitrarily deemed common enough (eg not all, but *most* sites need a blog), then we include it. We also have the approach of implementing our own code if the feature can be achieved simply enough, only deferring to dependencies when the feature is too broad to implement from scratch. The case of a REST API and django-rest-framework clearly fit this bill, in that we wouldn't try and recreate what it does. I too have worked with DRF quite extensively over the last 12 months, and I feel like the actual backend API code for Mezzanine would be fairly minimal when leveraging it. So to sum up: - In 2009 when Mezzanine started, a REST API probably wasn't common enough to warrant inclusion in Mezzanine. Now in 2014 I think it is. - If we defer to DRF as a dependency, which from my experience has been very stable, the code should be minimal enough in Mezzanine to warrant inclusion, eg the maintenance overhead in this case would be acceptable given the benefit of having this feature work out of the box. In terms of implementation, my idea would be to create a "mezzanine.api" package that simply houses the view (and serializer in DRF-speak) code in one spot for all the other apps. This may seem like it goes against the notion of Django applications and isolation within them, and that we should build REST API code within each individual app (blog, pages, etc), but I don't see it that way structurally - I feel like the REST API is a single feature of Mezzanine as a whole, that belongs in its own app that can be turned on or off. I think of it in terms of the URLs exposed, would you expect a single root endpoint for the API like: /api/blog/ /api/pages/ or endpoints littered throughout the URL structure like: /pages/api/ /blog/api/ I've worked on projects with both approaches in terms of URL structure and "Django app" structure, and having both aspects follow the former pattern above really feels right. >From that point I think we'd start designing things to more or less mimic the design of admin classes throughout Mezzanine - these represent the common interfaces for crud operations (via Django admin). So we'd have something that maps to Displayable and could be re-used by project specific models that subclass Displayable - we'd then use that in mezzanine.api to implement the blog's REST API. That should be pretty straight-forward. The stuff for pages will get a little trickier: - How do we represent a tree in a REST API without hammering the web server, in the same way Mezzanine originally solved the problem for rendering trees without hammering the database with recursive queries. - How do we have the REST API automatically expose project specific Page subclasses, in the same way the admin currently does? That's all I have in mind for now. Both ideas of including this within Mezzanine, and putting everything into a single mezzanine.api package are probably hot topics for debate, although I'd normally be the one rallying against including large new changes in Mezzanine itself. But again, I think the development landscape in 2014 warrants a REST API out of the box. > Is there anyone willing to > take the lead on this? I, unfortunately, haven't played with Mezzanine > in a while, but I can try doing a code checkout and refreshing myself > over the next few days and throw up some thoughts about how this maybe > structured - I've found DRF to be a real pleasure to use and on the > surface, it seems like it should be fairly straightforward to get it > to work with Mezzanine - will take a better look at the Mezzanine code > though, I was very impressed by it a year or so ago, but haven't had > the opportunity to use it in a real-world project yet. > > Do let me know if I can lend a hand with anything, with the disclaimer > that this really excites me, but that 'real work' may ambush my best > intentions, so I don't want to commit to things I may not be able to > finish. > > Thanks again, Stephen - it's been quite awesome to be on this list and > follow conversations - have learnt a lot. > > -Sanjay > > On Tue, Jun 3, 2014 at 2:24 AM, Stephen McDonald <st...@jupo.org> wrote: > > > > > > On Tue, Jun 3, 2014 at 4:19 AM, Niels Jakob Buch <njb...@gmail.com> > wrote: > >> > >> Guys, I can only confirm that the time is mature for a mezzanine rest > >> framework and some goodies for more advanced UI. > >> > >> I am crossing my fingers that some of you cool dudes will grab your > balls > >> and start creating something nice. > > > > > > > > It's a subtle faux pas when we imply everyone here is male (I constantly > > have to stop myself from using "guys" when I mean "all'), but it crosses > the > > line when we add crotch grabbing on top of that. I'm sure your intentions > > are harmless, but I just wanted to point out comments like this aren't > > welcome on the mailing list. > > > > Thanks. > > > > > >> > >> > >> Full support from here! > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Mezzanine Users" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to mezzanine-users+unsubscr...@googlegroups.com. > >> For more options, visit https://groups.google.com/d/optout. > > > > > > > > > > -- > > Stephen McDonald > > http://jupo.org > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Mezzanine Users" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to mezzanine-users+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Mezzanine Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mezzanine-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Stephen McDonald http://jupo.org -- You received this message because you are subscribed to the Google Groups "Mezzanine Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
