10 ms·
Django REST framework 3.4 Released
- overcast 10y agoInteresting, somehow this project didn't come onto my radar. I was just about to start using Flask to build a REST API for our Oracle database. Definitely checking this out instead.
- harel 10y agoThere was a port of DRF for Flask, but it was not as mature and not as good. I went with Django mainly because of the included batteries and in particular DRF.
- overcast 10y agoI was just always dissuaded from the size of Django, Flask is mininal, and gets up and running quicker for me. Coming from a lot of Express work, it just made more sense to me, but I'll be definitely diving into DRF for my new project.
- kennydude 10y agoDjango is batteries-included, but the batteries aren't heavy. You can easily turn off 99% of the stuff it does for you. You also never know when you need a really good admin panel.
- collyw 10y agoThe admin is great, especially at the start of a project, when you want to look at and manipulate your data even if it isn't needed in the product you end up with.
- harel 10y agoThe size is less relevant - you only use what you need. The other main reason I chose Django for a particular project is the ease at which I can find experienced developers afterwards. Not that it really matters that much, Python being Python, but its easier to find someone with Django experience than one with Flask.
- morenoh149 10y agoBut django is a superset of Flask. If it's easy to find django devs it must be easy to find Flask devs.
- harel 10y agoNot really. Because its python, its all Python devs. But if you want someone with specific Django experience, you'll find it easier to find than flask. Popularity wins and Django is popular (for a good reason)
- justinsaccount 10y agoI use flask for a few applications.. it works, but even in my cases: Any sufficiently complicated flask application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of django. For sites that are just a few endpoints, it's great. I use it on an application that uses redis+gearman to spawn docker containers on demand. django would have worked too, but I'm not using anything other than routing and templating. On the other hand, I have an application that I built on flask that I needed to shift the timezone of the dates. in django you change TIME_ZONE and you're done. My flask app I had to fix it all myself, it was a nightmare.
- Spiritus 10y agoDjango can be minimal if you want: https://github.com/rnevius/minimal-django/blob/master/minimal.py https://github.com/rnevius/minimal-django/blob/master/minima...
- ralmidani 10y agoThe size of the framework is really not relevant in the context of Python server-side development. You just import what you need and ignore what you don't. For example, I develop single-page apps with Django+DRF and Ember, so I never use Django's template engine. If you really want to minimize your setup, you can even go into your settings.py file and turn off the middleware you don't need. Put another way, it's not like client-side JavaScript where the entire framework is sent to the user's browser.
- gshulegaard 10y agoBeware, having used Django, Pyramid, and Flask (in order of first use) I would highly recommend Flask over Django. Django is batteries included which can cause pain when trying to use different batteries. For me, SQL Alchemy > Django ORM for example. But if your use case fits well within the Django ecosystem...then Django can be easier.
- thorin 10y agoIf you have oracle would you consider using Oracle rest data services? I've only used it a little bit but it seems to make everything very easy. http://www.oracle.com/technetwork/developer-tools/rest-data-services/overview/index.html http://www.oracle.com/technetwork/developer-tools/rest-data-...
- overcast 10y agoYeh that's neat, but I feel like that is just going to cost me something to play. Also, there will be other databases tied into this project as well SQL Server, MySQL, and RethinkDB.
- emmelaich 10y agoI've installed ORDS. It's got some installer wackiness -- modifies the .war as part of the install. Otherwise, it's smooth enough and runs in Tomcat. I haven't used the REST features so much; we just use for the APEX pl/sql bridge (ugh).
- morgante 10y agoI love DRF. Compared to building APIs using Flask or Node, it's an order of magnitude faster.
- malinens 10y agoDoes faster mean speed of development or speed of code execution?
- deleted 10y ago[deleted]
- Abundnce10 10y agoI love Python but I've never used Django -- I've always used Ruby on Rails since that's what I'm familiar with. Do you know of any resources I could use to get more comfortable with DRF (i.e. more complex than just the Quickstart tutorial [0])? [0] http://www.django-rest-framework.org/tutorial/quickstart/ http://www.django-rest-framework.org/tutorial/quickstart/
- mod 10y agoDRF is not the same as Django, fwiw. Since you're looking for an alternative to RoR, I'm assuming you want Django. They have great docs and you might check out godjango.com
- ralmidani 10y agoIf you want to focus on REST APIs with Django, DRF is pretty much required, and it's only a "pip3 install" away. I flirted with switching to Rails (and did a lot of Code School courses and most of Michael Hart's Rails Tutorial), then realized I didn't have to limit myself to what comes with Django out-of-the-box.
- timc3 10y agoDjango REST framework really makes Django in my opinion. It really is the add-on which opens up a lot of possibilities.
- misiti3780 10y agoagreed - maybe it will be integrated into django someday like south was
- morenoh149 10y agowas south integrated? the docs say it hasn't http://south.readthedocs.io/en/latest/about.html#a-brief-history http://south.readthedocs.io/en/latest/about.html#a-brief-his... but maybe it's outdated?
- themoonbus 10y agoThe main developer of south was responsible for bringing schema migrations to Django's core... don't know how similar it was to south's codebase, though: https://www.djangoproject.com/weblog/2013/mar/22/kickstarting-schema-migrations-django/ https://www.djangoproject.com/weblog/2013/mar/22/kickstartin...
- collyw 10y agoIts pretty similar from developer perspective.
- brianwawok 10y agoThat doc is dated 2010. Further proof docs lie ;) But as other people said, no idea if it was copied and pasted into the django codebase or rewritten from scratch.. but everything South did, I believe Django now does.
- varikin 10y agoRewritten by the author of South. Basically, all the good ideas of South with some of the problems fixed.
- sandGorgon 10y agomy only blocker for migrating a legacy application to DRF is because it doesnt have support for nested routes (and I have to use a third party package). AFAIK this is deliberate and opinionated.
- morgante 10y agoWhat do you mean by nested routes? You can definitely have an API which looks like this: /api/people/morgante/comments/3000/
- quinnftw 10y agoYou can also use the include(x.urls) feature to really simulate nested routes.
- sandGorgon 10y agohttp://www.django-rest-framework.org/api-guide/routers/#drf-nested-routers http://www.django-rest-framework.org/api-guide/routers/#drf-... See for yourself.
- morgante 10y agoI'm not sure why that would prevent you from migrating to DRF. It's clearly supported and there's even a helper module to nested routes even easier.
- sandGorgon 10y agoI'm not really sure why a framework would take a position where something is important (and probably requested enough) to put it in the official documentation.... but not make it part of the core. I fear we-barely-tolerate-it syndrome.
- morgante 10y agoIt's entirely possible to do in core without any extensions. It seems like you're just coming up with ridiculous excuses to not use DRF.
- tbarbugli 10y agoVery interesting new feature, anyone has already some experience with the Core API implementation of DRF?
- tomchristie 10y agoAs the author, yes. The team I was previously with used Core API in some of https://www.crunchboards.com/ https://www.crunchboards.com/ That's got a service-based architecture, and we were using it both on the server side (where we wrote explicit Core API schemes, rather than auto-generated) and on the client side (moving towards doing our inter-service communication using `coreapi`, rather than directly through `requests`.) For us, the dynamic client libraries were a big win - the client code that you're working with becomes more meaningful and robust, as it's working with an application layer abstraction, rather than directly at a network layer.
- orliesaurus 10y agoDRF has some of the best docs for building APIs in Python - thanks for keep it real!
- mrweasel 10y agoThe documentation is great, but navigating it is a pain. Class names, methods and modules really should be links to where they are documented (because they are almost always documented). Search could also stand to improve, a lot.
- dopeboy 10y agoBig fan of DRF. Great documentation and awesome support on the usual channels. I use it for all my greenfield projects. I can't find a way to make a one time donation. Anyone know how?
- tomchristie 10y agoThat's not currently supported. We need recurring revenue rather than one-offs, so that's what I'm pushing for right now. Out of interest, is recurring something you'd consider if there was another lower-priced individual tier added?
- dopeboy 10y agoTotally understandable. I wouldn't just because my budget is very tight now.
- tomchristie 10y agoThen don't sweat it! :)
- SEJeff 10y agoI did fund your original kickstarter for DRF3 as a heavy DRF user at $job, and now might consider signing up as a recurring payment. Your code has saved me a lot of time and effort in my career, so thanks much sir!
- agconti 10y agoIts really awesome that this project continues to endure. The code base is top notch and the maintainers are committed to the highest level of quality. DRF is one of the core reasons why Django is top choice among web frameworks today. In my opinion, it sets the standard for rest frameworks for the development community at large.
- davesque 10y agoAgreed, this is a top notch project. Excellent code, documentation and, above all, the concepts exhibited in the library are extremely well thought out.
- guscost 10y agoTo be perfectly honest I think the implementation is a lot better than some of the documentation. The tutorials can be pretty confusing or just plain broken for anyone without at least an intermediate proficiency in Django already. Perhaps the documentation should have messages recommending that developers get good at Django first. Most of my experience with it has been great though, it's a very well built technology. For a helpful reference also check out http://cdrf.co http://cdrf.co
- mixinspy 10y agoAgreed! The code is lot easier to read than the docs. I generally think of DRF as "that which has to be true so that mixins.py[1] makes sense" 1- https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/mixins.py https://github.com/tomchristie/django-rest-framework/blob/ma...
- paukiatwee 10y agoOut of topic, I think the way DRF project funded is very interesting, i.e. public funded fulltime developer working on OSS. How many other similar successful OSS with such funding?
- tomchristie 10y agoClosest things I know of are: * Ruby Together - https://rubytogether.org/ https://rubytogether.org/ * Django Fellowship Program - https://www.djangoproject.com/fundraising/ https://www.djangoproject.com/fundraising/ * Read the Docs sponsorships - http://read-the-docs.readthedocs.io/en/latest/sponsors.html http://read-the-docs.readthedocs.io/en/latest/sponsors.html I think the business case is clear enough to make for a big project like REST framework. It's a relatively small investment per-company, but the relative payoff if we can hit a level that keeps it sustainable is huge.
- tschellenbach 10y agoEvery time I build something using a different stack than Python/Django I feel a bit sad I can't use DRF :) Awesome project, we're supporters!
- bsbechtel 10y agoJust curious if someone could give the tldr version of this vs graphql. I'm familiar with django, but not the rest framework, and have a basic understanding of graphql but am not really sure how they compare.
- morenoh149 10y agoThis has very little to do with graphql. The DRF is to get a solid json api up and running quickly. The standard it ships with conforms to the http://jsonapi.org/ http://jsonapi.org/ spec. Which came mostly from the Rails community and many projects built in different stacks conform to. If you're familiar with Rails it's like https://github.com/rails-api/rails-api https://github.com/rails-api/rails-api which was recently merged into Rails in v5. You could totally add a graphql endpoint to any api `/graphql?[your GQL query here]`. We're currently exploring adding that to our Django/DRF backend with one of these https://github.com/chentsulin/awesome-graphql#lib-py https://github.com/chentsulin/awesome-graphql#lib-py
- cdrx 10y agoStandard DRF is nothing like the JSON API spec.
- morenoh149 10y agoThis is true. My mistake. At our company we added https://github.com/django-json-api/django-rest-framework-json-api https://github.com/django-json-api/django-rest-framework-jso... to get DRF conformant to jsonapi spec.
- criloz2 10y agoI really love the django ORM, after your model are done you can create a really fast api with DRF, and if you want to try graphql/relay is possible with graphene https://github.com/graphql-python/graphene https://github.com/graphql-python/graphene.
- Alex3917 10y agoI'm really glad that ModelSerializer classes now require either fields or exclude. IMHO not requiring that before was one of the biggest weaknesses of the project, since it could easily lead to data being unintentionally exposed. I know that's maybe not the most exciting change, but I think it's important that it be very obvious what the code does even if a person isn't an expert in a given technology, especially when there are privacy/security implications.
- cdnsteve 10y agoWould DRF ever be an official third-party library like Channels is going to be?
- mikeokner 10y agoPossible, but the maintainer has stated there aren't plans to completely merge it into Django proper. https://www.reddit.com/r/django/comments/2ijyuq/added_tom_christie_to_core_team/ https://www.reddit.com/r/django/comments/2ijyuq/added_tom_ch...
- zentrus 10y agoThis is true, and I love DRF but I find it unfortunate then that the concept of Serializer exists. Tom Christie essentially says that Serializers can and should be used outside of views (REST) to decouple and encapsulate business logic. He seems to believe models are database operations-only. This view is fine (e.g., data mapper) but then it seems the scope of DRF is beyond REST and should be part of core.
- Kiro 10y agoSo I went and had a look at the quickstart and the first thing it talked about was serializers. Why is that even necessary?
- ralmidani 10y agoI've been thinking about a new acronym for a web development stack. I build my apps on GNU/Linux, deploy via Apache, and use Django (with DRF) and Ember. So how does "GLADE stack" sound?
- mpicard 10y agoWow dynamic client libraries, holy crap I'm mind blown I can throw out my thin requests wrapper and never maintain it again.
- eljulio 10y agoWell Django is good for ORM, migration and admin. DRF gave a new opportunity to provide new web technology to this old framework but it's not enough. The global stack is very heavy and it's very complicated to use Websocket. I was fan of Django but for me the future is in framework like phienix: light stack, fast, secured and supporting current web technology. It's avoid you all the time loose to implement tornado/rabbitmq stuff.
- kennydude 10y ago"global stack is very heavy" is quite subjective, when a lot of what it provides you generally need or end up writing yourself Django Channels is coming in 1.10 which will make realtime better.
- MrBra 10y agoHow does it compare to Code Igniter from 10000 feet?