We Keep Coding

Django and Node – how does it work? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
In order to make an web application with RESTful capabilities I have read and watched tons of articles and videos and I still do not get a complete picture of how it works. And which I should chose. Every other answer is the not helpful ”it depends”. I have boiled it down to a first choice between Django and Node. But nowhere I find the whole ”picture” of how the pieces works together and which modules are needed. Therefore I have tried to put all into a rough illustration. Note that I am a complete newbie on this.
I develop an ERP application with accounting modules. Basically it is mainly about CRUD besides viewing diagrams, printing and storing documents. So this is the ”it depends”
The only thing I have managed to make decisions about is to use nginx, Postgresql and Debian 8 as tools/os. These are the fixed stars.
My questions are not really the common Django vs Node.js and it is not just an opinion I want:
Is the picture below correct? Any comments?
Is there any further components that will be needed? To get started?

You have a lot of questions - and on StackOverflow there should be one question that can be answered without generating a lot of debate or have opinions rather than facts.
As such, I think your question might be closed as "too broad"; however I think it deserves an answer.
I am not going to say "it depends", although that's really all it boils down to - but here is my attempt to explain it.
nodejs is a runtime. It is an environment which allows you to develop code on the server using javascript. In order to do anything useful with nodejs, beyond "hello world"; you'll need to use a framework, and there are tons of those around and various stacks have been developed by the community to tie in all the components together. An example of such a stack is MEAN, which is MongoDB for the database, Express for the framework, Angular to assist with the front-end, and Node to run it all.
django is a framework - it is not a runtime. This means that it is one step removed from the node world. The runtime for django is Python. django also is not a "stack" like MEAN, you can develop your own stack on top of it - but since django is a "batteries included" framework, you only really need to add a database to it - it includes everything else you need.
REST is just a way of designing web-services. Its not a language, or a platform or a library. Its a set of rules that describe a way to design APIs such that they take advantage of the semantic verbs of HTTP.
You can use any library and programming language to develop a RESTful service. All you really need is two things [a] a library to communicate over HTTP [b] a way to serialize data, preferably in JSON (but even that's not a requirement).
nginx is just a very fast webserver and a reverse proxy. The reason it is mentioned often - is because it is very expensive for a framework to serve static media. All requests to a framework (either in django world, or in nodejs world) have to go through a large chain of components that help decode the HTTP request and create a data structure that is easy for developers to use. This chain of components is often called middleware. Since each and every request has to go through this middleware, it is better for performance reasons that requests that don't need the "power" of the application to execute (like a request for an image, a stylesheet, a video file) be handled by something else. This is what nginx is used for, since its a very fast webserver.
Now that those are explained, you need to see what stack works best for your application. To do that, you need to know a bit about the philosophy/justification or problem that each stack is trying to solve.
For django - this is easy. Django was created by a team working on multiple newspapers to help them manage content that was published on different sites. As such, it is designed so that the management of content is of primary concern. That is why it has a very robust administration console as a standard component; and a built-in quite robust ORM and its own templating engine. Django leaves it up to you to figure out how best to actually run and deploy it; although they do provide a lot of suggestions and examples - but in the end, its upto you to decide which database to use, which web server to use, and how to deploy the application.
In the nodejs world - the primary focus is nonblocking I/O and speed of response. Nodejs excels at being able to serve a lot of simultaneous requests on limited resources. Therefore, it provides you a very powerful foundation to develop applications that need to quickly respond to requests ... and that's it. When you program in node or any other specialized lower-level library, you need to make sure your code is taking complete advantage of the library. So, if you start writing blocking code in node, you'll find that the performance that you expect hasn't been achieved.
nodejs doesn't care what the application actually does. Think of it like a very fast, very powerful tool. You can build anything with it, but you need to know what the tool is designed to do best in order to know when to use it.
nodejs has you working at a lower level - which is why there are a lot of packages that help you do all sorts of things with node; and multiple ways you can take components and create your own stack - depending on what you are building on top of node. Think of it like Lego building blocks.
nodejs and django are not mutually exclusive. You can utilize both in your application and exploit their strengths and take advantage of what each does best.
As far as your specific questions:
Did I get the picture? Any comments?
I don't know. Did you?
Is there any further components that will be needed? To get started?
The answer to this is yes, because you don't want to build everything from scratch. Each stack has its own libraries components for developing services. For django, there is django rest framework (DRF).
Which framework are best for CRUD?
Which framework are best for RESTful? Any other module needed?
Best report generator for printing?
Best diagram tools?
There is nothing that is "best" for anything. This question is just asking for opinions. Its like asking, what is the best fruit juice?
Which framework are fastest and most reliable for CRUD using Postgresql
People have developed many robust applications on top of postgresql; however as nodejs is bound to javascript - there is still a lot of work being done in this area.
Can I lock the library (trade secrets) in both environments?
Yes.
Is there better tools for creating ERP/Accounting?
ERP and accounting are two very different things. There are tons of accounting packages/applications written in Python. There are very few ERP systems written in Python.
You cannot combine the two and lump it together.
What is the benefits using Angular on top of Node.js?
The same benefit of using Angular on top of _____ (insert your favorite backend). Angular is just a front end library.
An anecdotal benefit is that both Angular and Node use the same programming language.

Which python project to choose for a database-heavy application

I plan to develop a rather database heavy (~100 tables) web application in python. The focus is on providing a nice and task-optimized interface for people that edit or navigate through the data. Other focuses are:
Handle lots of data and complex queries.
Internationalization (translation, timezones, currencies)
Mailings (bulk emailing as well as notifications)
Easy integration into other websites (pull data from or push data to the application)
A role based authentication scheme. (ideally enforcing one role at a time)
It should be easy and fast (for python programmers) to create custom forms and workflows to work with the data.
I've read a lot about django, turbogears, pyramid, webcore, … but I'm still having a hard time to figure out where to start.
My current evaluation would suggest that turbogears is the way to go. Pyramid seems too much to learn about. Django seems to be too publishing focused. WebCore seems a bit to immature to base such a project on it.
Am I overlooking something? Are there other more suitable python frameworks? Is my information about some of them plain wrong? Which framework would you choose for this project, and why?

Imo the only part of django that might be "too" publishing orientated is the admin, but I have seen plenty of django applications doing stuff neatly.
Django has plenty of apps available covering what you want to do, but the only road block you might find is the part of: handle lots of data and complex queries. You will probably move out of django ORM land, but you might even move out of SQLAlchemy land too. Most of these projects use ORM's, so I would look into SQLAlchemy first, and evaluate how to use it for your needs.
Second, I would just go through the tutorials of the following projects, reading about them is good, but a small little tutorial/project (or mini prototype) is the only way to see if the project fits your programming style: pyramid, turbogears, and django. They have afaik the largest communities. The best tool will be the one you feel more confortable with. They all have good, excellent documentation, good supportive communities, and are mature enough for solid projects, and for very subtle differences, you probably can use any of them for your needs.

I have to agree with you: if you already have a database model, Django is not potentially the best way to go.
As of database binding, SQL Alchemy is definitely worth checking out, regardless of which framework you choose.
Some additions to your list:
Web.py - A little low-level, but a nice, mature framework (for SQLAlchemy usage, see cookbook on SQLAlchemy)
Tornado - Very good performance, supports Websockets which could be of a concern for some applications.
Edit: nowadays I would recommended Flask instead of Web.py. Tornado works really nicely with it as well.

The number of tables is not relevant for speeds etc. and not relevant for the choice of the framework. Recommendation: use SQLAlchemy as ORM between database and application. Go for Pyramid as web framework. Pyramid is easy, well-documented, test and very flexible in all aspects. Forms etc. can be easily created using "colander" + "deform" add-ons.

My gut says you want to use SQLAlchemy as the ORM. Turbogears does this out of the box, and probably is the largest player in the "not Django" space.
There was some work on pulling in SQLAlchemy for (or in addition to!) Django's ORM, but I don't know how current that work is (a quick google search found articles from 2008-2009 as the top hits)

webapp, tipfy or django on google app engine [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
which one are you using on google app engine?
what were the reasons behind your decision?

Tipfy
It's developed as an extension to webapp, so it's just one abstracted layer.
That abstracted layer is very minimal. Methods have the same or similar names to their webapp counterparts, but with useful extras that you'd probably end up coding yourself.
Simple routing; if you're familiar with Django or web2py, tipfy's routing is a huge step forward.
Finally, tipfy has an excellent support community. Rodrigo Moraes is especially helpful and engaging. Questions are answered very quickly, and courteously.

Although I mainly work with Django for larger work related projects (hosted elsewhere) I've tended to use webapp for things on App Engine. App Engine to me is best suited for small webservices that you then link together into a full app, and webapp suits that usecase pretty well. Small hacks as well I always use webapp just for simplicity and speed of development. Examples imified-demo.appspot.com, gitbug.appspot.com and github.com/garethr/appengine-image-host
Downside is tool support, you probably have to hack together little things to make your life easier that already exist in the Django world (eg. a test runner http://github.com/garethr/appengine-testrunner)
Anecdotal evidence from a previous project made me feel like Django was a little slow on App Engine for my liking.
Tipfy sounds a good idea, hopefully a case of App Engine maturing as a platform, although I have no personal experience with it at this stage.
All things considered it depends. A big project with multiple developers should probably opt for Django. It's standard ways of doing things will make life easier for everyone. For one off projects I personally prefer webapp or similar. But set aside some time for building your own tools as well as writing your application.

Imho..
Django - the only part that's relevant is the templating and maybe the no rel..
Webapp - never tried it after
Tipfy - is what I'm using, seems to be more "pylons" like, has a basic apps/modules structure and lots of "helpers" which quite frankly should be in the google.appengine.api
Easy to implement templates and routing is nice. Your pretty much left on your own on how to use tipfy and how to structure the application.

I'm still investigating, but I think webapp and tipfy will be a lighter framework than django. Right now, I am using just webapp and the cold start times are already too long. I want to use tipfy for sessions and keep everything else in webapp.
What are you trying to optimize for? Speed of development? Easy of programming? Obscure middleware?

I would still prefer Django for its structure and a high support available over internet for it and for the following reasons:
Webapp offcourse is light weight, but
Django comes with a nice structure
which saves a lots of time while
working on a large application.
Google app engine does provide a good
document for working with Webapp but Django has
a large community of programmers and
thus proves to be a better choice for
implementing some complex
applications.
Django provides a default admin
panel, which otherwise would need to
be created in Webapp, though Google
app provides an admin interface but
that is not equivalent of a full
fledged customizable admin panel.
Webapp itself follows Django for its templates.

I use webapp2 which is a derivative of tipfy (in fact the functions and docs are in many cases identical) and takes ideas from other frameworks too. I recommend taking a look at some boilerplates if you are starting a new project and want to get a quick feel for the framework. Take a look at this boilerplate i've been working on with coto if you are interested in webapp2: http://github.com/coto/gae-boilerplate

Can anyone point out the pros and cons of TG2 over Django?

Django is my favorite python web framework. I've tried out others like pylons, web2py, nevow and others.
But I've never looked into TurboGears with much enthusiasm.
Now with TG2 out of beta I may give it a try. I'd like to know what are some of the pros and cons compared to Django.

TG2 has several advantages that I think are important:
Multi-database support
sharding/data partitioning support
longstanding support for aggregates, multi-column primary keys
a transaction system that handles multi-database transactions for you
an admin system that works with all of the above
out of the box support for reusable template snipits
an easy method for creating reusable template tag-libraries
more flexibility in using non-standard components
There are more, but I think it's also important to know that Django has some advantages over TG2:
Larger, community, more active IRC channel
more re-usable app-components
a bit more developed documentation
All of this means that it's a bit easier to get started in Django than TG2, but I personally think the added power and flexibility that you get is worth it. But your needs may always be different.

TG2 takes Pylons and changes some defaults - object dispatching instead of Routes, and Genshi instead of Mako. They believe there's only one way to do it, so apps can rely on the same API for any TurboGears website.
Similarities
TG2 and Django both distinguish between websites and components, so you'll eventually see reusable building blocks for TurboGears, too.
Differences
Django uses its own handlers for HTTP, routing, templating, and persistence. Django also has stellar documentation and an established community.
TurboGears defaults to best-of-breed libraries, which apparently are Paste, object dispatching, Genshi, and SqlAlchemy. This philosophy produces a better all-round toolset, but at the risk of instability - because it means throwing away backwards compatibility if and when better libraries appear.

Pros.
SQLAlchemy > django ORM
Multiple template languages out of the box (genshi,mako,jinja2)
more WSGI friendly
Object Dispatch > routes > regexp routing. You can get the first 2 with TG2
Almost all components are optional you can keep the core and use any ORM, template, auth library, etc.
Sprox > django forms
Cons.
- Admin is more basic (no inline objects yet!)
- less third party apps
- "app" system still in the making.
- given it's modularity you need to read documentation from different sources (SQLAlchemy, Genshi or Mako, repoze.who, Pylons, etc.)

I was struggling with the same question months ago and decided for Turbogears 2, and my reasoning was simple. "I'm new to python, I want to learn it not just for web-projects but as a substitute to php for scripting small helpers"
What I didn't like about Django, to me looks like a "close platform". ORM, Template system, sessions, etc they all are Django's
On the other hand, Turbogears 2 uses already known open platforms and just glued them, just like Appfuse does it for Java
With TurboGears 2 I learn SQLAlchemy that I can use later for small python scripts, or from the python shell to solve common tasks.
Main drawbacks are the lack of complete documentation and error messages.
Sometimes you have to search very deep to find simple solutions, the learning curve is steep, but it pays long term. The error messages where to me very confusing (coming from more than 10 years in Java development). I had lost many hours trying to find an "ascii encode error" when the real problem was a module not being imported.
That's my opinion, just remember I'm new to python and I could be wrong about many things stated here.

Besides what Nikhil gave in his answer, I think another minor difference is that Turbogears provdes some support for javascript widgets and integration with Mochikit.
Whereas Django steadfastly remains javascript framework neutral.
(At least this was true with older versions of Turbogears... this might have changed with TG2)
Edit: I just went over TG2 documentation and see that it did indeed change. Turbogears now uses ToscaWidgets which can use jQuery, ExtJS, Dojo, etc. underneath. This nicely makes it more framework neutral while still providing nice javascript widgets.
This strikes me as a pro for Turbogears if you don't have any javascript experience and a pro for Django if you are writing a lot of specialized javascript.

One of the most important questions is not just what technical features this platform provides or that platform provides, but the driving philosophy of the open source project and the nature of the community supporting it.
I've got no dog in this fight myself, but I found Mark Ramm's talk at DjangoCon 2008 to be very interesting on this point (Google will yield no end of subsequent discussion, no doubt).

Because Django uses its own ORM it limits you to learn that ORM for that specific web framework. I think using an web framework with a more popular ORM (like SqlAlchemy which TG uses) increases your employability chances. Just my 2 cents ..

Last I checked, django has a very poor data implementation. And that's a huge weakness in my book. Django's orm doesn't allow me to use the power of the underlying database. For example I can't use compound primary keys, which are important to good db design. It also doesn't support more than a single database, which is not a big deal until you really need it and find that you can't do it without resorting to doing it manually. Lastly if you have to make changes to your database structure in a team-friendly way, you have to try to choose between a set of 3rd party migration tools.
Turbogears seems to be more architecturally sound, doing its best to integrate individual tools that are awesome in their own right. And because TG is more of an integrator, you're able to switch out pieces to suit your preferences. Don't like SQL Alchemy? You can use SQLObject. Don't like Genshi templates? You can use Mako or even django's, although you're not exactly stuck with the default on django either.
Time for tg2's cons:
TG has a much smaller community, and community usually has its benefit.
Django has a much better name. I really like that name ;-)
Django seems simpler for the beginning web developer, with pretty cool admin tools.
TG has decent documentation, but you also need to go to Genshi's site to learn Genshi, SQL Alchemy's site to learn that, etc. Django has great docs.
My 2 cents.

Is Pylons enterprise-ready? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am a developer who is looking for an Enterprise-ready web application framework for Python. My main concern is long-term support, extensive feature set and reliability.
I have been experimenting with Pylons and after my horrendous experience with Ruby on Rails on Windows where I even had to compile my own Postgres driver, Pylons and Python have been a godsend.
I believe Python, due to a very strong community and commercial interest, is definitely 'enterprise-ready' due to the number of available libraries and their efforts to maintain some semblance of backward compatibility for Python 3.0. My worry is:
Can we all say the same for Pylons 0.97?
On a side note, I have been figuring out how to get SQLAlchemy working with DB2 on Pylons so that I can automate basic CRUD operations. The current DB2 driver on http://code.google.com is quite useless only supporting SQLAlchemy 0.4. Do you think IBM is committed with making DB2 work with SQLAlchemy for the long term? Or you guys feel it's better to make SQLAlchemy interface with the ODBC driver supplied with DB2. Any disadvantages compared to using IBM's SQLAlchemy driver?

When it comes to enterprise ready, I'm not sure how much more ready a stack using Pylons with SQLAlchemy can be in the Python world. You're ready for massive legacy databases with crazy schemas (totally common in large corporate worlds), something where Django just falls apart at the seams. Sure, in Django, you could still use SQLAlchemy, but then all the Django contrib tools fall apart since they all rely on the assumption that you'd doing things the "Django" way.
Pylons has been around since mid-2005, and it isn't going anywhere. It's actually quite mature, and has a fairly slow and solid release schedule of 6-10 months between releases, with quite a bit of testing. One of the core Pylons developers is also a developer on Jython ensuring that Pylons can run on the JVM (which helps get Pylons based apps into enterprise environments that are hostile to things that can't be packaged up into a WAR file for deployment).
Regarding some of the other 'answers' here, the question is about whether Pylons is enterprise-ready, I have no idea why others were unable to read the question and instead chose to start preaching their own favorite framework. It's quite silly to say that you should use Django/Zope/Grok because it has "bigger uptake" or a "larger community", if that's the criteria the choice should be PHP, which makes the Django and Zope communities look itty bitty in comparison. Pylons definitely has a large enough community to sustain itself, especially as its rather lean and compact code-base don't pick up nearly as many bugs as the "kitchen sink" frameworks of Zope/Django.

I would say that if you're worried about 'enterprise-level' support, you should be looking more at Django. Although you can debate the relative technical merits of the two frameworks, there's no doubt that Django has the bigger uptake, and there are quite a few large companies using it.
One additional reason is that IBM have (just in the last couple of days) released a Django driver for DB2, so you should have no problem using your existing database with the Django ORM.

define enterprise ready.
Also, if we're talking scalability, I would say you have a better shot with sqlalchemy since you can drop down to raw sql when necessary. Whereas the active Record pattern seems to be the cause of a lot of the value of high level frameworks, that can lead to scalability issues if you are throwing stuff together.
Of course "enterprise ready" to some people means complicated and expensive, is this is your definition, than I would say that no python web framework is going to meet your needs.

I consider a piece of software enterprise ready when it has stability and support.
I believe that Pylons/Python is stable. There are a load of sites using Pylons (including one of the highest traffic'ed sites, reddit.com).
Support wise I'd consider aspects like how easy it is to hire people who know Pylons or to purchase support contracts. This is a bit harder. If you plan to support in house Pylons is more than ready to go. If you are looking for support so that you have someone to take liability when the software breaks you might want to look elsewhere.

I'd second the call to use Django. I actually prefer Pylons, because it is much leaner than Django, but considering you specify "enterprise ready" I think you might want to hedge toward the larger framework and carry the kitchen sink around with you.

+1 for Django
Pylons is a good framework, but you will have to match all the components to create your own architecture, so I think it's more appropriate for leaner projects. For something bigger, I suggest Django, that's know to be on production on some large scale sites.
IBM recently released a DB2 back-end for Django, so might fit you well.

If you want frameworks that aren't likely to go away anytime soon look at Django and one of the frameworks in the Zope community (Grok, BFG, Zope3). Zope has a big community and have been around for more than ten years and isn't going away any time soon, and is a breeding ground for many of the new cool Python web technologies. Django is newer and did only recently come in version 1.0, but it has a very large community and is also going to stay around more or less forever.