4 ms·

Interesting points. Yes there are many parameters that could be application specific but i was wondering if some of them could potentially be provided as librar

Interesting points. Yes there are many parameters that could be application specific but i was wondering if some of them could potentially be provided as libraries ? for example, able to select subdomain style vs. others, set a billing cycle with certain parameters? etc. Or am I already too specific to be a framework ? Just wondered.

bmelton 14y ago
I mean, Django and RoR are typically (with high degrees of arguability) the types of frameworks people use for this sort of thing. There are a variety[1] of[2] ways[3] you can implement subdomain keys in Django, but each is effectively downloadable from somewhere and installable, possibly just with pip. Again, there are a myriad[4] of ways to implement payment processing and subscriptions using Django, easily installable, but picking the right one for your application type is up to the architect. Creating one monolithic payment library that supports every possible payment type, subscription method, payment gateway provider, etc., is just asking someone to build a bloated app. I'd much rather drop in 'payments-with-stripe' if I'm using Stripe as my payment gateway than to install 'omni-payments' and have to spend the day configuring it to work how I want, then worry about the size of the codebase and the likelihood of human error. Like I said, most of the things you're looking for can either be dropped in or just coded in a day. [1] - http://thingsilearned.com/2009/01/05/using-subdomains-in-django/ http://thingsilearned.com/2009/01/05/using-subdomains-in-dja... [2] - https://github.com/tkaemming/django-subdomains https://github.com/tkaemming/django-subdomains [3] - http://code.google.com/p/django-accounts/ http://code.google.com/p/django-accounts/ [4] - http://www.djangopackages.com/grids/g/payment-processing/ http://www.djangopackages.com/grids/g/payment-processing/

bmelton 14y ago

I mean, Django and RoR are typically (with high degrees of arguability) the types of frameworks people use for this sort of thing. There are a variety[1] of[2] ways[3] you can implement subdomain keys in Django, but each is effectively downloadable from somewhere and installable, possibly just with pip. Again, there are a myriad[4] of ways to implement payment processing and subscriptions using Django, easily installable, but picking the right one for your application type is up to the architect. Creating one monolithic payment library that supports every possible payment type, subscription method, payment gateway provider, etc., is just asking someone to build a bloated app. I'd much rather drop in 'payments-with-stripe' if I'm using Stripe as my payment gateway than to install 'omni-payments' and have to spend the day configuring it to work how I want, then worry about the size of the codebase and the likelihood of human error. Like I said, most of the things you're looking for can either be dropped in or just coded in a day. [1] - http://thingsilearned.com/2009/01/05/using-subdomains-in-django/ http://thingsilearned.com/2009/01/05/using-subdomains-in-dja... [2] - https://github.com/tkaemming/django-subdomains https://github.com/tkaemming/django-subdomains [3] - http://code.google.com/p/django-accounts/ http://code.google.com/p/django-accounts/ [4] - http://www.djangopackages.com/grids/g/payment-processing/ http://www.djangopackages.com/grids/g/payment-processing/