Hacker News Reader

Comment by drbryanadams | Hacker News Reader

I don't get it: why does moving to microservices mean ditching Django? Couldn't you take your Django monolith and break it into separate (still-Django) microservices? I get that Django is seen as "too heavyweight" to do such a thing, though there are literally books (http://shop.oreilly.com/product/0636920032502.do) written about how to slim down Django.

I get that monolith to microservice is all the rage these days, I just don't understand (and the article doesn't really say) why you have to "ditch Django" to do that.

View on HN

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.

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

Why?

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.

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.

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

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.

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.

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

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?

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.

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

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.

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.

He listed one of the benefits of microservices as freedom to use whichever languages/frameworks developers prefer.

Sure, but the title says "ditching Django" ... presumably if they have a Django monolith, at least some of the devs might choose Django for some of the microservices?

Maybe they are still using Django in some capacity and the title is just slightly overstated ... not sure, but would appreciate an author comment in this regard.

Yes you're right it is slightly overstated. We still use our Django monolith to compensate for not re-writing every single part of our codebase.

However overtime I would imagine we would move away from Django as with small enough services it would be overkill as a solution.

Saying that, if it makes sense at the time then why not. With this architecture you have the flexibility to do that.

Sure -- not looking to nitpick. I just wanted to understand if there was something about Django that you found incompatible w/ microservices, and it sounds like there isn't.

An overstated headline isn't the worst crime on the planet (though, I would say that Google has already carried the headline far and wide already ... sigh).

I could see that freedom becoming technical debt if the project is big enough and poorly documented.

I keep picturing the legendary missing Novell server that was buried behind drywall at the University of North Carolina:

http://arstechnica.com/civis/viewtopic.php?f=2&t=1824

Reply on news.ycombinator.com