[eliben]

Seconding this. Could someone clarify?

I thought Django and "microservices" are orthogonal. Can't Django be used to create any service, even a micro service? I certainly used Django in the past just as a REST server, without any "web site" to speak of. It just reduces some boiler plate.

[adambratt]

Using Django Rest Framework is practically the EASIEST tool for building microservices I've ever used. It's incredible how awesome it is for building APIs. We were recently looking at building out some new services in Flask or Express. We compared the advantages of each to DRF and quickly concluded that it wasn't worth it. DRF has so much commonly used stuff done for you and it sets up one of the best standards for REST API's I've ever seen.

[mpdehaan2]

Love DRF. Really easy, super flexible to modify (we did a lot of stuff with RBAC), the API browser is an amazing feature.

[karuth]

Flask is so minimal. Curious what were the disadvantages that weighed against chosing Flask.

[rattray]

Flask is too minimal. Using DRF is like having code written for you. Because, you know, the code was written (and battle-tested) for you. Why start from a log every time when you can get a wheel for free?

[adambratt]

DRF includes all the serialization and loose object structure for you to build off of.

We've been using DRF pretty seriously for over a year and have yet to find a feature that we want that isn't already implemented or easy to implement on top of it.

[tmwatson100]

We actually use DRF. Although I actually find it overcomplicated for what it does.

[adambratt]

Not sure what you're trying to do. But we've found the best part of DRF is that it creates a great structure to build off of and gets everyone writing APIs the same way.

We haven't separated many of our services out but we actually have extended a lot on top of DRF. We created a way to do internal requests, so now instead of passing querysets to HTML views we actually do an internal API call. In the future, that code can be moved into it's own service.

Abstracting things out like this allow us to plan for microservices in the future while not having to deal with tons of different codebases and deploy strategies right now.

In the past year as we've scaled from 3 to 20 developers, I would say that DRF is the single-most crucial element that helped us scale the team without any massive issues.

[eliben]

Gah, it's perfectly possible to use Django without DRF for simple REST services. If you need simple things, it's not a big deal.

[tmwatson100]

Perhaps the title was a tad flippant. You can use Django in a microservice architecture although if your services are small enough I would hazard to say that Django would be overkill for most implementations as it is not what it is designed for.

Saying that if it increases development speed and makes sense in the scenario then I wouldn't shy away from it.

[eliben]

I find the claim "if your services are small enough ... Django is an overkill" baffling. When you're writing a simple program / command-line tool, do you use a minimalistic programming language or do you just stick to your Python / C++ / whatever? If you have Django expertise, how does it make sense not to just use it, and worry about "an overkill" instead? Overkill in what sense? In the extra 500KB of memory Django uses? In the extra few MBs of disk space? I just don't get it.

[raverbashing]

Of course Django can be used for microservices

I don't recommend it, but you can use it

I would prefer to use Django mainly for CMS kind of things

[mbrameld]

Why?

[kstrauser]

My own reasons: because Django is awesome as long as you want to do everything the Django way. For example, as soon as you want to upgrade to SQLAlchemy because every other business unit is already using it, you're in for pain. You can unwire some of those low-level decisions and plug your own code it, but with all the difficulty that usually brings, what's the point of using Django in the first place?

Django was born as a CMS and it really excels there, but it's modeled as a complete end-to-end stack. That's great if you love every single component of that stack, but not so great if you'd prefer alternatives.