> UI other: bootstrap / kendo UI / dojo / jquery UI / ... ? whatever you feel more comfortable, get something working first, but I wouldn't use jqueryUI and wouldn't pay for kendo at least to begin, after I got something working and the situation proves I need kendo I would buy it.
> JS framework: angularJS / backbone.js / ember ? (btw, I prefer declarative over algorithmic coding) If you need to start learning something I would choose angularjs, but if you are already familiar or prefer something just use what you like > BE API for browser FE: just pure django views or anything else? what other option would you have other than django views? > BE API for web services integrations: TastyPie? (API will have to be versioned, I would like to have the auto documentation, too) I like tastypie, but use it only if you actually need it > Cache: reddit? memcached? how would you use reddit for cache? > BE - app server: Django (for sure :), Celery / Rabit MQ? It seems you are confusing the things here, none of them are application servers django is a framework, the application itself would be using it to serve the application I would use nginx+uwsgi, nginx is a webserver, uwsgi is the application server > Authentication: (it is not a social app, therefore the own login is acceptable. Eventually there will be needed some sort of SSO from corporate environment - how to do that?) + eventually python-social-auth for public SSO (e.g. for SMEs, who use GApps?) So don't worry for now, worry then, there are django apps for that, you can plug additional auth backends later or even write your own > Search: Whoosh? (there will be searchable cca 100 000 records, every record is ala github ticket. Nevertheless search should form some sort of group-based selection wizard, therefore I do not like the Haystack limitations. Solr etc. seams to be overkill now. My suggestions here is to create a stage server, populate and test with some of the most popular, it looks like you already ruled out haystack In any case this shouldn't influence on the alpha version, use the DB for search for now, while you are only making the prototype after you start seeing performance problems start looking for a dedicated engine, remember the first 3 rules on optimizing > BE - DB: PostgreSQL? I like postgres, I strongly recommend it > Deployment: Fabric? yes, but on the other hand this doesn't have much meaning, fabric just makes easier automating ssh commands, it doesn't provide recipes for deployment, you still have to plan this > Supporting: Sentry, New Relic? what kind of support are you talking about? > BE autotests: ??? >FE autotests: selenium? unit tests are very nice, but if you have no experience on it you may waste too much time learning this instead of making the product itself, ideally you should have them before making a release, but make an alpha version first and start thinking about them during beta > CDN: google, maxcdn, other? (for JS, fonts etc.) just serve them from your server, if you see performance problems after releasing the first version you can consider them, and test. this depends on your users location, before using CDN's make the content cachable, in any case refer to the first 3 rules on optimizing On Sat, Oct 18, 2014 at 1:01 PM, Radek Svarz <radek.sv...@gmail.com> wrote: > Hi, > > just imagine you have a chance to create a new application - on the > greenfield (hurray! :) > > The application would be *Software as a Service ala Github, Bitbucket, > JIRA, Mailchimp, Zendesk, Freshdesk*. > > I.e. friendly, direct frontend + some background tasks (initiated both by > cron and users) + API for webservices integrations. > > Users are from corporates and SMEs. App has designed architecture for > ideal zero downtime. > > App would have both URL separated parts and SPA (Single Application parts > for modules) via # in URL. UI should behave like Mailchimp. > > Due to the continuous development the app would have configurable feature > flipping (for both FrontEnd, and BackEnd, might also have for webservice > APIs). > > Usage is on PC browser (IE9+ and others - yes corporates:( ), also for > browsers in tablets (Android Chrome, Ipad Safari). > > *# How would you design the app architecture TODAY? #* > > ------------------------------------------------------------------------------- > > Browser Front End (*please answer at least this*): > > UI for interactive special graphs: D3JS (we have tested several others - > conclusion we must use it) > > UI other: bootstrap / kendo UI / dojo / jquery UI / ... ? > > JS framework: angularJS / backbone.js / ember ? (btw, I prefer > declarative over algorithmic coding) > > > Other::::::(back end,...):::::::::::::::::: > > BE API for browser FE: just pure django views or anything else? > > BE API for web services integrations: TastyPie? (API will have to be > versioned, I would like to have the auto documentation, too) > > Cache: reddit? memcached? > > BE - app server: Django (for sure :), Celery / Rabit MQ? > > Authentication: (it is not a social app, therefore the own login is > acceptable. Eventually there will be needed some sort of SSO from corporate > environment - how to do that?) + eventually python-social-auth for public > SSO (e.g. for SMEs, who use GApps?) > > Search: Whoosh? (there will be searchable cca 100 000 records, every > record is ala github ticket. Nevertheless search should form some sort of > group-based selection wizard, therefore I do not like the Haystack > limitations. Solr etc. seams to be overkill now. > > BE - DB: PostgreSQL? > > Deployment: Fabric? > > Supporting: Sentry, New Relic? > > BE autotests: ??? > > FE autotests: selenium? > > CDN: google, maxcdn, other? (for JS, fonts etc.) > > > Overall constraint - we love Django, so we want to build it on top of it. > :) > > > We have the vision that the application would be there for a long term > period. Therefore we need ingredients which are maintainable. > > Please provide the structural answers :) > > Thanks, > > Radek > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at http://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/fd22c91e-0474-4266-af39-2740ef3d2370%40googlegroups.com > <https://groups.google.com/d/msgid/django-users/fd22c91e-0474-4266-af39-2740ef3d2370%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFWa6tJ-98yFNawo875gDB-hGkGPJzkgUYeDZ%3Ddqn5G8%2B_%2BU6g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
