We Keep Coding

Design Decision Django Rest Framework - Django as Frontend

I am currently developing my first more complex Web Application and want to ask for directions from more experienced Developers.
First I want to explain the most important requirements.
I want to develop a Web App (no mobile apps or desktop apps) and want to use as much django as possible. Because I am comfortable with the ecosystem right now and don't have that much time to learn something new that is too complex. I am inexperienced in the Javascript World, but I am able to do a little bit of jQuery.
The idea is to have one database and many different Frontends that are branded differently and have different users and administrators. So my current approach is to develop a Backend with Django and use Django Rest Framework to give the specific data to the Frontends via REST. Because I have not that much time to learn a Frontend-Framework I wanted to use another Django instance to use as a Frontend, as I really like the Django Template language. This would mean one Django instance one Frontend, where there would be mainly TemplateViews. The Frontends will be served on different subdomains, while the backend exposes the API Endpoints on the top level domain.
It is not necessary to have a Single Page App. A Normal Website with mainly the normal request/response-cycle is fine.
Do you think this is a possible approach to do things? I am currently thinking about how to use the data in the frontend sites in the best way. As I am familiar with the Django template language I thought about writing a middleware that asks about the user details in every request cycle from the backend. The thought is to use a request.user as normally as possible while getting the data from the backend.
Or is ist better to ask these details via jQuery and Ajax Calls and don't use the django template language very much?
Maybe there is also a way to make different Frontends for the same database without using REST?
Or what would you think about using a database with each frontend, which changes everytime I make a change in the main database in the backend? Although I don't really like this approach due to the possibility of differences in data if I make a mistake.
Hopefully this is not to confusing for you. If there are questions I will answer them happily. Maybe I am also totally on the wrong track. Please don't hesitate to point that out, too.
I thank you very much in advance for your guiding and wish you a nice day.

as per my experience and knowledge, you are almost going towards correct direction.
my recommendation is for making backend rest api Django and django rest framework is the best option however for consuming those api you can look for the angular or react both works very well in terms of consuming API.

Thank you for your input om tripathi.
I think it really does make sense to use the modern js frameworks for consuming a REST API.
I looked a little further into my problem and found multitenancy to fit my requirements perfectly. There are also great plugins and good reads for that use case. Just for others some informations I stumbled upon:
https://djangopackages.org/grids/g/multi-tenancy/
https://www.vinta.com.br/blog/2017/multitenancy-juggling-customer-data-django/
Especially the second link gave me information about different design approaches. For myself I chose to go the way with one database for every Client and then using the site framework from django to seperate data. For the Subdomain resolving I use django-hosts.
Thank you again and have a nice day.

Django REST or simple Django for REST API

I would like to know if it is possible to build a REST Api using only Django (without Django REST).
I have following code in my views.py my Django (no REST Django)
from django.http import HttpResponse, JsonResponse
def get_something(request, object = None):
dummyDict = {'Debug':object}
return JsonResponse(dummyDict)
ulrs.py
url(r'^(?P<object>\w{1,50})$', views.get-something, name = "get-something"),
Can this work as REST API?
I tried testing using curl and I get following answer from my django server:
HTTP/1.0 200 OK
Date:
Server:
X-Frame-Options:
Content-Type: application/json
{"Debug": daodoaw}

You may do that though you'll have to add a lot of things to make an API RESTfull.
Your example is already missing proper response code for PUT / POST / PATCH / DELETE and doesn't respond correctly to OPTIONS

Ofcourse you can do these things with Django, but the advantage of django rest is that it is specifically created to handle api creation and management, Thus using django rest will be much more effective. When you look at the documentation of django rest, you could see that viewsets like ModelViewSet, GenericViewSet which are capable of handling any type of requests(POST, PUT, PATCH, etc...) in a two or three line code. Meanwhile while you using django you have to specify each and every case. Its just a case where DRF is more preferred).
What I try to say is, DRF is more handy in the case of API Creation and has a very good documentation in their official website
If you have to know about any specific part, please comment below
Thanks

Using Django is not a crime! We are given the liberty to use either DRFor Django.
Here are some of the situations when you can think of using DRF:
Let's imagine, you have developed a web application with django. What would happen if your client or you want a mobile version (android/iOS version) of your application? As multi-platform development is becoming the norm, using DRF can become crucial to reuse the same backend for both a mobile app and a web app.
Another comprehensive reason to use DRF is its super easy serialization facility.
If you want to segregate your front-end from Django provided templates, you are free to use modern javascript frameworks such as Vue, React or Angular for better design and to be dynamic as much as possible with your REST APIs.
When you use DRF, you are given ready-made view classes (ApiView, GenericAPIView, Viewsets) that are only a few lines of coding and able to handle all sorts of requests such as (POST, PUT, PATCH, etc...).
NOTE: Definitely, you can use Django depending on the project you are handling. In the case of building a web application that doesn't need to be accessed from other platforms, I would not use DRF. It entirely depends on the requirements.

Django : Project consuming data from REST API, How to use external apps in this system?

I have a Django web front-end that consumes data from a REST API backend.
Even the users are made and created on the backend.
My Problem :
How to use 3rd party apps within this system, that heavily depend on django models/ORM ?
Is there something that can provide some bridge between the REST API resources and the ORM?
How can this problem be dealt with ?
Update
DRY principal seems to be failing in this situation.

Probably things have changed since this question has been originally posted. Now there are a couple of interesting related questions on StackOverflow about this topic.
To code yourself a solution as explained in this answer, you can create an external service layer (aka services.py) and write there the logic to access the external resources. Your views will consume this layer, and make the proper actions. There are other questions that provide help on how to pass information from the original request received by the django-view to the external service like this or this
There is also a django app that takes this situation into account as explained in this answer. django-roa uses the Resource Oriented Architecture paradigm to solve this.

I'm facing a similar obstacle with a new ecommerce project.
The project is a front end to a full-fledged store management software (CMS+ERP+CRM). It needs to use the master product database, but have its own entries for product reviews, ratings and so on.
The initial thought was to make a cached copy of the master database. The website will benefit from fast loading times for the cached items, but the implementation is not trivial.
After some considerations, the selected approach was updating the website's DB from the management program. This way the website's copy will always be correct, and most of the implementation doesn't need to worry about REST services (it'll still be used for user registration, shipment tracking etc.)
In your case, where you can't have the service update your own database remotely, you need to come up with a mechanism that allows you to refer to REST recourses like regular models, and that caches them in the background.
Important note: research for a way to make sure the cache is always correct (non-dirty)...

I'm not sure I completely understand your question or requirements. The way I am reading it, you have a primary back-end which is basically a black-box, and you want to use some 3rd-party apps in your project which use the Django ORM.
I am unclear as to why there would be a need for being able to have a two-way synchronization between the two data-stores. The users of your project would be returned data from your primary back-end, and from the project's ORM.
Since you are concerned about saving the "ORM" data in your primary back-end, maybe you would consider creating a Transaction Middleware that would fire any time ORM data gets updated, which could serialize the structure being saved and transmit it to your REST API. This REST API, I assume, is able to accept arbitrary data structures?
You'll probably at least want to use some form of middleware, and maybe a utility module/class to help form the "bridge".

Django REST browser interface

I'm writing a set of REST services for a Django project. I've been using django-rest-framework for a while. Because of its limited functionality I had to switch to django-piston which I quite enjoy.
However, django-rest-framework had one really nice feature - it was able to display an admin-like interface for testing the created services from the browser. It's just terrific for debugging purposes. It's very simple: one form is displayed for each HTTP method like "GET", "POST", etc. Along with that a drop-down list of available content types and a text field for putting in the data to be sent.
As I view it, this isn't really a feature in any way directly connected with a particular REST framework. It isn't even necessarily about Django. It could all be achieved just using HTML + JS, or an external website.
My question is: What do you use for manual testing / debugging web services? Could you point me to some HTML snippet or a Django app that would do the described thing?

This may seem obvious, but:
Why not just use Django's testing client (django.test.client.Client)? then instead of manually 'debugging' in your browser, you can write unit tests with expectations and get leverage out of those further down the track.
e.g.
from django.test.client import Client
client = Client()
resp = client.put('/employee/2/', data={'email': 'here#there.com'}, follow=True)
#... etc

As the author of django-rest-framework it'd be great to pick your brains about which bits of functionality could do with fleshing out. :) (obv i've got some thoughts of my own and areas I'm planning to work on, but be really good to get some user perspective)
Your absolutely right about the API browser not being limited to any particular framework. To me that's the big deal with DRF and I'd love to see more API frameworks take a similar approach. One of the supposed benefits of RESTful APIs is that they should be self-describing, and it seems counter-intuitive to me that so many of the Web APIs we build today are not Web browseable.
Oh, and totally agree with jsw re. testing Web APIs in django, I wouldn't use the framework's browsable API to replace automated tests.

I had the same problem and that was eaily solved by logging out of admin page in that project.

What to do after starting simple_server?

For some quick background, I'm an XHTML/CSS guy with some basic PHP knowledge. I'm trying to dip my feet into the Python pool, and so far understand how to start simple_server and access a simple Hello World return in the same .py file. This is the extent of what I understand though, heh.
How do I integrate the simple_server and your basic XHTML/CSS files? I want to start the server and automagically call, for instance, index.py (does it need to be .py?). Obviously within the index file I would have my markup and stylesheet and I would operate it like a normal site at that point.
My eventual goal is to get a basic message board going (post, edit, delete, user sessions). I realize I'll need access to a database, and I know my way around MySQL enough to not have to worry about those portions.
Thanks for the help.
EDIT: Allow me to clarify my goal, as I have been told Python does a LOT more than PHP. My goal is to begin building simple web applications into my pre-existing static XHTML pages. Obviously with PHP, you simply make sure its installed on your server and you start writing the code. I'd like to know how different Python is in that sense, and what I have to do to, say, write a basic message board in Python.

The other answers give good recommendations for what you probably want to do towards your "eventual goal", but, if you first want to persist with wsgiref.simple_server for an instructive while, you can do that too. WSGI is the crucial "glue" between web servers (not just the simple one in wsgiref of course -- real ones, too, such as Apache or Nginx [both with respective modules called mod_wsgi] as well as, for example, Google App Engine -- that one offers WSGI, too, as its fundamental API) and web applications (and frameworks that make it easier to write such applications).
Everybody's recommending various frameworks to you, but understanding WSGI can't hurt (since it will underlie whatever framework you eventually choose). And for the purpose of such understanding wsgiref.simple_server will serve you for a while longer, if you wish.
Essentially, what you want to do is write a WSGI app -- a function or class that takes two parameters (an "enviroment" dictionary, and a "start response" callable that it must call back with status and headers before returning the response's body). Your "WSGI app" can open your index.py or whatever else it wants to prep the status, headers and body it returns.
There's much more to WSGI (the middleware concept is particularly powerful), though of course you don't have to understand it very deeply -- only as deeply as you care to! See wsgi.org for tutorials &c. Gardner's two-part article, I think, is especially interesting.
Once (and if that's your choice) you understand WSGI, you can better decide whether you want it all hidden in a higher level framework such as Django (so you can focus on application-level issues instead) or use a very light and modular toolbox of WSGI utilities such as Werkzeug -- or anything in-between!-)

I would recommend Django.

"Obviously with PHP, you simply make sure its installed on your server and you start writing the code."
Not true with Python. Python is just a language, not an Apache plug-in like PHP.
Generally, you can use something like mod_wsgi to create a Python plug-in for Apache. What you find is that web page processing involves a lot of steps, none of which are part of the Python language.
You must use either extension libraries or a framework to process web requests in Python. [At this point, some PHP folks ask why Python is so popular. And the reason is because you have choices of which library or framework to use.]
PHP parses the request and allows you to embed code in the resulting page.
Python frameworks -- generally -- do not work this way. Most Python frameworks break the operation down into several steps.
Parsing the URL and locating an appropriate piece of code.
Running the code to get a result data objects.
Interpolating the resulting data objects into HTML templates.
"My goal is to begin building simple web applications into my pre-existing static XHTML pages."
Let's look at how you'd do this in Django.
Create a Django project.
Create a Django app.
Transform your XTHML pages into Django templates. Pull out the dynamic content and put in {{ somevariable }} markers. Depending on what the dynamic content is, this can be simple or rather complex.
Define URL to View function mappings in your urls.py file.
Define view functions in your views.py file. These view functions create the dynamic content that goes in the template, and which template to render.
At that point, you should be able to start the server, start a browser, pick a URL and see your template rendered.
"write a basic message board in Python."
Let's look at how you'd do this in Django.
Create a Django project.
Create a Django app.
Define your data model in models.py
Write unit tests in tests.py. Test your model's methods to be sure they all work properly.
Play with the built-in admin pages.
Create Django templates.
Define URL to View function mappings in your urls.py file.
Define view functions in your views.py file. These view functions create the dynamic content that goes in the template, and which template to render.

Take a look at CherryPy. It's a nice http framework.

It depends on what you want to achieve,
a) do you want to just write a web application without worrying too much abt what goes in the background, how request are being handled, or templates being rendered than go for a goo webframework, there are many choices simple http server is NOT one of them. e.g. use django, turbogears, webpy, cheerpy, pylons etc etc
see http://wiki.python.org/moin/WebFrameworks for full list
b) if you want to develope a simple web framework from start so that you understand internals and improve you knowledge of python, then I will suggest use simple http server
see
how can you create a URL scheme so that URLs are dispatched to correct python function,
see how can you render a html
template e.g. containing place
holder variables $title etc which
you can convert to string using
string.Template
b) would be difficult but interesting exercise to do, a) will get you started and you may be writing web apps in couple of days