We have developed a django app and finished all view and templates. There are many controls in template and views. Our new frontend partner says us :
I want to use angularjs, so develop a webservice for me.
So, what is advantages and disadvantages ? Why we might omit the written view and templates?
Any help with this issue will be appreciated.
AngularJS is modern javascript framework for creating complex web
applications within the browser. It focuses on strong separation of
concerns (MVC) and dependency injection to encourage creating
maintainable (and testable) modules that can be integrated to develop
rich client side functionality.
With the advent of more interactive web applications, a ReSTful API
can be leveraged by rich client interfaces to expose and interact with
your application's data model. AngularJS is a great companion because
of its clean separation of controls. AngularJS's modular architecture
involves a little bit of setup. Your app is composed of modules
which define services, directives and controllers that
compartmentalize the functionality for cleaner separation.
Part of the power of AngularJS, is that it provides reactive
programming leveraging their javascript-like expression language.
We can simply define a template that references variables, and our page will automatically refresh when changes are made to those
variables.
Django Rest Framework is best choice to expose your web services/apis as it uses less code.
i might think you have to omit/keep aside the existing views/urls as it uses django forms to store the data etc. Whereas you have to handle the json data (applicable if you not use django rest framework)
reference link
Related
I've been working with the django framework and mostly have been using html templates for its front end but im wondering whether i should switch to React if it's a big project? Alternativelyl, can i create a user interface application without using React as front end or is React / ReactRedux advisable when using Django?
Can you achieve greater functionality with React when manipulating the front-end as opposed to using views in Django?
Advice for when to use React does not have to do something with Django. It mainly depends on the complexity of the application that is to be developed. If you have, or will have a Web application with a complex frontend, containing many functionalities and quirks, which can grow to a large codebase, it is a good idea to use one of today's popular frameworks such as React, Vue or Angular. They allow you to divide the large codebase into components and manage them more easily.
So, the short answer is - if it is going to become a large and complex application, it is a good idea to use React. Otherwise, Django templates will be just fine.
If your application's frontend getting larger and larger and you feel that your are repeating too much html page for example , you might want to use a SPA and component based framework to reuse the components across the application.
If you want to separate backend and frontend code to acquire more maintainability and separation of concerns that might be the reason
If There will be more than one clients(Web, IOS, Android etc.) it is a good idea to separate backend code from frontend(client)
Frontend framework will bring more structure to your application therefore it will be more easier to maintain the project
Otherwise Django templates are good to build a fast project like a few form entries and an introduction page etc.
Hello I am tasked with translating a current Excel tool to a web application. I decided to use Python and Django. Lately I studied the Django REST framework. I have the following related questions.
Is it for such an application a good idea to first write a web REST API so that I
firstly only need to focus on the backbone of the web application. I.e. implement the PUT, POST, GET and DELETE methods and the Django models.
The second step would be to implement the user interface... But if this is a valid method how can I reuse the REST views??? I followed the REST tutorials, but they don't show how to build a nice slick user-interface on top of the REST API.
Since REST views inherit from Django, I think it's maybe not such a good idea to write a Django view which inherits from a REST Apiview? Or can I directly use an API endpoint in a template. If so where can I get some nice examples?
Writing the back-end separately using Django REST Framework is a great idea.
There is a strong architecture based on the idea of decoupling the back-end from the front-end. After you finish the project's backbone, as you are calling it, you can start creating you front-end but your don't have to use Django template rendering in that case.
You can take the pros of using REST APIs and you can use one of the good front-end frameworks or libraries as Angular and React.js.
Another advantage of this that the same API can work with mobile development and so on.
So you develop one back-end and multiple front-ends depends on your need.
Also you can read a discussion about your question on Quora: https://www.quora.com/Why-does-it-make-sense-to-separate-front-end-from-back-end
Historically I've mainly written web apps in Django, but now I'm increasingly finding that I want to write single-page web apps using Backbone.js or a similar JavaScript framework, with a back-end that solely consists of a database and an API.
My questions is this. If my application structure looks like this:
1. Database
|
v
2. API methods
|
v
3. Single-page front-end written with Backbone
and I'm most comfortable in Django - but also keen to learn new things too, such as NoSQL and Node, if they are appropriate - what would people recommend I use for (2)?
Typically I would use Django with Piston as the API app, but it seems rather heavyweight to have all of Django and only use it as an API provider. Perhaps I shouldn't be worrying, though.
If you use Django, which is an MVC framework, and use Backbone, you might be comfortable setting up your app in pure Node.js or Express.js, with additional modules for connecting to your choice of database.
With Express, if you plan to serve only JSON via RESTful interface, you don't even need to use Views, which is handy. You would only need to set up models and routes (that also serve as controllers).
Any server side framework or lang that is capable of supporting or providing for RESTful APIs should work. I myself as using Slim PHP right now. But seeing that you are from a Django/Python background perhaps this post would be helpful to you.
Recommendations of Python REST (web services) framework?
This question is regarding the co-extisense of two MVC Frameworks (on the client side and the server side).
Some Background: I am fairly new to web development, but am a very proficient programmer. I learnt javascript and Django only recently. The Front end for my app is quite Javascript extensive and hence I decided to use a framework. I am currently reading up on the available frameworks and I am inclining towards backbone.js + jquery.
My problem is that I don't fully understand how a MVC framework like backbone.js can co-exist with a server side framework like Django.
From what I understood of backbone.js, when there is a change to a model, the corresponding views related to the model are automatically updated. Here, we are referring to the "views" of the Client side framework right? Would such a "view" communicate with the backend framework's "controller"?
How would a possible directory structure be? Is such an architecture bad?
Does the question make sense? or am I lost?
Edit: To add some clarity: I guess my essential question is : How a complex single-page JS web application be structured on the client-side (espertially if u are using a client side framework)? Specifically I'm curious about how to cleanly structure the application in terms of its model objects, UI components, any controllers, and objects handling server persistence.
I can speak in terms of Rails/Backbone, but I can't imagine that Django would be much different.
First, a client-side MVC framework like Backbone isn't just for single-paged apps. You can also use it to add some rich interaction to one or many views of a more traditional app. They simply provide structure and data abstractions on the client.
Next, these client-side frameworks are designed specifically to work with your back-end MVC frameworks. Backbone.js (since you tagged it specifically) models and collections work with REST services. They will talk via GET/POST/PUT/DELETE verbs and will ultimately communicate with your controllers on the back-end when they make asynchronous requests.
In the case of Backbone, it talks JSON instead of HTML. In the case of Rails, this is really easily handled in the controller. If the request is an HTML one, then you return a view as HTML. If it is a JSON request (*.json or Content-type) then the controller returns a JSON representation of the data. I am assuming that it is as easy in Django as it is in Rails to have the same controller respond to multiple content requests (HTML, XML, JSON, etc)
I have a fairly conventional Grails application. It's monolithic; although it's somewhat split into plugins along functionality lines, it is built into a single war for deployment. Due to company architectural constraints, I need to consider isolating the app's persistence into a web service (or series of web services). What's the best approach to dividing a Grails application into a persistence service and a presentation application?
Put your domain classes in a Grails plugin, and have two distinct Grails applications, one for your web front-end and one for your web service. Both access the database directly, but code for persistence is not duplicated.
Here is a blog post that have some more details on how to realize that.
I don't have an out-of-the-box solution for your problem, and I don't believe there is one. I'll just explain the solution I use and what I would consider in your case.
In my organisation, our approach is to separate our applications in a Grails back-end and a front-end in Flex. The reason is that we have many ready-to-use Flex components that would take too much time to re-implement using pure web technologies, but here's not my point.
Creating a REST back-end in Grails is quick, as views are scaffolded when appropriate, controllers are straightforward, and input validation is greatly simplified by Domain constraints.
The drawback of this split is that definition of domain objects have to be duplicated in the front-end. You might includes objects validation in the front-end or not, but if you omit them, it will have an influence on UI responsiveness (requests to the REST back-end in AJAX calls for real-time validation to get the errors). At the end, our application is quite cumbersome because modifying objects in the back-end implies modification in the front-end. Furthermore, we do validation in both the front-end AND the back-end, and this code is not shared, so it must stay in phase and maintained at two places.
Our applications are split in a way that's similar to two completely distinct Grails applications that would share no code. A solution that would work in your case but is not what you are looking for, for sure.
In your case, I see two viable solutions for the web front-end:
use the Groovy REST client library to fetch and send back your domain objects directly from your controller. If needed, pack them in command objects that reflect your domain objects, so that you can share validation code with the back-end.
create some kind of REST GORM that replaces Hibernate with queries to your REST web service. You could look at the GORM for Mongo Plugin as an example of how to create such a GORM replacement.
I like the last idea, it would be a useful public plug-in. It doesn't exist yet, unfortunetly.