We Keep Coding

how to deploy a vuejs/flask project on apache

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

What's the point of Django's collectstatic?

In Django, the convention is to put all of your static files (i.e css, js) specific to your app into a folder called static. So the structure would look like this:
mysite/
manage.py
mysite/ --> (settings.py, etc)
myapp/ --> (models.py, views.py, etc)
static/
In mysite/settings.py I have:
STATIC_ROOT = 'staticfiles'
So when I run the command:
python manage.py collectstatic
It creates a folder called staticfiles at the root level (so same directory as myapp/)
What's the point of this? Isn't it just creating a copy of all my static files?

Collect static files from multiple apps into a single path
Well, a single Django project may use several apps, so while there you only have one myapp, it may actually be myapp1, myapp2, etc
By copying them from inside the individual apps into a single folder, you can point your frontend web server (e.g. nginx) to that single folder STATIC_ROOT and serve static files from a single location, rather than configure your web server to serve static files from multiple paths.
Persistent URLs with ManifestStaticFilesStorage
A note about the MD5 hash being appended to the filename for versioning: It's not part of the default behavior of collectstatic, as settings.STATICFILES_STORAGE defaults to StaticFilesStorage (which doesn't do that)
The MD5 hash will kick in e.g. if you set it to use ManifestStaticFilesStorage, which adds that behavior.
The purpose of this storage is to keep serving the old files in case
some pages still refer to those files, e.g. because they are cached by
you or a 3rd party proxy server. Additionally, it’s very helpful if
you want to apply far future Expires headers to the deployed files to
speed up the load time for subsequent page visits.

Django static files can be in many places. A file that is served as /static/img/icon.png could come from many places. By default:
FileSystemFinder will look for img/icon.png in each of STATICFILES_DIRS,
AppDirectoriesFinder will look for img/icon.png in the static subfolder in each of your INSTALLED_APPS. This allows libraries like Django Admin to add their own static files to your app.
Now: this only works if you run manage.py runserver with DEBUG=1. When you go live, the Django process will no longer serve the static assets. It would be inefficient to use Django for serving these, there are more specialised tools specifically for that.
Instead, you should do something like this:
find all of static files from every app
build a single directory that contains all of them
upload them somewhere (a static directory somewhere on your webserver or a third-party file storage)
configure your webserver (such as nginx) to serve /static/* directly from that directory and redirect any other requests to Django.
collectstatic is a ready-made script that prepares this directory for you, so that you can connect it directly to your deployment script.

In the production installation, you want to have persistent URLs. The URL doesn't change unless the file content changes.
This is to prevent having clients to have wrong version of CSS or JS file on their computer when opening a web page from Django. Django staticfiles detects file changes and updates URLs accordingly, so that if CSS or JS file changes the web browser downloads the new version.
This is usually achieved by adding MD5 hash to the filename during collectstatic run.
Edit: Also see related answer to multiple apps.

It's useful when there are multiple django apps within the site.
collectstatic will then collect static files from all the apps in one place - so that it could be served up in a production environment.

pyroot folder of a python module

I am following a step-by-step tutorial blog on the flask micro framework for python.
I bumped into an issue, when they require me to 'setup' a configuration file in the root of the application folder, so it can easily be accessible if needed.
They called it config.py.
My question is, if the local path to my application is /home/test/application1/, should I create the file inside the ./application1/ directory? What gets me confused in this somewhat obvious question is that I did a quick search for other config.py files in the local directory inside /home/test/application1/, where I found 4 other files. There were in the following directories:
/home/test/application1/flask/lib/python2.7/site-packages/flask/testsuite/config.py
/home/test/application1/flask/lib/python2.7/site-packages/flask/config.py
/home/test/application1/flask/local/lib/python2.7/site-packages/flask/testsuite/config.py
/home/test/application1/flask/local/lib/python2.7/site-packages/flask/config.py
So should I create a new config.py file in the directory that I first mentioned or should I add some lines in one of the previously created config.py files.
Here is the source of the step-by-step tutorial:
It is at the beginning, right after Configuration.

Unlike other frameworks, Flask does not have a lot of rules, in general you can implement things in the way they make sense to you.
But note that the other config.py files that you found are all in the virtual environment, and are all scripts that come with Flask. They have nothing to do with the application configuration.
I wrote the tutorial you are following. In the tutorial I'm putting config.py outside of the application package. This is what I like, I consider the configuration separate from the application. My thinking is that you should be able to run the same application with different configuration files, so that for example, you can have a production configuration, a testing configuration and a development configuration, all different.
I hope this helps.

Recommended place for a Django project to live on Linux

I'm uploading my first Django project to a Linux server, where I should put my project in the filesystem?
With a PHP, or ASP project, everything goes into /var/www, would it be ok to do the same and add my Django project to the /var/www folder?

In the Django tutorial it states:
Where should this code live?
If your background is in PHP, you're probably used to putting code under the Web server's document root (in a place such as /var/www). With Django, you don't do that. It's not a good idea to put any of this Python code within your Web server's document root, because it risks the possibility that people may be able to view your code over the Web. That's not good for security.
Put your code in some directory outside of the document root, such as /home/mycode.

File Hierarchy System
#Andy Hayden really states where not to place ones code. The File Hierarchy System (FHS) implicates the following structure; PATH maps to PACKAGE or PROVIDER (It is recommended that parties providing multiple packages should use PROVIDER/PACKAGE) :
/etc/opt/PATH # FHS location for /opt configuration files
/opt/PATH # FHS location for PROVIDER or PACKAGE name
/var/opt/PATH # FHS location for /opt variable storage
The FHS expects /opt/PATH to contain all the material necessary for the successful execution of ones package so it seems prudent to setup the following symbolic links
/etc/opt/PATH to /opt/PATH/etc
/var/opt/PATH to /opt/PATH/var
This provides a good basis but Django projects have extraneous requirements that the above structure does not fully meet.
Static Files
Static files are deployed when one runs python manage.py collectstatic to the STATIC_ROOT which should point to the web server root for static delivery, usually /var/www/PATH.
One could link /var/www/PATH symbolically to /opt/PATH/static
but this is typically a bad idea; Consider the case that you have a misconfigured server and a user goes to www.domain.tld/../ and copies your work.
Settings
If you created your project with django-admin create-project WEBSITE the you will typically have a setup.py file under the WEBSITE folder.
PROJECT/
WEBSITE/
setup.py
...
If you converted this settings module into a package, or you used some wrapper around django-admin e.g. django-cms-create etc.
PROJECT/
WEBSITE/
settings/
__init__.py # from .settings import *
settings.py
...
You might symlink /etc/opt/PATH to /opt/PATH/WEBSITE/settings instead of /opt/PATH/etc as described above. I can't think of a practical reason for doing so though... YMMV.
Media
Media, typically provided by ones websites users, are placed into MEDIA_ROOT. It seems prudent to map /var/opt/PATH to /opt/PATH/media in this case.
Virtual Environments
/opt/PATH/env seems the most logical location. /var/env/PATH also seems sensible but is probably better suited as a symbolic link to /opt/PATH/env.
Since a virtual environment is neither an application nor a library the locations /opt/bin and /opt/libs would not do for this. /env/ or /pyvenv/ does not conform to the FHS.
Whiskey
If you're using mod_wsgi with Apache the an invocation similar to python manage.py runmodwsgi --server-root /etc/opt/PATH --setup-only is probably preferable since it places the Apache control commands into the FHS compliant locations, granted they are more cumbersome to invoke in this case.
Home
To my understanding /home was traditionally used by PHP developers when they were hosting multiple sites upon the same server. If you're using Django you're probably serving your site from a dedicated machine and this structure looses a bit of favour in this case... YMMV.

A web application to serve static files

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.