Guys i would like to use Django as my backend framework and qooxdoo as the frontend framework.
Is it practical to do this?
Has anyone tried to do this?
How did they do it?
Links and pointers would nice.
Gath
I have no direct experience using Django and qooxdoo, but the general answer to the question "Is it practical?" is: yes :). Although Django's default rendering behaviour is to produce HTML (which is unsuitable for a single page application like the ones you build with qooxdoo), it's easy to switch to returning e.g. Json on requests, which is a common format for the client-server communication between a qooxdoo frontend and a server. They just exchange data.
Has anyone tried to do this? - Yes, but they don't give much information on how, other than the before mentioned Json data exchange, implementing a Json RPC server in Django using RPC4Django.
AFAIK, there is no deeper Django integration, e.g. interfacing qooxdoo with Django views on the server (like dojango).
Hope this helps.
Update:
There is one elaborate product, Sava, using qooxdoo for the frontend and Django for the backend. There is a short overview, but I think it's closed-source so it only testifies to the "practicality" of using this technology stack. You probably won't learn in detail how it is realized.
There is also enre, a qooxdoo-based GUI for Django. But I'm not familiar with it, and couldn't find any documentation on first glance, so I'm not sure what this really means.
Related
I want to use Django Rest Framework as an API and am looking for a way to "couple" the frontend / HTML/CSS/JS to it.
To put it in perspective, I am used to the way Django "usually" does it, by naming HTML templates and 'rendering' them when going to a particular URL.
Now, with DRF, it appears that this functionality has fallen away and everywhere I look it's just "react.js or vue.js" as the answers to consume the API.
What are my options for the front end? Can I not just do it all within the 'usual' Django framework, simply, as it was done before. And why do no resources talk about this?
Thanks, let me know if you require further info.
DRF is just additional layer for Django which help to implement API. You can use Django for render html on server side and serve it to browser. You don't need use DRF for it. But if you assume that you frontend app will be interactive, dynamic and complicated then it is not best way to solve it.
More popular approach suggest to separate it on frontend application (react or vue) and backend with REST API for interact with. It allow move all things related with UI on frontend app and only keep state on server.
By the way Django was developed for generate html on server and for site like this https://www.washingtontimes.com/news/ but world changing. Resources talk just about popular things
I have a single page app built with emberjs with an a rails backend. Is it a common pattern to build an admin interface on rails serverside on a subdomain. What is the right approach for this?
Your question is vague but I will try to answer it my best. I have done this with a Node and a Go backend combined with Ember.js.
No, there is technically nothing to prevent you from doing a single page application for an admin interface.
Rails is a good choice for this, and generally you should stick with the backend framework/language you and your team master the most.
As for what would be the right approach, there is no magic recipes. Document your code, write test and follow best practices for the tools you are using.
One key element though will be the communication between your frontend and your backend. Ember chose to follow the JSON API specification (http://jsonapi.org/) and comes out of the box with an adapter to talk with these kind of API. Using such adapter will help you save a lot of time.
Here are some implementation of JSON API for Ruby : http://jsonapi.org/implementations/#server-libraries-ruby
One more thing about your frontend code structure. You haven't say how big your app will be. If it gets big, you may want to take the pod approach in ember-cli (http://ember-cli.com/user-guide/#pod-structure). It basically changes the structure of the code so it's easier to maintain a lot of files.
Django rest framework is a great tool to expose data in restful protocol, but does it have a built in client that does the heavy lifting at the back to enable easy implementation in SOA architecture between different django projects?
So far I haven't found much from the django rest framework documentation, hopefully someone can shed some light on this one.
There is no "official" client for DRF, since REST-APIs mostly don't have much "heavy-lifting" as you perhaps know it from SOAP or similar techniques.
For most REST-APIs slumber is the easiest way to connect to these. It handles url-building, authentication and json-dump/load.
I recently created a package that mimics the django queryset over DRF.
django-rest-framework-queryset
I would like to create an oauth (REST) API the same way Twitter or Foursquare does.
I found this website http://djangopackages.com/ which is really great and has several packages but I would like some opinions on which is the best package, etc...
I would like, for example, let people to allow permission to 3rd party apps to access their data (Using API Keys, etc...)
Thanks a lot!
Django is a wonderful web framework. It helpes you in many ways making rich web applications. It helps you starting in form handling and ending in templating.
However in your case if your intension is just to make an awesome API such as of Twitter or Foursquare, you have to ask yourself if you need all this help Django provides. For example, are you ever going to use any templates in the API or process a for submittions. The answer is probably not...
So if you need a very flexible framework to developer an API, I would highly recommend to take a look into Pyramid. It is very similar to Django, however does not have all this extra cludder which is not necessary for an API.
However if your application needs both a rich user interface and an API or you just want to use Django, like Ulusses suggested, then I think TastyPie is for you. It is a great library where you can have a running API in no time. I use it all the time and it is very flexible. ReadTheDocs uses tastypie.
Another API lib is piston. I haven't used it so can't judge if its better or worse then tastypie. Bitbucket however uses it.
You can check out https://github.com/toastdriven/django-tastypie or https://bitbucket.org/jespern/django-piston/wiki/Home.
You can achieve what you want with both, check out on the documentation the one that suits you best.
I use Django REST framework. It is awesome.
Piston is dead. Tastypie is awesone, but works with Django only. There are pros and cons with Django as well as Pyramid. If you need great ORM, sqlalchemy is only one, and there is no good example of using it with Django, so in this case you have Flask, Bottle or Pyramid. Django ORM is really not at that par.
If you choose Pyramid, you will have to write a lot of things, and the framework is just skinned boneless cat. You need to assemble and configure every block, seems frustrating to many including me.
We're looking for a general RESTful API solution for our Django project. We would use the API at first for Ajax calls on the web site and later for mobile apps, external apps and things like that.
I found two modules which seem to be widely used. django-piston and django-tastypie
From what I read, piston seems to be older and thus more mature but maybe a bit outdated?!
While tastypie is relatively new and nicely documented.
What would be the best thing to go with? django-piston or django-tastypie?
Important for us (ordered by priority): Continuous maintenance of the source, documentation, stability, ease of use.
EDIT (2013 Jul 16th):
Now over a year later we have a clear winner. At first we went with tastypie. Which we kinda liked. But after half a year or so we switched to the then upcoming django-rest-framework and never looked back.
What we like most about it:
Nice documentation
Active community
Clean design (build upon django's class based views)
Browsable API for development and debugging
We rely on the API heavily so support (in the future) is one of our main concerns. We met the maintainer - Tom Christie - (on and offline) and he seems very committed to the project. So we feel very comfortable using the django-rest-framework.
A good resource to compare them is http://www.djangopackages.com/grids/g/api/
Django-tastypie sure is the save choice right now.
Personally I'd advocate a look at django-rest-framework if you use django 1.3, because it uses the new class based views. djangopackages.com's comparison page shows it has good participation and activity. And, wow, it sure has a nice browsable interface to the API.
I have no experience with this, but I trust Pydanny in this:
django-piston has been barely supported for nearly two years. That is
an eternity, and the number of forks to address multiple issues is a
cause for alarm. Because of that, in it's place at this time I
recommend django-tastypie. It is up-to-date, has very good
documentation, supports OAUTH, and scored second place in the Django
Packages thunderdome (it got nearly 3x as many points!). Another tool
to consider is Django Rest Framework, which is as good as
django-tastypie but lacks the OAUTH support.
On the django-piston front, Joshua Ginsberg has taken over the reins
and we should hopefully see some movement again. In which case I'll be
able to remove this section of the blog post.
from Pydanny's blog.
Having implemented API's with django Piston, tastypie and django webmachine Django tastypie rocks! Having said that, I think that while tastypie is really good when your API is modelled close to your models, it's a little bit more complicated to do things once you want to move out of the box. There are workarounds to some issues, with others you have to do more bending than building. It will, probably, still cover 90% of django use cases.
Afaik Webmachine was modelled after the popular erlang webmachine, but hasn't been very active lately. So that leaves piston, which is picking up some activity, and tastypie, that has a lot of momentum and activity. Piston is a bit more flexible, but tastypie is moving very fast and in my opinion has a really easy API.
My recommendation would be to quicky implement a prototype of the API in tastypie, and see if it covers what you want to do.
Django REST framework 2.0 was anounced in Oct 2012 and now supports OAuth out of the box. What I really like is the Web browseable API, which is really helpful when developing your API, but also when someone implements your API. It's kind of comparable with using the Django admin site for inspecting your models' structure and data, but then for your API. Also the documentation is very good.
From their website:
Django REST framework is a powerful and flexible toolkit that makes it
easy to build Web APIs.
Some reasons you might want to use REST framework:
The Web browseable API is a huge usability win for your developers.
Authentication policies including OAuth1a and OAuth2 out of the box.
Serialization that supports both ORM and non-ORM data sources.
Customizable all the way down - just use regular function-based views if you don't need the more powerful features.
Extensive documentation, and great community support.
Check out their Quickstart guide to get a quick idea of how it works.