On the other hand, if you don't anticipate hundreds of users, then a cheaper option like Digital Ocean may meet your needs better. There minimal servers start at $5/month.
Don't get me wrong, I love Aws, and I use it all the time. It just sounded like your needs were modest, so thought that might be a better fit. Aws may have a bit better stability than DO in the long run, but for the apps I run there, uptime has not posed a problem so far. Good luck with your app, and have fun. I know I certainly have with this framework. Aaron On 4/29/16, Fred Stluka <[email protected]> wrote: > Patrik, > > I host the servers of all my clients at AWS (Amazon Web Services). > > I'd suggest you start by running the DB server (MySQL, PostgreSQL > or whatever) on the same Linux server as the Web server (Apache, > nginx or whatever). Have the Web server handle all the static files > (HTML., JS, CSS, image) and forward the Django requests via WSGI > or uWSGI to the Django server on the same Linux server. You can > do it all with one AWS EC2 micro instance, which is free for the > first year, and only $0.02/hour ($15/month) after that. > > As your needs grow, you can scale vertically by converting your > micro instance to a small, medium, large, XL, XXL, etc. And/or > you can scale horizontally, by moving the DB server to it's own > EC2 Linux server or to the AWS RDS service. And by using AWS > ELB, Autoscale, ElasticBeanstalk, etc., to manage farms of web > servers and DB servers, allocating and terminating servers as > needed to handle the load. It's a one-line change in the Django > settings file to point Django to the IP address of an RDBMS on a > different server. > > Or turn the entire ops business over to AWS and just use their > AWS Lambda service to serve the HTTP requests. I haven't yet > done that with Django, so you'd have to look into how well it > works. > > For security reasons, configure Django to use a non-root user > at the DB server, ideally one with as few privileges as possible. > And make sure that the DB server is running as a non-root Linux > user. It everything accesses everything as root, you have a big > security risk. If someone DID succeed in hacking your Django > app, and became able to get it to execute arbitrary SQL calls, > they could make an SQL call that causes the DB server to make a > system call (as root), that could run arbitrary code on your Linux > server. So, lock it down at each level, just in case. > > For more info about AWS, see: > - http://bristle.com/Tips/CloudComputing.htm > - http://bristle.com/Talks/CloudComputing/current/ > > For direct printer access from a web app, see: > - http://google.com/search?q=direct+printer+access+from+a+web+app > Lots of hits, so I'm thinking it must be possible. > > --Fred > ________________________________ > Fred Stluka -- mailto:[email protected] -- http://bristle.com/~fred/ > Bristle Software, Inc -- http://bristle.com -- Glad to be of service! > Open Source: Without walls and fences, we need no Windows or Gates. > ________________________________ > On 4/29/16 2:40 PM, Patrik Mjartan wrote: >> >> Sorry, I miss-clicked post button and so I will reply twice now. >> >> Another important (rather obvious to you I guess) question would be - what >> is the usual structure of the servers? >> >> What I mean is - I assume we don't want to have the actual DB on the same >> server as where we host the website. >> >> Is it usually such that Web server is hosted by some hosting company (so >> they can make sure it's up 24/7) while DB server is on the premises of the >> company (ie. the one for which I work for) such that data can be retrieved >> faster? Although I guess that doesn't make too much sense either, as the >> data has to be retrieved by web-server first in order to be presented to >> the user... >> >> Overall I'm quite sure that the company I work for would prefer paying >> some hosting companies to host everything so they don't have to spend >> money on (potentially) expensive hardware. Is this the standard approach? >> >> I'm a total newbie in this area so would appreciate some help ^_^. >> >> >> On Friday, April 29, 2016 at 7:33:58 PM UTC+1, Patrik Mjartan wrote: >>> >>> Thank you very much for the reply! >>> >>> I went through the tutorial a few days ago and loved it. >>> >>> One, very important, question that I forgot to ask - one of the biggest >>> advantages on having an actual desktop front-end app is having a direct >>> access to media, such as printers. Hence a simple button click in the app >>> would result in some document getting printed by default printer (or w/e >>> printer is selected by code, not necessarily user). Is it possible to >>> capture such functionality by web-app at all? Printing PDF documents is >>> not a huge problem (users can just download the PDF invoice and print it >>> manually), problem is for example receipts (in case of future expansion >>> to include on-site sales). >>> >>> If it is not possible to do it directly, I guess it's always possible to >>> make a small stand-alone app that communicates with the server and >>> listens on when it should print certain documents. >>> >>> On Friday, April 29, 2016 at 7:05:52 PM UTC+1, Fred Stluka wrote: >>>> >>>> Patrik, >>>> >>>> Yes, Django can be used for that. >>>> >>>> The "ORM" features and the "templates" and "views" of Django >>>> make it very easy to do a "CRUD" app for a users to create/ >>>> retrieve/update/delete data in any RDBMS. >>>> >>>> There are some built-in security features like logins, protection >>>> against "CSRF" attacks, etc. >>>> >>>> Django "formsets" make it easy to show multiple rows with a >>>> details panel for the row currently selected. >>>> >>>> With a web app, you won't have to re-distribute the front >>>> end. Just push a new version to the server. >>>> >>>> Django's templates and views both support "inheritance", >>>> which should solve your problem of managing multiple >>>> related forms. And, there are many Open Source custom >>>> widgets for Django and for JavaScript that will give you all >>>> the sub-grouping and tree-views that you need. >>>> >>>> Django scales very well to large amounts of data, large >>>> numbers of screens, and large numbers of users. There >>>> are many performance tuning options, including "caching" >>>> of templates, and of fully-constructed pages, and of DB >>>> data. Also, lots of other "middleware" for security, >>>> performance, logging, and other "aspects" of the software. >>>> >>>> Yes, you can run a Django server locally, behind a "firewall", >>>> or can expose it to the world, securing various parts as >>>> needed. >>>> >>>> To make it as secure as possible, I'd put in on a Linux server >>>> that is protected by tools like Logwatch, Fail2ban, and >>>> Tripwire. See: >>>> - http://bristle.com/Tips/Unix.htm#unix_security >>>> And be sure to redirect all page requests from HTTP to >>>> HTTPS. >>>> >>>> I do all of this and more, including processing financial >>>> transactions and supporting "multitenancy", restricting >>>> access by thousands of different users, each to his own data, >>>> plus "attribute based access control" for cases where data is >>>> shared, at the Web site I'm currently working on: >>>> - http://HelpHOPELive.org >>>> >>>> Sorry for all the terms and acronyms, but if you're considering >>>> writing such an app, you'll need to be aware of them and they're >>>> all pretty easy to Google. Feel free to reply with more questions. >>>> >>>> Also, you'll quickly get a feel for Django's power if you go >>>> through the on-line tutorial at: >>>> - https://docs.djangoproject.com/en/dev/intro/ >>>> >>>> Enjoy! >>>> --Fred >>>> ________________________________ >>>> Fred Stluka -- [email protected] -- http://bristle.com/~fred/ >>>> Bristle Software, Inc -- http://bristle.com -- Glad to be of service! >>>> Open Source: Without walls and fences, we need no Windows or Gates. >>>> ________________________________ >>>> On 4/29/16 12:57 PM, Patrik Mjartan wrote: >>>>> >>>>> Hi, >>>>> >>>>> I work for a very small company that I developed an application for, >>>>> all using MS Access (it has back-end MS Access db - although this is >>>>> planned to change to some more robust RDBMS, and a front-end app built >>>>> in MS Access). Currently this app is used to calculate the exact wages >>>>> of some employees (sorry, English is not my native language so I don't >>>>> know how that type of wage is called here, but basically we look at how >>>>> many products they produced and calculate it based on that. It's not a >>>>> hourly wage). However, this summer I would like to expand it to do some >>>>> order management too (ie. each order has specific products that need to >>>>> be produced... each of those can be produced by our employees and so >>>>> it's directly linked to the wages). >>>>> >>>>> However, it is very hard to manage everything using MS Access. >>>>> Basically each time I make any change to FE or BE, I have to >>>>> re-distribute the FE to all of the front-users. This is not a HUGE >>>>> problem, the big problem, however, is within the MS Access itself, that >>>>> is, it's very hard to manage all the forms as they are listed as simple >>>>> names (ie. you cannot sub-group them efficiently to make a tree-view). >>>>> Overall I cannot see myself working with MS Access in 5 years time as I >>>>> can already see the scalability problems after a few months of working >>>>> with it. >>>>> >>>>> What I thought of, however, is making a website that is only for local >>>>> use, but is it possible to have the same functionality as a regular >>>>> front-end app? Is this good idea to begin with? I had a brief look at >>>>> Django (I'm VERY new to web-dev, but I'm a fast learner I like to >>>>> think) and I really like it so far. But is it possible to have the same >>>>> level of functionality MS Access offers? That is, for example a >>>>> sub-form on a form that gives more details about the current record >>>>> selected in the main form? Ie. main form consists of overview of 10 >>>>> recent orders and the lower portion of the main form is a subform that >>>>> displays some detailed info about a selected order. >>>>> >>>>> How does it stand from security-perspective if the app is changed from >>>>> local to public? Obviously even on local I'd imagine I'd put a login >>>>> requirement there, similar to how the admin page has it, but how safe >>>>> is it regardless if put to public? Are there pre-determined measures >>>>> that if taken, it will be 100% secure? As you'd imagine I wouldn't be >>>>> very happy if someone deleted all of our inventory records because they >>>>> could bypass the logging system. >>>>> >>>>> Is there any good literature I can read up on doing some similar >>>>> exercises/examples? For instance: orders/inventory management web app? >>>>> >>>>> Thanks a lot in advance! >>>>> -- >>>>> 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 [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> Visit this group at https://groups.google.com/group/django-users. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/django-users/fdee3fe0-6f3e-4d5b-862c-3a875b04035b%40googlegroups.com. >>>>> 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 [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/django-users. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-users/af709945-ddab-4e9b-97bb-ffc6d36f34dc%40googlegroups.com. >> 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/0f85786b-242c-3cdf-83a3-593634cdf603%40bristle.com. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAERFoOg6M-ciVeefbjnXfEzhe%2BB1htnEVMkHwz7eTO1D3s7VGA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
