Re: Is it good idea to transition from MS Access to a webapp? And if so, is Django a good tool to do it?

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 <fred@bristle.com> 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:fred@bristle.com -- 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 -- mailt...@bristle.com -- 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 django-users...@googlegroups.com.
>>>>> To post to this group, send email to django...@googlegroups.com.
>>>>> 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 django-users+unsubscribe@googlegroups.com.
>> To post to this group, send email to django-users@googlegroups.com.
>> 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 django-users+unsubscribe@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> 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 django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
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.