I want to use this chain (Angular, not AngularJS) but don't quite understand how exactly it should work in production. Tutorials and simple logic show two variants:
Separate application servers, for example
Apache
Angular on top of Webpack or something
Django on top of Gunicorn
"Folder-style" project separation, like
project-folder\
angular-folder\
...
django-folder\
...
(some config to make it work)
Does anybody have working boilerplate of such an application? Everything I saw was outdated. Can someone show the right path and where to start?
This wonderful blog post by Jonathan Cox introduced me to the use of Django Webpack Loader, a Django app that reads a webpack stats file and loads the required bundles automatically. It focuses on React, but the idea can be applied to any front-end framework that uses webpack as output, I used Vue with great success.
Basically, your development stack will look like this:
Webpack Dev Server or Express for serving your bundle with hot reload.
Django Dev Server, using the webpack loader's template tags to load the bundle from Express' virtual location.
Then in production:
Use Webpack to build the bundle straight to Django's Static folder
Load the bundle from statics, using webpack loader.
Folder structure should be whatever you want, you can separate both code bases or make a new folder at app-level in your Django project to keep it all together. It shouldn't matter, while you can point to the dist folder with STATICFILES.
Related
I've created a simple project with vuejs as the frontend and flask as backend.
The project was constructed by following the example here, thus the resultant file structure is like that the vuejs build files "dist" is on the same folder as that of the driving python script, run.py.
The project was tested and working fine locally now I ran into problems trying to deploy it on my Ubuntu server hosted by digitalocean.
I followed this article to learn how to deploy - the article was well written but I believed I need to change the apache config file (/etc/apache2/sites-available/000-default.conf) a little to specify the static files of my project as shown in the screenshot.
The question is how? I don't know. When I followed the article word by word and launched the web app, it showed errors like:
Loading failed for the <script> with source “http://my_website.com/static/js/manifest.0e78d562f6b86d93f516.js”. vue-amazon:1:1
static is a standard vuejs folder under "dist" in my file structure.
I found the issue has nothing to do with the way how Flask project is deployed - it's about the configuration of the vuejs frontend.
I need to adjust the setting of assetsPublicPath in vuejs's config file, to a proper location where the index.html can find the obfuscated javascripts.
For example, if my project is called "ABC", and i want the url looks like:
http://my-site.com/ABC
I need to have this in the vuejs config file:
env: require('./prod.env'),
index: path.resolve(__dirname, '../../dist/index.html'),
assetsRoot: path.resolve(__dirname, '../../dist'),
assetsSubDirectory: 'static',
assetsPublicPath: '../../ABC/dist/',
before I run
npm run build
Currently I have react app that is consuming rest API written in python. But I want to know whether can I use React to generate template and render it from server?
Depending on what server side framework you are using, you can build a static version of your react app and serve it from your static directory. If you peak around this github repo, you'll see it does exactly that with a Django app: https://github.com/ethankulman/react-django-boiler
To create static version of your app, you'll want to go to your react directory and use the command
npm run build
You'll see a new folder in your directory named "build" and it contains all the necessary files to serve your app statically.
I've recently started my python/django walkthrough and there's still a question that bothers me: I dont find a really easy, unobtrusive, painless way to deploy a Django app =(. I only see tutorials of mod_python, fastCGI, wsgi stuff - all of them are necessary for each webapp I create..
I'm used to Java web-apps (JSF+Tomcat) and I'm used to just drop the *war package in the webapps folder. Or uploading the *war through tomcat-manager. Or, even better, make a maven-hot-remote-deploy. And as far as I'm concerned, simple PHP apps also need minimum config (after setting up the apache2 conf, just cp the php-webapp-folder to /var/www/ would do..). I cant believe that Python lacks this kind of feature =((
My point is: after a clean OS install (let's take a JEE-VPS for example), I only need do setup my web server once. If I develop the webapp01, I choose one of the options above to deploy it. When I develop my webapp02, the same thing - no need to change tomcat-some-conf.xml to deploy it after webapp01. Obviously I consider only small webapps, like Django admin ones. =]
My target is to setup a Python/Django webserver and dynamically create Django admin webapp's, automatically hot deploying them to the webserver. So, I'd initially setup the web server stuff once and have a ready http://myserver.com. When user A generated a webappA01, it would be transparently available in http://myserver.com/userA/webappA01.
Is it possible?
Modern approach is to use uwsgi with Apache or NGINX (I recommend this one).
I don't know a tool which will auto-deploy your Django app. There are many web services like Heroku which deploy your app automatically (you supply just your VCS repository).
You can deploy your Django app semi-automatically by writing some scripts that will sync your code base, apply migrations for the db and reload web server. Check fabric or Buildbot.
First, Python/Django does not provide a "drop-in" deploy function by themselves, nor I know any way of doing something similar to war packages.
There are services that provide easy deploy methods like Heroku, but I recommend reading Django's official documentation about deploying for starters.
My target is to setup a Python/Django webserver and dynamically create
Django admin webapp's, automatically hot deploying them to the
webserver. So, I'd initially setup the web server stuff once and have
a ready http://myserver.com. When user A generated a webappA01, it
would be transparently available in
http://myserver.com/userA/webappA01.
Sounds like what you want to do can be accomplished with custom AdminSite instances.
Basically, you can write a view that instantiates an AdminSite instance named "webapp" (you can pull those parameters from the url of course, and check if the webapp data exists on the database). You'll need to connect any models you want to that AdminSite instance either from that view or by overriding its init method. The autodiscover function of the Django admin may not work for custom admin sites.
I am thinking to design my own web app to serve static files. I just don't want to use Amazon services..
So, can anyone tell me how to start the project? I am thinking to develop in Python - Django on Openshift (Redhat's).
This is how ideas are going through in my mind:
A dashboard helps me to add/ delete/ manage static files
To setup API kind of thing (end point: JSON objects) so that I can use this project to serve my web apps!
As openshift uses Apache!, I am thinking to dynamically edit htaccess and serve the files.. but not sure whether it would be possible or not
Or, I can use django's urls.py to serve the files but I don't think djano is actually made for.
Any ideas and suggestion?
How about this:
Use nginx to serve static files
Keep the files in some kind of predefined directory structure, build a django app as the dashbord with the filesystem as the backend. That is, moving, adding or deleting files from the dashboard changed them the filesystem and nginx doesn't have to be aware of this dashboard.
Do not use dynamic routing. Just layout and maintain the proper directory structure using the databoard.
Optionally, keep the directory structure and file metadata in some database server for faster searches and manipulation.
This should result in a very low overhead static file server.
I am in a team developing a web-based university portal, which will be based on Django. We are still in the exploratory stages, and I am trying to find the best way to lay the project/development environment out.
My initial idea is to develop the system as a Django "app", which contains sub-applications to separate out the different parts of the system. The reason I intended to make these "sub" applications is that they would not have any use outside the parent application whatsoever, so there would be little point in distributing them separately. We envisage that the portal will be installed in multiple locations (at different universities, for example) so the main app can be dropped into a number of Django projects to install it. We therefore have a different repository for each location's project, which is really just a settings.py file defining the installed portal applications, and a urls.py routing the urls to it.
I have started to write some initial code, though, and I've come up against a problem. Some of the code that handles user authentication and profiles seems to be without a home. It doesn't conceptually belong in the portal application as it doesn't relate to the portal's functionality. It also, however, can't go in the project repository - as I would then be duplicating the code over each location's repository. If I then discovered a bug in this code, for example, I would have to manually replicate the fix over all of the location's project files.
My idea for a fix is to make all the project repos a fork of a "master" location project, so that I can pull any changes from that master. I think this is messy though, and it means that I have one more repository to look after.
I'm looking for a better way to achieve this project. Can anyone recommend a solution or a similar example I can take a look at? The problem seems to be that I am developing a Django project rather than just a Django application.
The best way that I have found to go about this is to create applications and then a project to glue them together. Most of my projects have similar apps which are included in each. Emails, notes, action reminders, user auth, etc. My preferred layout is like so:
project/
settings.py
urls.py
views.py
...
apps/
emails/
urls.py
views.py
...
notes/
urls.py
views.py
...
...
apps:
Each of the "apps" stands on its own, and other than a settings.py, does not rely on the project itself (though it can rely on other apps). One of the apps, is the user authentication and management. It has all of the URLs for accomplishing its tasks in apps/auth/urls.py. All of its templates are in apps/auth/templates/auth/. All of its functionality is self-contained, so that when I need to tweak something, I know where to go.
project:
The project/ contains all of the glue required to put these individual apps together into the final project. In my case, I made use heavy of settings.INSTALLED_APPS in project/ to discern which views from the apps were available to me. This way, if I take apps.notes out of my INSTALLED_APPS, everything still works wonderfully, just with no notes.
Maintenance:
This layout/methodology/plan also has long-term positive ramifications. You can re-use any of the apps later on, with almost no work. You can test the system from the bottom up, ensuring that each of the apps works as intended before being integrated into the whole, helping you find/fix bugs quicker. You can implement a new feature without rolling it out to existing instances of the application (if it isn't in INSTALLED_APPS, they can't see it).
I'm sure there are better documented ways of laying out a project, and more widely used ways, but this is the one which has worked best for me so far.
You should take a look at :
Django generic relations
Django reusable apps best practices if you want to re-use
GIT or any other CVS (git is great for maintaining + deployment)
Fabric if you need automated deployments/updates
I usually use this project structure :
/djangoproject
/apps
/main # the main code
/static # each sub app can serve statics
/app1
/static # each sub app can serve statics
/app2...
/scripts # manage.py, wsgi, apache.conf, fabfile.py...
/core # your libraries ...
settings.py
local_settings.py
Each app in /apps have an urls.py thats autoincluded in the main urls.py. And each app can be a git submodule (or svn external)
Also, using git, you can work on different parallels branches (master/dev/customerA/customerB...) and merge updates.
Creating real reusable is not so easy with django.
You can extract the common functionality into a separate module and make your apps depend on it:
my_portal
auth_module
profiles_module
application1 (depends on auth_module)
application2 (depends on auth_module and profiles_module)
I think the fact that a 'classical' Django project appear to 'contain' the apps it's using prevent you from seeing the picture - in fact, it's not necessary. For a project where you're going to have some sort of pluggable modules I'd suggest organizing the apps as eggs and using zc.buildout+djangorecipe to manage everything.
This way you'll be able to keep your modules in a flat one-level structure. Eggs have the ability to specify dependencies, so if you install application1 (see above), auth_module will be installed automatically.
Also it'll be easy to have different configurations deployed to different servers. Suppose, you have server1 which has application1 installed and server2 which has both application1 and application2 installed - you can just have two configs:
server1.cfg:
[buildout]
extends = base_deployment.cfg
eggs += application1
server2.cfg:
[buildout]
extends = base_seployment.cfg
eggs += application1
application2
djangorecipe also allows you to specify different settings files for each buildout config so you'll be able to add the necessary bits to the main project's urls and installed apps settings.
Not to mention, you can also have a separate config for development configuration (with debug=True and Django Debug Toolbar installed, for example).