Hacker News Reader

Comment by n0us | Hacker News Reader

If you're writing a REST api, invest the time to learn Django Rest Framework. It is well worth it.

DRF is nice enough 90% of the way, but when you need to do something that its authors haven't really thought of, you need to dig in very deep to fix things, I've found. :/

Agreed, for this reason I stopped using it, the investment in those digs were not worth the time to not copy/paste some CRUD api views. Which is what I do now, and modify as needed.

If the number of models and views grows too much and gets brittle, maybe it will be worth trying again.

I think this is true of django in general.

> I think this is true of django in general

Probably goes for all opinionated frameworks. That's part of the tradeoff you make when choosing one.

If that's the case, you should take a step back and think about it from another angle to make absolutely sure that you're not attacking the problem from the wrong vector.

I have heard great things about DRF, and often it is good to resist coloring outside the lines.

That being said, your comment assumes that DRF has indeed thought of everything. All abstractions leak, some more than others. Clean escape hatches are very valuable.

I never said that you MUST be thinking about it wrong. I just said to make sure you're not thinking about it wrong. No framework has thought of everything.

Ah, my bad, I should have noticed that.

DRF's code is realtively easy to read and it's designed in a way where you can just roll your own parts quite easily.

I had that issue for a while, but lately I've really just found that 95 times out of 100, I can accomplish everything I want to do with just a .to_native() and using whatever method I see fit. I know it's not always the most optimal way, but leveraging that allows me to really use DRF for so many projects and get it up easily and without too much hassle.

Seconded. It provides an API similar to that of Django's various Form classes. It should feel somewhat familiar, even to newcomers. Their documentation is also great with rich examples and explanations.

It's my understanding that you can use Django's Form classes to replicate any POST/UPDATE/DELETE operations you'd like to use DRF for. I'm not sure what else DRF gets you besides more API-like auth - for example I don't know how well Django would support token-based auth out-of-the-box as compared to DRF.

You get:

* pluggable authentication methods (literally adding JWT, session and cookie tokens takes one line of code * pluggable output serializers (want YAML? Plug in a renderer. XML? Same thing) * pluggable documentation generators * Utility methods for handling RESTful response types

DRF has a staggering amount of features that, if implemented by hand, require a stupid amount of time and a 100% guarantee of subtle bugs.

Isn't Flask simpler for REST stuff?

Sort of, but you'll have to assemble several different libraries to make it good. It doesn't handle request validation, JSON serialization/deserialization, or databases well out of the box.

If you use Flask with Flask-SQLAlchemy be sure to use apply_driver_hacks to enable the pool_pre_ping option or you'll end up in production wondering why 1/3 of your requests are getting a bad DB connection from the pool.

Honestly, it seems like many somewhat essential libraries for Flask APIs are being maintained by one person on GitHub. I wouldn't want to put my faith in that for a core part of my business. Django has a lot more resources going into it even if it's not as powerful as SQLAlchemy or as simple as Flask.

Hug [0] has my goto for REST. Validation, versioning, serialization, automatic documentation.

[0] http://hug.rest

This looks great! I've been keeping my eye on APIStar but that still seems like it's undergoing a lot of breaking changes. This delivers a lot of the same benefits but it looks like it's actually production ready!

Flask-Restful seems pretty well maintained and it's very easy to use. If you use marshmallow it's very easy to get request validation with meaningful errors. There is also a package called apispec that can make a Swagger specification from your flask paths and marshmallow models. I like Django but unless I'm using it already I've not seen a reason to use it instead of these simpler libraries for APIs.

For simple stuff yes.

When you have to do an small API in Python is what I use.

Define, "simpler."

For a simple CRUD API, if you already have a cookie-cutter template of your REST API sketched out with Django Rest Framework, you can write your models and you're done.

Smarter developers than me have spent much time and effort hammering into my thick skull the following idea: one of the most important aspects of a senior developer is the ability to choose the correct tool for the job.

Flask is indeed much simpler, and serves the needs of smaller apps very well. The reason I've stopped using it is because I'm now familiar enough with Django's substantial, problematic learning curve that building a Django project is now just as easy for me as spinning up a Flask app (django-cookie-cutter and wagtail's project init help with this, but they're no replacement for several years of smashing your head against bad Django code). While I love Django, and have derived much utility from the tools it gives me, it's not the solution to all problems, and there are times when Flask makes total sense.

But once Flask's simplicity advantage is removed by experience, I find that it's immensely useful to have (largely correct) opinions on ORM<->DB interactions, templating, settings/config management, form validation, and user authentication baked into the project. For my projects, having these has never cost me anything even if they go unused, and more than once I've gotten myself into the situation of "You either use Django or build Django"

All of the above applies even more so to the specific task of producing a rest API. DRF is, by a large margin, my favorite tool for producing robust, understandable APIs, and I've been lucky enough to never encounter the scaling issues that I've been told (and believe to) exist.

Only if you need to implement simple CRUD API. But if you need filtering/ordering/authorization/complex serialization/unconvential request parsing -- you would need to implement a lot of stuff or install a lot of packages and find a way to make them work together. DRF makes all this things for you.

Agreed, but with the caveat that there are a lot of bad parts of DRF. It's probably the best tool to build a REST API, but only if you're using some minimal subset of the tools available.

What are the bad bits? Why are they bad?

Too many issue to enumerate them here, but there are just a lot of things that are likely to lead to security vulnerabilities or hidden performance problems. I'm planning to write a blog post on this in the next few weeks.

How do I subscribe to get it?

I'll post it here, you can subscribe via email:

http://alexkrupp.typepad.com/

Reply on news.ycombinator.com