3 ms·

Great article, the explanation of rearchitecting the app left me hungry for more! I currently work on a Django project and I'm pushing tastypie to its limit as

Great article, the explanation of rearchitecting the app left me hungry for more! I currently work on a Django project and I'm pushing tastypie to its limit as well. Working on switching to django-rest-framework. At a high level, what does your flask service architecture look like? I dug through your blog but couldn't find much. I'm particularly curious how you handled migrating from a django database and schema to whatever you ended up using.

rdegges 13y ago
At a high level, the rewrite included the following services: - opencnam-accounts (user accounts, and billing API) - opencnam-www (the public facing site and web portal) - opencnam-api (the developer API service) We're currently splitting the backend up into several other components as well, so in the end-game things will look more like this: - opencnam-www - opencnam-api - opencnam-auth (or possibly use Stormpath) - opencnam-billing - opencnam-email (handling drip email, etc.) - opencnam-logs (all logging information, metrics) - opencnam-delivery (telco CNAM retrieval stuff) - opencnam-storage (our CNAM storage product, still in development) Each of the services basically gets their own Heroku app, their own NewRelic monitoring, and their own resources (cache, database (if necessary), etc.). I can't even begin to say how helpful having multiple small apps actually is. Our codebase shrunk in size (total lines of code), became WAY more maintainable, way simpler, and way nicer in general. As a side effect, it's also a lot easier to do teamwork type stuff, since you can have one person work on one service for a while, etc. Makes keeping things running smoothly really easy. I wrote a bit about this in some other blog posts a while ago: - http://www.rdegges.com/service-oriented-side-effects/ http://www.rdegges.com/service-oriented-side-effects/ - http://www.rdegges.com/service-oriented-problems/ http://www.rdegges.com/service-oriented-problems/

rdegges 13y ago

At a high level, the rewrite included the following services: - opencnam-accounts (user accounts, and billing API) - opencnam-www (the public facing site and web portal) - opencnam-api (the developer API service) We're currently splitting the backend up into several other components as well, so in the end-game things will look more like this: - opencnam-www - opencnam-api - opencnam-auth (or possibly use Stormpath) - opencnam-billing - opencnam-email (handling drip email, etc.) - opencnam-logs (all logging information, metrics) - opencnam-delivery (telco CNAM retrieval stuff) - opencnam-storage (our CNAM storage product, still in development) Each of the services basically gets their own Heroku app, their own NewRelic monitoring, and their own resources (cache, database (if necessary), etc.). I can't even begin to say how helpful having multiple small apps actually is. Our codebase shrunk in size (total lines of code), became WAY more maintainable, way simpler, and way nicer in general. As a side effect, it's also a lot easier to do teamwork type stuff, since you can have one person work on one service for a while, etc. Makes keeping things running smoothly really easy. I wrote a bit about this in some other blog posts a while ago: - http://www.rdegges.com/service-oriented-side-effects/ http://www.rdegges.com/service-oriented-side-effects/ - http://www.rdegges.com/service-oriented-problems/ http://www.rdegges.com/service-oriented-problems/