I need to create web application, which can be reached by user as regular web site and as XML-RPC web service. Also web site should have mobile version. I'm planning to use next technologies:
Django (for web frontends (regular and mobile)).
Pyramid (for web service).
SQLAlchemy, Memcached (for persistence level)
Later other projects can reach this data and providing logic, so I think it is better to make two tiers. I see it in next way:
Tier 1. Main logic service level. This level will provide API for frontend applications (Django powered web site, for example).
Tier 2. Different mostly end client applications (web site, API for remote client devices).
For communication between this tiers I'm planning to use XML-RPC protocol.
In this case it will be easy to scale it and add new front end application or connect another projects to this (I believe it).
I have main question, -- what can I use to make it easy build first tier? Maybe there is some framework good for that?
And what do you think about this whole architecture. Because I'm filling that I'm thinking in Java terms developing in Python. Maybe there is some another idioms in Python world for such situations.
Thanks for you time and help.
P. S.
Some links for reading are welcome.
This architecture really makes no sense. You're using Django, a full-stack web framework, for the front end, but not using it for the database. And you're using Pyramid, another full-stack web framework, for the web service side, thus ensuring that you duplicate all the business logic.
Much as I am an advocate of Django, I would say it has no place in your architecture. It looks like the only thing you're really using it for is URL routing and templates, both of which Pyramid does itself fine - you can even use Jinja2, which is based on Django's template language, as the template language in Pyramid if you like.
Doing it this way means that you can share the business logic between the front-end and web service code, since you'll almost certainly find that a lot of it will be the same.
I must say also that I don't understand the division into tiers, which you have described as separate from the front-end/web service division. To me, the web service is the second tier. It makes no sense to have a further division.
You should checkout the Turbogears framework as it is composed of several popular components: ORM with sqlalchemy, pylons for logic and support for WSGI, permits support for several templating engines for the frontend... endless.
I use it for several web-services behind AJAX-enabled front-ends (like Flex-based apps, among others). You can front end the TG2-based webapp with apache or your favorite WSGI-enabled web server too.
Checkout their website since they have a tutorial to setup a wiki in 20 minutes.
Cheers!
Related
I've developed a couple of apps in Django and need to develop a moderately complex new app now. I've heard about AngularJS and I'm considering to use it in my new web app.
From research I have done so far, it seems like the main benefit of using Angular compared to plain Django is a better user experience. Are there any other major benefits that I need to take into account?
I would imagine the disadvantage of this is increased development time. Assuming I get past the Angular learning curve, how much longer will it take to develop the app in Django + Angular than purely in Django? (For instance 150% longer)
One last question is about using Django as the API framework. Effectively, I'm not using all of Django's features, but only a subset. Given this, is Django a good framework to create the API in? What are other alternatives should I consider?
Currently using a similar architecture for an app.
Backend is in Django and I'm using Django Rest Framework (DRF) to create REST resources. It's a highly powerful and customisable REST framework to create API resources.
From my understanding and experience, DRF works very well with any abstracted front end. So you can use the same APIs for any client be it browser or mobile apps. You can also serve the front end content in the same context as the Django backend or even separated. DRF has authentication methods for both types.
Resources: http://www.django-rest-framework.org/
As for learning curve, AngularJS isn't that difficult if you have basic understanding of the concepts of MV* as well as JavaScript. I won't be able to give you an exact time estimate but for me both methods would have lasted as long as each other.
I have a django powered website which allows uploading/downloading of some event, where event contain fields like geocode, some text, an image.
Hopefully the events would be around 1000-1500 at max but they might come simultaneously.
Can django development server handle the pilot load or should I shift to standard web server(will have to do some changes for that)?
you should definitely switch, django dev server is pretty much a toy, a simple single threaded server easily used for development, there are very few steps involved with serving your django application using apache –
If someone uploads a large image, the server will block all other requests during that time, I believe that alone is good enough reason to switch servers.
Additionally, advice from the first page tutorial in django documentation:
Now’s a good time to note: don’t use this server in anything
resembling a production environment. It’s intended only for use while
developing. (We’re in the business of making Web frameworks, not Web
servers.)
Currently I am working on a portal which is exposed to end users. This portal is developed using Python 2.7, Django 1.6 and MySQL.
Now we want to expose this portal as a mobile app. But current design does not support that as templates, views and database are tightly coupled with each other. So we decided to re-architect the whole portal. After some research I found following:
Client side: AngularJS for all client side operations like show data and get data using ajax.
Server side: Rest API exposed to AngularJS. This Rest API can be developed using either Tastypie or Django Rest Framework (still not decided). Rest API will be exposed over Django.
I have few questions:
What you guys think about architecture? Is this is a good or bad design? How it can be improved?
Will performance of portal will go down after adding above layers in architecture?
In the above architecture whether 2 servers should be used to run this (like one for client and other for serving the API's) or one server will be enough. Currently Heroku is used for deployment.
Currently portal is getting 10K hits in a day and it is expected to go to 100K a day in 6 months. Will be happy to provide more information if needed.
If i got an opportunity to architect the portal which you mentioned than i would really love to design the architecture which i have already explained here.
What you guys think about architecture?
This is a common Service Oriented Architecture with decoupled Clients. You just have REST endpoints on your backend, and any Client can consume those endpoints.
You should also think about:
Do you need RESTful service (RESTful == stateless, will you store any state on the server?)
How to scale the service in the future? (this is a legit thing as you already aware of huge traffic increase and assume 2 servers)
How it can be improved?
Use scala instead of python :)
Will performance of portal will go down after adding above layers in architecture?
It depends.
It will get some performance penalty (any additional abtract layer has it's tax), but most probably you won't event notice it. But still, you should measure it using some stress tests.
In the above architecture whether 2 servers should be used to run this (like one for client and other for serving the API's) or one server will be enough. Currently Heroku is used for deployment.
Well, as usual, it depends.
It depends on the usage profile you have right now and on the resources available.
If you are interested in whether the new design will perform better than the old one? - there are a number of parameters.
Resume
This is a good overall approach for the system with different clients.
It will allow you:
Totally decouple mobile app and frontend development from backend development. (It could be different independent teams, outsourceable)
Standardize your API layer (as all clients will consume the same endpoints)
Make you service scalable easier (this includes the separate webserver for static assets and many more).
I'm slightly confused on what is meant by a "web application". I.e. Django positions itself as "a web framework" for the development of "web apps", quite similar to the description of Pyramid. What I'm looking for is a framework for an application that has a browser interface but is very database driven. In short: It's a system that should handle transaction and subscriptions. These transactions are registered through a web interface. The backend consists of XML/JSON feeds of these subscriptions/transactions and an administrative interface to generate statistics and reports. Quite similar to a ticketing/box office system.
Now: Is it a good decision to start out with something like Django/Pyramid even though they seem more focussed on the creation of "websites" rather than (scalable) input/output "applications". Is there any python framework that I'm better of using or are they perfectly suited for the kind of software that I'm describing?
Any help would be greatly appreciated!
I don't know Pyramid at the time of writing so I'll answer the Django part, though I can imagine the answer to apply to Pyramid as well as the distinction between websites and web application is quite vague.
Django is suitable for both websites and web applications: you can create an informative website for your local library as well as an all-in web application with lots of interactive features. Django simply facilitates the creation of the backend of a web system. Both websites and web applications use databases, have caching and can have interactive parts with forms.
It's just that websites are usually just for informing the user (most sites out there) or interacting with others (such as forums). A web application is best described with some examples, such as webmail, administrative interfaces, Google Docs, etc; it serves as a replacement of a desktop application.
From a technical perspective, there's no clear cut thing that separates the world of websites from web applications, it's just a matter of what you create with your web framework.
To answer your question, Django is quite suitable for creating a database-driven web application as it supports multiple databases, caching, autmatic creation and handling of forms, etc. I can imagine Pyramid to be suitable as well but I can't answer that. It's good to explore your options.
I believe that at this point you might want to think more about the overall architecture of your application rather than frameworks. For Example
Single Tier - Just a simple webapp, using simple file or object storage
Two Tier - Webapp + Relational Database. The webapp contains the presentation logic + business logic using MVC principles
Three Tier - Webapp + Middle Tier + Relation Database. In this setting, the Middle Tier will basically contain all the business & processing logic. The Webapp is then just a presentation layer
Once you decide the architecture, you can then start thinking about which framework to use for each of the component of the architecture.
I believe progressing this way will be less confusing and will give clarity of thought.
I'm tasked to create a simple CRUD MVC application, and I thought it's a good opportunity to learn python. Because of its great documentation, I'm thinking now that I'll go with Django.
Now, this simple CRUD MVC application could become quite complicated in the future. I might have receive and issue JMS messages, display charts that are updated periodically (I'm thinking about ajax) and what not.
Given this I'm a little worried, since while I'm told it's easy to call Java code from python (I'm a Java developer), I'm also told that Django is generally best for content based web application, and can be restrictive.
Do you think it is okay to go with Django in this case?
simple CRUD MVC application
Django does this "out of the box" The admin interface is a simple, CRUD, MVC application. You don't do much programming to make this happen. You create the model. That's it. Use the Django admin for your CRUD application. Done.
I might have receive and issue JMS messages, display charts that are updated periodically (I'm thinking about ajax) and what not.
That's the point. Since you didn't waste time writing the CRUD application, you are able to write the other, more interesting stuff.
Look at http://hjb.python-hosting.com/ for a Python-JMS bridge.
We have FLEX front-end and Django-based RESTful web services. The Django apps create PDF's, and other things. The FLEX does pretty pictures and charts.
Django is generally best for content based web application, and can be restrictive.
Doesn't mean anything. Provide a quote or a link to whatever it is you're talking about.
Mozilla is currently rewriting two of our largest sites on Django. These are both fairly complex applications that interact with numerous online and offline services. With Python's large collection of libraries, anything Django doesn't do itself we've usually been able to find, or create pretty easily. For example, we have both cron jobs and on-demand offline tasks, backed by AMQP, which is similar to JMS.
Short answer: you can get pretty darn complicated if that's what you need to do, and odds are there's already a Python project or library to do what you need.