[Pulp-dev] 3.0 API module organization question
pcreech at redhat.com
Wed Sep 14 20:08:50 UTC 2016
On Wed, 2016-09-14 at 15:34 -0400, Sean Myers wrote:
> We've got a bunch of models, so we (wisely, I think) break them up
> into submodules in the platform app's models namespace so that they're
> easy to find.
> In my work on the 3.0 REST API, I'm mirroring this layout when defining
> the serializers, because we're pretty likely to have at least one
> serializer for every model, and we're also pretty likely to have
> a few custom fields on those serializers, as well.
> This is working well, but seems to me to be a bit of a rabbit hole when
> other API components are taken into effect, particularly ViewSets. Each
> API endpoint is represented by a ViewSet, and each ViewSet is related to
> a Django Model and that Model's Serializer. While we won't necessarily
> have a ViewSet for every Model, we're pretty likely to have a whole lot
> of them, so it seems like they should be similarly organized.
> So, my question is: Should we generally break up Model-related objects the
> same way we've broken up our models (like ViewSets, Serializers, etc)?
I am for this. I have done similar in the past, with other codebases. It can make for a little
more investment effort, but I believe it will pay dividends later w/r to codebase organizaition.
> All objects (Models, Serializers, ViewSets, etc) are in a single
> module's namespace. This makes them easy to discover when initializing
> apps, and also raises errors related to circular import issues very
> quickly. Discoverability, in particular, is Pretty Important™.
All seem to be very good and important Pros to me.
> /me writes pulp.app.models.foo.Foo
> /me imports Foo into pulp.app.models
> /me writes pulp.app.serializers.foo.FooSerializer
> /me imports FooSerializer into pulp.app.serializers
> /me writes pulp.app.viewsets.foo.FooViewSet
> /me imports FooViewSet into pulp.app.viewsets
> /me is le tired, but gets over it because at least things are consistent?
> I think it makes sense to keep things broken up just like the models, but
> I'm nervous about how deep this rabbit hole might be, and if at some point
> it just becomes a ridiculous maintenance headache. :)
/me thinks if that bridge comes, we can cross it then
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 473 bytes
Desc: This is a digitally signed message part
More information about the Pulp-dev