3 ms·

I actually prefer #5 because you are explicitly “exporting” the parts Django cares about and ensures you aren’t stomping on other models. The part that stinks i

I actually prefer #5 because you are explicitly “exporting” the parts Django cares about and ensures you aren’t stomping on other models. The part that stinks is dealing with cyclical imports. At the end of the day it comes down to discipline and leaning on the framework to help keep things clean is Not A Bad Thing(tm) IMO. But I am not one that feels like it robs me of my expressiveness because I’d rather have something consistent to build on across multiple projects instead of trying different patterns within the web stack that flask / fastapi let you get away with. That being said, fast api seems great especially if you don’t have to deal with the overhead of user management and such directly.

skrtskrt 6y ago
In my experience, within an organization that runs services/microservices, having a service template is a good way to handle having a consistent approach across services instead of each team picking their own favorite libraries to flesh out a small/micro frameworks like FastAPI or Flask. Any internal libraries should be very very light wrappers, if they exist at all. Putting more into the service template or even using code generation allows things to slowly improve and change without being pinned to some old crappy code in a shared internal library, or managing breaking library changes across teams.
theptip 6y ago
I think the "Djangonic" approach would be to make this configurable, but with defaults that give you convenient magic for the simple/happy path. For example template paths are completely configurable (indeed you can plug new lookup strategies in addition to just overriding the default paths), but the defaults are "look in this well-defined location". This is more of a DX gripe than a reason not to use Django, it should probably not be in my list if I'm being fair.

skrtskrt 6y ago

In my experience, within an organization that runs services/microservices, having a service template is a good way to handle having a consistent approach across services instead of each team picking their own favorite libraries to flesh out a small/micro frameworks like FastAPI or Flask. Any internal libraries should be very very light wrappers, if they exist at all. Putting more into the service template or even using code generation allows things to slowly improve and change without being pinned to some old crappy code in a shared internal library, or managing breaking library changes across teams.

theptip 6y ago

I think the "Djangonic" approach would be to make this configurable, but with defaults that give you convenient magic for the simple/happy path. For example template paths are completely configurable (indeed you can plug new lookup strategies in addition to just overriding the default paths), but the defaults are "look in this well-defined location". This is more of a DX gripe than a reason not to use Django, it should probably not be in my list if I'm being fair.