I am currently creating a website hosted by Django. I plan to use React as my frontend framework. I have done some research on putting them together but most say that I should go for the SPA model and have separate web servers for frontend and backend. The problem is that I wish to use apache as a prod server with django and avoid having 2 separate servers. I have read about the hybrid model and having django serve static files with react.
My Biggest concern is security as I have already setup apache for security and I aware that node.js is somewhat insecure.
What would the best approach be. The separate SPA model or the hybrid model.
I'd say it's okay to go for hybrid model if the project is small and you are the only one working on it and you only want to make things done. I think it's kinda messy to create apps like this unless they don't really worth the time.
But if it's a big project and more than one developer is working on it or will work on it then i highly recommend going with separate web servers one serving frontend app and one django app.
Also note that you don't really need 2 different servers. You can use one server for both and use 2 different which is still not necessary and you can use one web server to serve both.
And security not something that different models can cause to downgrade or upgrade. It's up to you to configure the server and write both frontend and backend apps secure enough to do the work for you.
There are more than one web servers that are as secure as they can be and they work with both django and react pretty well. I used nginx many times to host both django and react apps and i had no problem causing by nginx itself whatsoever.
And for last piece of advice if you will; Creating good quality apps requires a lot of time and energy, working with different technologies that do really good for what they are made for and if you are planning to be a really good developer you should come out of your comfort zone and adapt with new technologies that comes out and they are coming out pretty rapidly which requires you to learn constantly and do things in way you are not used to yet and making things work even if they doesn't seem to be good together at the first look.
I'm fairly new to both Django and Angular. I recognize this is subjective and there are likely many ways to do it, but I'm wondering what best practices people can recommend for laying out such an application. I'm specifically thinking of the case of rich, SPA with the backend being mostly or entirely a RESTful API server, but then I'd like to have a common approach for any apps that serve significant views from Django. (I haven't done enough to decide if the latter warrants using Angular or may be more trouble than its worth).
Specifically:
What are pros/cons of maintaining the front-end code in a separate directory/repository from the backend versus, say, inside a "static" subdirectory of the Django app? In my case I'm the sole developer for now, which has some impact on this decision, but I can still consider myself separate "teams" of back-end, front-end, designer, etc. in the sense that my workflow will put me in one of these roles at a time.
My setup is basically a development machine, SCM in GitHub, and hosted publicly on WebFaction (shared web hosting). I will down the line want to easily grab projects on different development machines, but the primary workflow is just one dev, one prod installation. That said, I'm interested in best practices in real-world projects as I hope a future job may be working with Django.
ADDED: Another point I'm very unsure about is whether the Angular app should/must be bootstrapped by Django. That is, should the front page be served by Django and injected with any data?
PROS:
Can configure URL paths and even API endpoints that change from dev to production, without any alternate config and without these being hard-coded in front-end.
This is maybe necessary for authentication? Unclear to me having not done this yet...
Allows use of tools like the Django debug toolbar app.
CONS:
Couples the front-end to the back-end. What If I want to swap out the latter? What if I want the front-end to work in a sandbox with mock data?
Seems to strongly favor moving all Angular stuff into the Django app layout. At the same time, I don't like having a mix of Angular partials in one place and Django template(s) in another. I am already resolved not to mix NG and DJ templates, as I don't believe much good will come of this.
I also started as solo developer on Django as BE with AngularJS FE. I've put AngularJS files in static folder and everything is fine.
Cons are definitely that you have FE and BE mixed up in one project, but I think that shouldn't matter since you are solo developer. Even if you decide once to hire additional developer (to split FE and BE work) your work wouldn't have any conflicts since one of you would work totally independent.
One of the pros for me is definitely I did entire login process via Django (templating as well) and once login went fine I served rest of the FE (entire AngularJS part).
For Django REST I've used TastyPie. It's great REST enhancement for Django and easy to set up.
I am developing a web app using django for server-side. It has clients in android, ios and frontend. I was thinking of using subdomains for differentiating the urls of these clients. The differentiation is due to the fact that responses to urls are different for different clients.
I was hoping of being able to do using subdomains like android.example.com, ios.example.com...etc. My subdomains are fixed.
Can you help regarding what approach I should take to achieve this. Some options I have read are
Hosting two different project with same database.(Looks quite good for me, but may not be the optimum)
Hosting on same instance using sites framework.(Not sure as to how good this option is)
Hosting using virtual-host(Really Not able to understand how to achieve this).
Using a Sub-domain Middleware, as mentioned in many of answers and also in some Django Snippets.
Please help me with the best option and if possible with links to some tutorials as to how to achieve it. Thanks.
"Using the sites framework" is somehow the same as hosting two projects with the same database. If you would use the sites framework you would have seperate instances for each subdomain which share the same code base and data base, but have to differ in one setting in the first place, which is SITE_ID.
If you're able to run multiple instances this for sure has some advantages:
You don't need additional processing via a middleware
You can easily choose different settings for each site, eg. different template paths, use different middleware etc, even customize urls per project if necessary
You're doing already some kind of load-balancing, as you're directing requests to seperate instances, also if one site crashes it shouldn't affect the others
If you can only run one instance I guess your only choice is using something like a middleware, eg. django-mobile then is maybe something to look in as it offers you some good toolset for determining the type of client etc...
But besides that note that it might not always be the best practice to have seperate domains with the same content when it comes to SEO.
At the moment I'm running a Django application that is the same for all of my clients.
Each client has its own subdomain e.g.:
http://client1.myapp.com/
http://client2.myapp.com/
client1 has a settings file, client2 has a settings file etc. The Django app is the same for everyone.
Nginx proxies the requests for each subdomain to a fcgi instance.
So, every client runs its own Django instance, consuming a lot of memory.
Is it possible to run one fcgi instance that switches to the right settings file based on the subdomain that is requested?
Thank you very, very much for your time.
Good question. There was an extensive discussion of this exact problem on the django developers mailing list a few weeks ago.
Basically there isn't a good official solution right now but lots of people are solving the problem themselves in various ways. If you read the whole thread you will probably have a better idea of how to proceed or who to talk to.
I've worked with XAMPP, WAMPP, MAMPP, etc and am starting to look at Django.
A majority of the work we do is very CMS orientated; although we've been told not to use third-party CMS' (mainly because of user's find them hard to use, and other issues), I've found that I can code a very simple CMS using Cake, CodeIgniter or one of the other PHP frameworks.
And yet, I'm getting increasingly frustrated with the amount of coding I need to do just to get something up and running, and I've been told that Django is a good Python framework to use. It also seems to get a lot of buzz from reddit.
I have some concerns and queries about moving from XAMPP to Django.
1) Security
Any web app should be coded defensively. Over the past few years we've seen a movement towards protecting against XSS, SQL injections, Cross site forgeries, session fixation, session hi-jacking, cookie hi-jacking; the amount of security one needs can be overwhelming.
What things does Django do to prevent/limit XSS, SQL injections, Javascript injections, and santizing input; one normally associates with securing PHP web apps? Is it something I need to worry about, or does Django do all this stuff out of the box.
2) What goes in the /www/ public folder?
In a manual I read it said not to put manage.py or the other .py stuff in the main webroot, so this means I put everything outside of the webroot; so what goes in there?
Do I put the /templates/ directory inside the webroot? How does the server know what to run?
3) Can I still use .htaccess on Django projects? I am familiar with Apache and often use it to do routing, or blocking off bad bots, but will using .htaccess still work?
4) Cronjobs
Do cronjobs still work with Python/Django projects?
5) Running Third party perl/other scripts
In PHP you can use other libraries such as the curl library, ffmpeg, ImageMagik as well as many others; can I still use these libraries with Python/Django?
6) Admin screen
Django gives you an out-of-the-box admin screen; is this only for development purposes or can it put live? I am concerned about any the security of the admin screen.
7) Integration with Discuss, Facebook, Twitter, OpenID, captcha, etc.
There are libraries in PHP that help integrate DisQuss, Facebook, Twitter; but is it relatively easy to do an integration with these and other third party apps?
8) E-commerce, SSL
Are there many e-commerce sites that use Django? I've seen a lot of CMS/Blog type software but not many e-commerce sites. By which I mean, shopping card, Protx/Paypal or Worldpay integration.
That's another thing; there are sandboxes for Protx, Paypal, Worldpay etc for PHP -- but are there any for Django?
9) Is it worth it?
Is it worth moving to Django from an XAMPP background? Will it really make things faster, or is that just marketing hype?
Thanks.
Security. The Django core team are very security-conscious, and have taken great care to make things like SQL injection impossible. The next version, 1.2, includes a whole new cross-site request forgery protection library. Obviously, you still need to be aware of these when developing your application, but Django does a lot to help you.
What goes under /www/public: Nothing. Django doesn't work via the normal Apache serving mechanism: it hooks into (preferably) mod_wsgi, which needs a single file which then tells it to run the rest of the code. The templates can go anywhere, and are pointed to by your Django settings file, but again aren't served directly by Apache.
.htaccess: You don't really need it, because of point 2: you're not serving things in a filesystem hierarchy. The best way to do it is to set up vhosts and manage things that way.
Cron jobs: Absolutely. Django is just Python, and you can easily run Python scripts via cron. Django allows you to set up custom command scripts which initialise the ORM and give you access to anything you would need.
Libraries: Again, because Django is Python, you get access to the huge amount of Python libraries that are out there. For curl, Python has urllib; for ImageMagick, it has PIL; and no doubt there are equivalents of ffmpeg too.
Admin: Again, security has been thought of from the beginning. Opinions differ as to whether you should use the admin only for your expert users, or customise it and allow access for all users; I've had a lot of success using it as the basis for my custom CMS interfaces.
Facebook, etc: Yes, there are libraries for all of these.
E-commerce: There is a whole e-commerce project, Satchmo, written in Django. Libraries exist to interface with all the payment providers.
Is it worth it? Only you can tell. My experience working alongside a range of developers who have moved from PHP is that they've enjoyed the experience and became much more productive.
On SQL Injections: Django uses an ORM, which takes care of SQL injection protection, and you will rarely write you own SQL. If you do, just follow the instructions on how to pass parameters to raw queries and prevent SQL Injections.
There is an entire chapter on the django book about security that should answer all your questions.
On what goes into /www/: anything that is not code? The concern is to not put the python code there.
On .htaccess: Yes, it should still work (for any non Django resources as Daniel points out).
On cronjobs: what do you mean?
On Libraries: Python - the language you will use with Django - is rich in libraries that probably provide the same functionality you are used to. This is a key point: you will need to learn Python well to benefit the most from Django.
On the admin interface: This is actually the thing that will probably help you the most, judging from your question. They are customizable (within some limits) and they really give the staff (it is not intended for public users, but for staff users) the basics of CRUD for your database models. It is a time saver. You might need to write your own templates for advanced functionality, but for most simple CRUD aimed at staff (which is usually the point of a CMS) it is very useful and easy to set up.
On integration: Check Pinax for a group of applications that provide extra functionality. There is a rich and diverse universe of integration solutions out there. It is not unusual to find questions here in SO about django + facebook and others.
On E-commerce: Check Satchmo out.
Is it worth it: Now, I have no experience with XAMPP. I know that I like Python better than both Perl and PHP (and Java, for that matter). I know that as a framework Django is simpler to use, faster to deploy than anything I used before.
My suggestion is the age old: go build a simple project and make up your own mind. You are the only one in position to decide if Django is the framework for you.
An older question on SO discusses some Django limitations. My answer to that might be helpful to you too.
I recently moved to developing any new projects in Django, coming from a PHP background. Here are my thoughts on your questions.
1) Security
Strings sent to templates is escaped by default, which takes care of most of that. Since you're using an ORM, SQL injection shouldn't be an issue unless you build raw queries for some reason.
2) What goes in the /www/ public folder?
Django doesn't use a file hierarchy for URLs like a typical PHP setup. The server knows what to run from your urls.py and settings.py pointer to the template folder.
3) Can I still use .htaccess on Django projects? I am familiar with Apache and often use it to do routing, or blocking off bad bots, but will using .htaccess still work?
As noted above, it works for static content just the same. For dynamic pages, you'd want to implement some other form of authentication or redirection for clients you want to block, as far as I know.
4) Cronjobs
There's no reason why you can't use cron for whatever, as you still have a normal Linux system.
5) Running Third party perl/other scripts
You'll want to use the Python versions of those libraries, of course. For instance
FFMpeg
PythonMagick
I replaced most of my need for Curl with the built-in urllib and urrlib2 libraries, but there is also PyCurl if you need it.
6) Admin screen
The Admin screen is intended to be used by your own admins, i.e. site staff. It may be possible to do so, but it's not supposed to be the scaffolding on which you build your public facing project.
7) Integration with Discuss, Facebook, Twitter, OpenID, captcha, etc.
There are a lot of people out there using Python and Django, and I haven't had any problem finding libraries. In my experience there is a bit less support for something than PHP, but what is there is often higher quality.
8) E-commerce, SSL
I haven't tried payment integration, so I can't say. Not sure about the other sites, but the Paypal Sandbox is run by Paypal, isn't it? I don't think it's related to what you're using on the server, so sure, you can access it like normal.
9) Is it worth it? Is it worth moving to Django from an XAMPP background? Will it really make things faster, or is that just marketing hype?
I moved to Django because Python is truly a more compelling language than PHP. Will it make things faster? I'm not sure what the advantages in that respect would be for Django vs.the PHP MVC frameworks. There are no magic bullets.
You do have to keep in mind that you're not just learning a new framework, but also a new language. There will be a bit of a learning curve if you've never used Python before. but I've found both Python and Django to be fairly easy to learn. The clean design of the language is fantastic and Django is veryt well designed, too. I do feel that it's boosting my productivity. I've found snippets for or articles about most everything I need to do in Django as I've been learning, so adapting has been pretty simple.