tmwatson100

love this

What sort of classes do you mean? Views? Models? Other? For us it hasn't changed much. Our apps were pretty self-contained so that splitting them into separate services isn't very arduous.

Stuff that is shared between apps is often related to 3rd party integrations, which could be moved into a separate (often asynchronous) worker/ service. In reality most of these design choices are done on a case by case basis, based on time/ cost/ maintenance.

It depends on what you're building. For us, we haven't noticed any issues with latency just yet and there are plenty of steps you can take to optimise this down the line.

As for monitoring there are plenty of tools to do that. You have bigger problems if you expect your services to go down often.

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.

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.

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

I perhaps should have explained that a bit more. Technology choices have to make sense before implemented but giving developers the flexibility opens a lot of doors for creativity and exploration.

I strongly believe that learning new languages help people become better coders overall as it increases their knowledge of different problems and solutions which can be applied across most stacks.

Also no one developer should ever be solely responsible for a particular service. But that should also be the case for apps within a Django project.

Correct, writing code does not make money. However this change is a little bit like starting a blog... You don't see the immediate benefits straight out but you'll realise them over time. You can put it off and put it off but the longer you do the harder it gets, especially in this scenario.

This architecture doesn't make sense for everyone and we could have continued with Django. But making these changes now mean that we will be able to fix all the above a lot quicker going forward.

Not worrying too much doesn't mean not worrying at all! We still have tools in place to ensure silly mistakes aren't made or are at least rectified quickly. Just we don't expect 100% test coverage on every single feature or fix we ship.

This approach will probably change as we get larger but being a small development team means that it is fine for now.