I am working on a legacy Django site which is facing a rewrite to replace the existing Flex frontend with HTML5. Further down the line there will be a mobile app (iPad only at this point), which will require a RESTful API.
My question is how much extra work would it be (turnaround is short < 2 months) to implement the web front end in something like backbone.js/mustache talking to a RESTful API on the Django side (probably tastypie) - in comparison to writing it as a standard Django app and bolting on the API later? I'd prefer to go with the former, but just wondering if anyone has gone down this road and what issues you encountered.
IME, RESTful APIs keep the server side clean, thus easier to maintain and scale. Your data models suddenly make sense as you need only worry about CRUD actions - the client makes the necessary API calls, thus allowing your endpoints to return only one type of data/dataset.
Your routes can then become modular and its easier to keep things DRY.
However, reliance on client side JavaScript ultimately means more cross-browser consistency issues. Hope you made the right choice!
Related
Started learning Django lately.
To make long story short - If I choose to combine:
django framework in my server side
REST as the middleware layer
some of the client side frameworks (such as React, Angular, etc)
which of django's MVC components will become irrelevant?
I presume that the templates components. Are there any other fundamental components (model/view ...) that won't be necessary in this case?
Assuming based on your post that you are using Django just to pull data from a database and serve it back to a client in JSON format, and that your templates will be rendered client-side (using, e.g. Angular) then you are correct that you likely won't be needing Django templates. However, you would still need some sort of models (whether you use Django models or something else) and also would need controllers (which Django calls views) in order to:
Do URL routing (that is, bind some URL to some controller/view
function).
Do some kind of server-side processing. Even if your app
is a single-page app and does a lot of client-side processing,
you'll still likely need to implement different kinds of business
requirements and validation on the server side. Some of these
requirements you can likely attach to the models, but others you may
need to implement in controllers.
So while your controllers (aka views) may be a lot "skinnier" due to the way you're structuring your app, they'll still be necessary to some extent. Models will always be necessary if you want some clean and consistent API to your DB.
EDIT: To expand more on this--while there is a Python library called Django REST Framework, it's really just there to assist you in building RESTful APIs. You can certainly build a RESTful API yourself using Django without leveraging it or any additional libraries. As the answer from user D. Shawley states in response to this question -- What exactly is RESTful programming? -- a RESTful API is basically just one where resources are identified by a persistent identifier (in this case, URIs), and where resources are manipulated using a common set of verbs (in this case, HTTP methods like GET, POST, DELETE, etc). So using this idea of URIs as nouns and HTTP methods as verbs, your Django framework might support the following RESTful operations:
GET https://your-app.com/product/123 - this operation fetches a product identified by the ID 123
POST https://your-app.com/product - this operation creates a new product
PUT https://your-app.com/product/123 - this operation updates a product identified by the ID 123
DELETE https://your-app.com/product/123 - this operation deletes a product identified by the ID 123
The data that come back from these operations doesn't necessarily need to be in any particular format (be it JSON, XML, or something else). In an application that closely adheres to the principles of REST, the client (consumer of your RESTful API, in this case your front-end app) would be able to specify (using the HTTP Accept header) which format they want to consume the data in.
I hope that's not too confusing, but really I want to make it clear that REST architecture is just a set of principles, and APIs that web programmers develop may not necessarily adhere to these principles 100%. Whether it's necessary for your application to strictly adhere to RESTful principles depends on your particular requirements. One question to ask yourself then is what are you hoping to accomplish by building a RESTful API using Django? For a lot of developers, the answer is simply "so that I have an easy-to-use interface for my Angular/React/etc. app to retrieve and update server-side resources."
Am I missing something?
But I am really not getting the rationale behind most online blogs and tutorials suggesting to use a base Django template to render a ReactJS bundle (bundled from webpack).
In my mind, the point of using Django Rest Framework in the first place is to completely isolate the frontend from the backend and have something like Nginx serving an html file that would import the ReactJS library (like any other stndard html/js project). The ReactJS layer would then get or manipulate data solely through the DRF REST API.
It is like most developers treat ReactJS as a completely novel beast, when it can be simply treated as standard JS (with added steroids) that runs on the browser.
Can someone therefore explain to me what are the advantages of using the methods depicted by blogs such as Jonathan Cox and Owaislone ?
On one part, you're right. One of React's principles is to make it function like a Mobile app(that consumes REST API) which also compliments React-Native, so there's not much for the programmer to learn and pick up and can quickly develop an app if they are familiar with React. This way, you'd build the back-end to serve both the web app and the native mobile app without much rewriting or customizing.
Usually, people like keeping their code together, front-end and the back-end if they're just developing for the web. It's a common practice. Since Django is widely used and is also an open source framework amongst a lot of web-developers, there's a big community to develop tools or plugins for it. This way, they'd just have one server instance running and configure the backend to serve just the index.html page, and the routing is handled by the browser.
I, on the other hand, prefer the latter part, work on a team with backend engineers and mobile developers. We heavily rely on RESTful calls for our apps. So we keep our code base neat and isolate our backend from our front-end so each of us can work independently.
It's just a matter of preference really, Jonathan Cox and Owaislone both don't preach about the right way to develop React apps, they just demonstrated one of the ways React can be used.
Also, some backends have a lot of security and need to be configured to allow certain headers for making requests. It could make you look at your computer screen for days while you sit there wondering how to work around the problem and you're diving deep into the documentation for web requests. CORS is one of the problems when you isolate your front end and back end code. It's something that can totally be avoided if Django is serving the files.
I'd say you can go ahead and pick one that suits your need, isolate your React code from the backend if you'd want the back end to work on mobile apps too, saves a lot of time.
Me and some friends are going to develop a web site with playframework and a mobile application (android and iphone). So we need to make some webservices for the mobile application(CRUD). So we thought about using this web services in our playframework application instead of wasting time and creating the CRUD with anorm(writing all the sql requests).
Well, I'm here to ask for your opinion. Is this a good thing to do ? What's the best advised method here ?
Thank you.
PS: the web services are automatically generated with Netbeans from our database.
There are various reasons why I would advice against this approach.
A general design rule is not to expose your internal data model to the user. This rule comes in many flavors in which the layered architecture is probably the most known one.
In detail there will be issues like:
Tuning performance: This is hard to achieve because your have no, or not much control over the generated web services. When your application is really taking of your will suffer from this limitation
Access the service: I don't know whether you generate RESTful web services or WS-* ones. The latter will get you in trouble when accessing them via iphone.
Design Play vs. synchronous web services: Also somehow related to performance is the issue that the generated service is likely synchronous, blocking, which does not fit well with the non-blocking approach which the play framework is taking.
Abstraction level: Because your database is based on sets but your business model is likely not, you will have issues developing a decent client, tuning the performance, doing proper validation, security, etc.
Authentication, authorization and accounting: Hard to do because the database only knows the db system users
Change: What if you change your database model? Will the generated services continue to work? Do your have do adopt them event if you just add a column?
...
Some of those reasons do overlap, but I think the general problem should be clear.
Instead of this approach I would recommend the following. Develop a RESTfull endpoint for your app, which is not that hard to to. This is the external contract against which the clients should be developing. play-mini for example has a very need, Unfiltered based, API to do this. While doing this, focus on the operations your app really needs. CRUD in general is a bad model when thinking about production ready software.
How you access your database is another decision your have to make but probably it is not that important because it is not your external contract so your can change it when your have the need for doing so.
I'm currently developing a web application, that relies heavily on mobile and desktop clients consulting the web server for information. This can be accomplished nicely making a RESTful API available to handle this. So my idea is to have an application acting as the "platform" which handles all the real business logic and database information behind the curtains.
My plan is to make the platform using symfony2 and OAuth 2.0 authentication mechanisms, combined with RESTful web services.
Now my real dilema comes on the website component. Ideally I would like to think of the website as yet another client that asks this REST platform for information, and completely separate it from the platform itself.
To make it a little bit more clear, let's say we are making a blog with this architecture, so one would have a "platform/backend" that provides a rest service to list articles, for example: /articles/5. This on the backend, and with symfony2/doctrine means that the app has an Article model class, and these can be requested from the DB. A simple controller queries for the Article number 5 and returns all the information in JSON format.
Now the website on this example, could just do the easy thing and also have an Article entity and just query the database directly, but I think it would be cleaner if it could just talk to the platform through it's REST api and use that information as a "backend" for the entities.
So the real question would be, is there anyway to support this kind of design using symfony2? Have entities rely on a REST api for CRUD operations? Or I'm just better off making the platform/website a single thing and share a "CoreBundle" with all the generic entities?
There is nothing in Symfony that prevents you from doing you want.
On the client side you could use Backbone.js or Spine.js.
Have a look at FosRestBundle, it makes your life much easier to create api:
https://github.com/FriendsOfSymfony/FOSRestBundle/blob/master/Resources/doc/index.md
I am building a application that services users via a web front end, which I have chosen to use Django for. I also have to choose a framework/libraries to provide management of and abstracted access to a bunch of embedded systems that provide information the web user gets to see in one form or another.
I like the idea of sticking with a restful approach to access the backend application which provides the hardware generated resources. Does it make sense to use Django for the front end and CherryPy for the backend? Or should I just use Django for both and ignore the stuff I don't need in django for the backend.
I guess another way to ask, is what do I gain by using CherryPy as the backend that out ways having to know two sets of libraries/frameworks.
I don't see any real benefit, only added complexity in the long run. If you are using Django's ORM, you'll want to build the REST interface around that anyways. For building REST interfaces with Django I like using django-tastypie which makes it easy to build RESTful APIs supporting authentication/authorization, validation, various types of serialization, throttling, caching, etc. I also rather like django-piston, which is also quite popular.