#pyramid

i have a small(er) project that i’m building that conists of 1) data aggregated through an API, 2) data aggregated through another api, and 3) a web project. piece 1) relies on tornado for pulling data (i’m using yelp’s bravado library for a swagger api). piece 2) relies on querying google. and piece 3) is pyramid. should i modularize the code into three different code bases? if so, can anyone provide a blog post / resource t

helps me think about how i should actually split these up (i’ll be sharing sqlalchemy models).

yeah, i know.

no advice from me, but I'd be mildly curious to see what you setle on

settle

[redacted]

[redacted]

dowwie: yep

[redacted]

i guess i’m wondering if i would then have 4 packages, prod_common, prod_web, prod_aggregator_1, prod_aggregator_2

yes

NotreDev: don't try sharing models

Charlie_X: precisely my concern!

Charlie_X: please go on

[redacted]

If you have clearly defined APIs then I don't see many problems.

dowwie: they’re independent services because the aggregators are just worker jobs. they feed the web app, but aren’t necessarily of value to the web app

might's well make 'em boring old REST APIs; that way they can run on different boxes on different domains, if necessary

[redacted]

[redacted]

[redacted]