In the years past, I've always used Angular 1.x for my front end which was as simple as including a single JS file at the time. Now with the rise of TypeScript in Angular, React, and others, there's now a need for a dedicated NPM build serves which compiles the source into vanilla JavaScript before serving the front-end as an independent project. Please correct me if my understanding of this is in anyway flawed.
At the moment I use Django for all of my backend applications, particularly a REST framework that will enable the frontend to function as a SPA. I've taken a liking to Vue.js as my frontend weapon of choice. My question is (and please forgive me if it seems a bit too broad) how do I setup my project and configure it properly so that I'm not running two servers for both the frontend and backend?
Again, back in the days of Angular 1.x and vanilla JavaScript all I had to do was include a minified angular.js in my static files folder in the backend and the same goes for the standalone version of Vue. Now I'm just so confused what is what and how to properly setting up a full stack project. If you guys, could weigh in, I'd very much appreciate it. Thank you in advance!
npm run dev # running the frontend for Vue.js
manage.py runserver # and a Django DRF backend
If you want to do a full-featured VueJS project with webpack template, here is what you can do: Run server and client apps on separate ports, and proxy all server requests (like APIs) using proxyTable in webpack config.
Here are the detailed steps:
Step 1: Create your usual Python server (or any other server that serves APIs, static files, etc.) in a separate folder / terminal window. Let's say it runs on port 8080. So, your development server is available at http://localhost:8080 which also hopefully serves some api requests.
Step 2: Create your VueJS project in a different folder (preferably using webpack template). When you run npm run dev, your client app will be available at http://localhost:4200 (default webpack setup). Do not start your client app yet, till you finish Step 3 below.
Step 3: Now open the config file: VueJS_Webpack_Project_Folder/config/index.js and setup proxyTable as follows:
...
...
module.exports = {
build: {...},
dev: {
...,
port: 4200,
...,
proxyTable: {
'/api': {
target: 'http://localhost:8080',
changeOrigin: true
},
'/static': {
target: 'http://localhost:8080',
changeOrigin: true
}
},
...
}
}
...
As you can see above, all requests going to /api and /static are redirected to server. This is just an example, you can proxy more requests that are relevant for your setup.
You can also change the port if your server is running on 4200 or if you have multiple VueJS apps in your dev setup.
Step 4: Now you can finally start your Python server (your development server) and webpack server (VueJS client app) and do your regular development.
EDIT: Final steps to deploy app
After you are done with development, when you finally run npm run build, it will create a dist folder within your VueJS project setup, containing the minified build files like vendor.hash.js, app.hash.js, etc.
You will need to copy these build files to the right folders within your Django server setup. Either you may do this step manually, or simply write a python script that removes old build files and copies new build files into the right folders.
EDIT 2: Explaining the reasons for the above setup
The reason we have to do all the complicated steps above is because of the following:
Today we may use Django. Tomorrow we may change the server side technology to something else, or may even go serverless. To ensure that our client app is not affected during this migration process, it is in our best interest to keep it independent.
Server and client have different roles: Server handles the databases, APIs, user sessions, authentication, etc. Client App focuses only on having the right user experience. Therefore it helps to separate these environments.
VueJS with webpack template is a very powerful way to do VueJS development. You get to change code and view results immediately in browser without even having to refresh. You get detailed error logs or warnings that allow you to fix bugs immediately without having to do a full build. The development cycle gets shortened significantly when you use VueJS + webpack. The only way to get it working properly is by having it as a stand-alone project.
And some non-technical reasons:
Keeping separate client helps in splitting work in future. In a small project, the single developer may do both client and server development. Later when the project becomes a big success, a separate team will handle the server, and a different team will handle the client app. Having it coupled will lead to a lot of synchronization issues.
And finally, when you have a big revenue-generating project eventually, you don't get developers with Django + VueJS skillset. Developers (unlike tech founders) focus on one particular technology at a time. When you have two different projects that fully conform to the regular development processes, your team can ramp up fast and get things done quickly.
[Disclaimer: This is just my understanding after a little research. Hope it helps.]
It seems today that there is now a build step when creating a frontend with various frameworks. This step only needs to happen when you make changes to your front end, e.g. you update your TypeScript or templates, then build/bundle them into some js package. I believe you can just do this on your development machine. You can then serve the output js statically just as you did before.
I believe the frontend servers exist to streamline the process. So, when you make changes to your frontend, instead of running the build at home and manually adding the output to your static files, the server will take your input files and refresh the output js automatically. But this isn't required.
You should still be able to use vue.js by simply linking to it:
Direct Include
Simply download and include with a script tag. Vue will be registered as a global variable.
https://v2.vuejs.org/v2/guide/installation.html
I'd suggest studying that page for other ways of using vue.js along with the documentation for npm, WebPack, and Browserify and then posting a more specific question if you're still lost.
Related
This is a bit embarassing, but I'm a Django noob and I couldn't find a simple solution to this:
I have written a Django app in a local VM that I now want to deploy to a "production" server. App works like a charm locally.
Now my IT colleague has set up the server with Django and that also works fine. I can open it via the Web and I get the usual "Congratulations on your first Django-powered page". I can also log into the admin interface. The project has been created.
This is a very low-key mini project and I'm not too familiar with git, so we've decided to just push files via FTP. (And I want to stick with that if at all possible.) So I uploaded the app folder into the project folder and also adjusted the project's settings.py and urls.py.
However, nothing seems to be happening on the server's end. The welcome page is the same, the app does not show up in the admin interface and the URLs won't be resolved as hoped.
Any suggestions what I should have done / done differently?
You need to restart apache or whatever is running your django project. Your changes to py files are cached when you first load your server config (settings).
Any suggestions what I should have done / done differently?
You should be using git/jenkins/deployment techniques, I know you said you've decided not to use it but you're going to be missing out on important things like being able to keep track of changes and unit testing
Before Ember CLI, I use to create an index.html page within Django project, plus the App.js file and all seemed to be working great.
Now that Ember is using CLI, it seems that there is no easy way to integrate Ember CLI project within Django application.
So I read that people are recommending using Ember CLI to develop the front-end, and Django to develop the REST API. However deployment is not easy, because you need to copy the Ember dist folder under Django static folder, plus change all the static asset url under Ember app to point to Django static path.
So it seems that, there is no easy way to integrate the two into one single development process.
Do you guys, have any suggestions on how to integrate the development, and deployment process?
Thx.
For projects like this, you should use separate repositories for your server app and client app(s).
Consider a project that has 4 code repositories, 1 server and 3 clients:
myproject (A Django app written in Python that provides an API for clients)
myproject-web (The Ember.js web client written in JavaScript)
myproject-ios (An iOS client app written in Swift)
myproject-android (An Android client app written in Java)
The core app will be deployed to a server that is capable of hosting Python apps (e.g. uWSGI).
Because the Ember.js project is ultimately a static resource, you can serve it from pretty much anywhere (e.g. NGINX), and point it at a separate API server that hosts the Django project (e.g. https://app.myproject.com/api/). See documentation on configuring ember-django-adapter to use a custom API host: http://dustinfarris.com/ember-django-adapter/configuring/
iOS of course would be deployed to the Apple App Store, and the Android project would be deployed to Google Play.
Each repository is a separate codebase with different requirements and deployment strategies—which is why it is best to keep them separate, so you can think about them and work with them in isolation. Just because Django can handle static assets doesn't mean you should rely on it—trying to host an Ember.js project (or any other JS framework project) within a Django project is just overcomplicating things. Hope that helps.
I am currently implementing a Ember-CLI app served by Django.
Here are the steps that I followed:
On Django:
Create a sub-project in your django project (ie: ember)
Install django-redis-views that will serve your index.html from redis.
Create a S3 bucket + CDN on AWS (or other storage product) in order to store your assets
On Ember:
install ember-deploy-redis & ember-deploy-s3
Add credentials to config.deployment and correct fingerprint in your ember-cli-build.js
Deploy ember
Useful link:
Easy deployment using redis + CDN: http://ember-cli.github.io/ember-cli-deploy/
Pip package that help your retrieving your index.html stored on redis: https://github.com/kevinlondon/django-redis-views
In the old world I had a pretty ideal development setup going to work together with a webdesigner. Keep in mind we mostly do small/fast projects, so this is how it worked:
I have a staging site on a server (Webfaction or other)
Designer accesses that site and edits templates and assets to his satisfaction
I SSH in regularly to checkin everything into source control, update files from upstream, resolve conflicts
It works brilliantly because the designer does not need to learn git, python, package tools, syncdb, migrations etc. And there's only the one so we don't have any conflicts on staging either.
Now the problem is in the new world under Heroku, this is not possible. Or is it? In any way, I would like your advice on a development setup that caters to those who are not technical.
How about a static 'showcase' site where all possible UI elements, templates, etc are shown using dummy content. The designer can connect, edit stuff and you merge in the changes in the end. Another option would be a test server with the full application running (kind of like you did it before) but with the option to connect via FTP or whatever the designer prefers.
Why not store all of the assets on S3?
It sounds to me that they don't really need to be part of the application at all, but external resources that the application references.
I am trying to build a web-app that has both a Python part and a Node.js part. The Python part is a RESTful API server, and the Node.js will use sockets.io and act as a push server. Both will need to access the same DB instance (Heroku Postgres in my case). The Python part will need to talk to the Node.js part in order to send push messages to be delivered to clients.
I have the Python and DB parts built and deployed, running under a "web" dyno. I am not sure how to build the Node part -- and especially how the Python part can talk to the Node.js part.
I am assuming that the Node.js will need to be a new Heroku app, so that it too can run on a 'web' dyno, so that it benefits from the HTTP routing stack, and clients can connect to it. In such a case, will my Python dynos will be accessing it using just like regular clients?
What are the alternatives? How is this usually done?
After having played around a little, and also doing some reading, it seems like Heroku apps that need this have 2 main options:
1) Use some kind of back-end, that both apps can talk to. Examples would be a DB, Redis, 0mq, etc.
2) Use what I suggested above. I actually went ahead and implemented it, and it works.
Just thought I'd share what I've found.
What I want to know are actually 2 things.
Part 1:
I have a developed source code for an application in python that uses Django framework.
What I want is to be able to run the code on a developer machine and see the result. What do I need for it?
(my guesses):
Python development enironment (Eclipse/PyDev/Aptana Studio 3 seem to be the better ones for windows not sure linux yet),
I also have a postgre database already setup (I know there's a file where I have to specify connection information)
- something installed from django or would this be already included in the code that I have?
Part II:
I also want to make a dev server accessible through internet.
- this is the major part of the question and the most important. How do I publish the app?
- I have a linux machine that I would do this on, but unsure of all the things I need. Apache server?
To answer your questions:
What you need: A list of requirements and instructions to get started with Django is available here: http://djangobook.com/en/2.0/chapter02/.
Database: that chapter also includes a section on configuring access to your database, with a specific section on postgreSQL.
Dev server: To start a basic development server, see this tutorial section
Deploying django (production): For instructions on how to deploy Django for production, see chapter on deploying Django.
Publishing on internet: as for making your dev server accessible through the internet, ask on https://serverfault.com/. Make sure you provide more information about your network setup, what you've tried, what isn't working, etc. (Briefly, you need to make sure that the host you are running your server on is on a publicly accessible IP, or has port 80 forwarded to it from such a host. If in doubt, speak to your sys/network admin if you have one. Or use a django hosting service such as those listed on http://djangohosting.com)
IDE : Regarding IDE, it's down to personal preference. What you mentioned are fine and can run on Linux too.
As a first step, I suggest you follow the tutorial which guides you through the process of starting a development server and developing a basic app.
Even if your goal is to deploy an existing app, the tutorial will give you an idea of how the different components work together (apps, models, urls, templates, etc) which will help with debugging when something goes wrong with your deployment.
Good luck.
You need Python, Django, a WSGI container (e.g. mod_wsgi, uWSGI, Paste Deploy), and a database server. You make the Django project available as a WSGI app, bound to the appropriate interface on the machine.