I think there’s some risk with this though too - more and more is behind the enterprise tier. People try to work around this in various ways but its an unsatisfying experience. For e.g. trying to enforce merge request approval with pipeline stages.
In practice the library ecosystem is just way behind Python. Maybe after you’re trying to optimise once you’ve worked out how to do stuff, but even the Langchain Go port is wayyyyy behind.
I live in a city with trams in the UK and that’s not how it works. There are sections that run on dedicated train lines, and sections where it runs on the street. Where it runs on the streets, priority is given over cars by switching traffic lights to red. Once the tram has passed onto the road it switches back to green so you can end up following the tram in your car.
Other thing is that when you’re VAT registered, as a buyer of parts you reclaim VAT on things you purchase as inputs. So the tax on the final product is what matters.
With US sales taxes you accrue tax all the way up the chain.
It’s interesting because BBC Sounds replacing iPlayer Radio was one of the worst redesigns I’ve ever seen for discoverability. Even now, several years on, it’s considerably worse. Whatever the technical merits of the migration, finding radio programmes became much much harder, all while they push podcast content.
You cant use the embeddings/vector search stuff this refers to in self hosted anyway, it’s only implemented in their Atlas Cloud product. It makes it a real PITA to test locally. The Atlas Dev local container didn’t work the same when I tried it earlier in the year.
> working for Rolls Royce in the middle of nowhere
Most people I know who ended up at RR live in Nottingham or the Peak District and commute in to Derby. Appreciate that’s perhaps not as exciting as London but it’s hardly a shit hole up here.
Agree on pay though. I work for a different engineering conglomerate (foreign owned) and I applied for a HPC role at RR a couple of years ago and the salary was £20k lower. The disparity would be even more now.
I’m 33, in the U.K. and my marginal tax rate is currently 66.7%, because the support you get for having children gets withdrawn between £60000 and £80000. If a promotion came up I would take it but it’s also at a point where I’m considering already dropping down to four days a week because of this. I don’t live in London so my life is very affordable. Save myself money on children’s nursery for a few years too…
It depends on how much you want to rely on Mixins and using Serializer classes to do more than just serialise JSON. Neither of those are compulsory to use, and the more you lean into them the more inheritance you’re forced to do as soon as you need to customise the behaviour.
Bonds are much less risky too. So when interest rates were low, it made sense for investors to put money into companies because with bonds you got a tiny return guaranteed vs a high risk but potentially large payoff.
Now, bonds are guaranteeing a 5%+ return, so a non-profitable business is much less attractive as a proposition.
ModelManagers are directly coupled to one model though. You mix concerns if you need to reference other models in them.
For e.g. say you have a User model and a corresponding “Profile” model. If you need to create the profile object when the user is created, it doesn’t really feel appropriate to put that in a UserModelManager directly coupled to the User object. This is the example given from the Hacksoft Django style guide to advocate creating a service layer.
In terms of the abstraction, I totally agree and tend to be pretty pragmatic about this sort of thing.
CBV doesn't require you to do anything in particular other than implement retrieve/list/etc. methods on the GenericViewSet as needed, and get/post/etc. on GenericAPIView. You can use the convenience methods in Django and mixins, but as soon as you get beyond a simple case, they start to become a hindrance.
The only thing beyond that that I'd recommend is specifying a get_serializer_class method since it simplifies your boilerplate and plays well with drf-spectacular for generating your API documentation. I generally don't use ModelSerializer unless the logic is very simple, I've been meaning to write a blog post for a long while about avoiding it when your data model is split across two database tables.
I disagree with the idea of not having a service layer at all, because in practice, changing your data model in some way is actually pretty common, even if the API remains the same so the data coming in/out isn't changing. I've had to split models into multiple parts to add audit history on certain fields, create notifications on object creation or modification (possible but hard to follow and a visibility problem when using signals), change the normalisation on fields, etc. etc. and at this point, turning to a service layer is much more appropriate than putting methods on the model since often the data is split across multiple database tables. I also would advocate this in projects where it's Django + DRF since you generally want exactly same logic to be run through whether submitting via a form or submitting via an API.
I've also found that it's good practice to impose boundaries between apps so that they are not strongly coupled together but communicate through an interface. That way, if you need to split an app out into its own project at some point, the migration is significantly easier from a code perspective, since the implementation of the interface function is all that needs changing on the consumer side.
I had exactly the same thing last year with a previous long departed staff member having forked django-flex-fields into their personal GitHub and having made substantial changes. Porting to Django 3.2 then became a huge and costly project in itself as a result.