The Django docs never mentioned that a person who doesn't know what HTML/JS/CSS is about can use it. Separation of concerns is done also in the backend, where the actual action(the views) are separated from the database layer or the URL-routing logic - That allows for loose-coupling. It never means you can write views without ever understanding your models. Similarly(well, not that similarly), you do need to have an understanding of HTML/CSS to get basic web pages up. You may or may not want to learn some JS, but I think with HTML5, it is more or less essential to know some JavaScript.
No sane web-developer is going to advise to to use a WYSIWYG editor like DreamWeaver. Write HTML by hand. You may, however, use things like HTML5 Bolierplate to get your project started fast.
Google AppEngine is a PaaS that you can use to deploy your application. It will provide among other things, the Python runtime, a high-replication datastore etc. - but it will not take care of generating your front-end.
If you're going to hire someone to take care of the front-end, that person would anyway have to know how to use Django tags, as really(if you follow the MVC - or MTV pattern closely), they define the blurred line between "static" and "dynamic" web-pages. Even if you choose to hire a frontend-developer, I suggest you grasp the basics of HTML and CSS(at least so much that you know how it works and how are you going to serve the CSS static files). It will only help you in the long run.
Not all people have good design skills, and design is undoubtedly best left to skilled people, but when it comes to actually serving pages with that design, it is all HTML and CSS. So you may hire a person who doubles up(most do) as a front-end designer and a front-end developer. But I suggest you to not remain completely unaware of front-end technologies.
Short answer:
I don't have enough information about your environment and goals to give a simple and helpful short answer. See my long answer below.
Long answer:
This is a really hard question to answer. There are a lot of specific things to your team and your project that lead to deciding on a best architecture for your system. To answer it well, there needs to be more detail around the goals and requirements for this web app. For example:
- Is the API going to be public or only used by the web app? I.e., should it be thought of as an internal service that is behind a firewall and only accessible to the web app, or something else?
- How much traffic is expected for this app? (1k users/month? 10k? 100k? 1m?)
- How fast do pages need to load? (i.e., how responsive does the application need to fel vs. actually be?)
- How much time do you have to build the app?
- Do you really need OAuth?
- How many people do you have on your team?
- Where on the spectrum of "learning experience" to "to support a business" does this project lie?
- Where on the spectrum of "practical, get it done" to "it must be perfectly technically correct" does this project lie?
- Is this app going to be indexed by search engines or is it going to be mostly private (behind an authentication mechanism)?
My opinion on the "practical" vs. "perfect" question is, make it more practical. If it doesn't ship, the project doesn't matter outside what you learn.
The answers for questions 1, 2 and 3 lead to how big and complex the system needs to be. (If a lot of traffic is expected and page load time is not that important, more layers and more systems could be introduced. If there are areas of data that can be cached, then that can offset other places where it is slower to get data.)
On authentication and account creation. This is a surprisingly complex topic that takes time to really understand. Whether using OAuth (assuming OAuth 2.0) against your own API, regular password authentication, or OAuth authentication against a third-party (facebook, google, etc.), you'll still need a way to create user accounts within your system.
On OAuth: the most common use for OAuth is for allowing a third-party system/service to access data in your system that is owned by one of your users. It does have the flexibility, however, to allow password-based login. This means that, once a user has created an account on your system, you can use the "Resource Owner Password Credentials" grant type in OAuth 2.0 to authenticate that user. Check out the full rfc if you have not yet done so.
Here are a couple common ways to architect web applications (this is not comprehensive and there are tons of variations):
- Use a front end framework, in javascript (think ember, angular or similar), to manage all the views and request the appropriate data from the API on a server. This API could then be either a public API or an API only used by that app.
- Create a multi-tier server architecture where there is an external-facing web app layer with internal services (APIs) for each of the services you need. The web app layer has the views and gets all model data from the internal services. All internal services are behind a firewall. For example, see how TripAdvisor does it.
- Provide a public API and create a standard, server-based web app where it serves individual html pages generated from views on the server. (i.e., the web app would not use the public API but would access all internal databases and services directly.)
- Provide a public API for 3rd-party use and create a semi-private API that only the web app uses. This is a specific variation on #1.
I would follow #1, #3 or #4:
- if I were building a system that I know will have < 100k users
- if I had to support > 100k users and the number of features in the system is small (i.e., not a hugely complex product)
I would follow a combination of (#2 and (#1, #3 or #4)) (parenthesis for clarity of operational order):
- if I had a lot of backend processing going on with a lot of other systems
- if I had to support > 100k users and there is a very large feature set / a lot of different types of data to handle
If I had a product that was publicly available and would be indexed by search engines, I would not do #1 nor #4.
My team matters a lot to me. Their preferences, experience and desire to learn would affect what I choose architecturally between #1/#4 and #3.
Best Answer
If each client you intend to service requires different output from your back end. Then write your back-end in a way where is can serve each type.
Do some abstraction. Ask yourself, what things will all clients need the same way, and what things will each client need in a specific different way.
Put all the stuff that is the same for all clients together, and then write an interface for each client that handles the differences for that client. These interfaces will get all content from the same module, but adapt serving that content to the specific clients needs.