CODEWITHSUNDEEP
djangoweb-applicationsweb.py
Marboni
Marboni

Reputation: 2459

Deviding Django application (social network) to Django Frontend and RESTfull API

I'm writing Django application (social network) and thinking about dividing monolithic project to two projects: UI and API. For example, Django will be used only to render pages, interacting with and taking data from API, written on web.py.

Pros are following:

  1. I can develop and test API independently.
  2. In the future, other UI can appears (mobile, for example), it will require service.
  3. I plan to outsource web UI developing, so, if my application will have two modules, I can provide outside only UI one, not sharing logic of application.

Cons are following:

  1. I'm working alone, and developing two projects are harder, then one.
  2. I will not be able to use cool Django admin panel. I will need to write my own.
  3. web.py is more low-level comparing with Django.

It's like a brain dump, but I will be really appreciated if you share your experience in creating web application with UI module and independent API module.

Update (more specific question, as Mike asked)

What Python framework will you use for creating REST API of social network, which can be used by different client applications? Is using web.py that returns JSON only and rendering it by Django for web is good idea?

Thanks, Boris.

Upvotes: 2

Views: 548

Answers (1)

jbrendel
jbrendel

Reputation: 2448

I've been in a situation similar to yours. I ended up writing both, the UI and the API part in Django. Currently, I am serving them both out of the same process/project. You mentioned you wanted to be able to outsource the UI development, but do hear me out.

In the meantime, I have used django-piston to implement the RESTful front end, but a bit of preparation went into it:

  1. Encapsulate all DB and ORM accesses into a library. You can do that either for your entire project, or on an app by app basis. The library is not just a low-level wrapper around your DB accesses, but also can be for higher-level 'questions', such as "all_comments_posted_by_friends()" or something. This accomplishes two things:
    1. You can call your pre-canned queries from UI views as well as API views without having to re-implement them in multiple places.
    2. You will later be able to replace some - if not all - of the underlying DB logic if you ever feel like going to a NoSQL database, for example, to some other distributed storage model. You can setup your entire app of this ahead of time, without actually having to worry about the complicated details of this right at the start.
  2. The authentication layer for the API was able to accept an HMAC/token based header for programmatic access and normal Django auth. I setup the views in such a way that they would render plain JSON for the programmatic clients (based on content-type), and would render the data structure in HTML (with clickable links and clickable docstrings) if browsed by a human from a browser. This makes it possible that the API is fully explorable and clickable by a human without having to read any docs, while at the same time it can be easily processed by a client just via JSON.

On effect, the database layer I build serves as the internal API. This same database layer can be used from multiple applications, multiple processes, if you wish to do so. The UI views and the REST views were both implemented in Django. They can either be in the same process or in separate processes (as long as they have access to the same database right now).

Upvotes: 1

Related Questions