5 ms·

Django isn't built to be the main backend for an API, I've previously used Tastypie and it's just not flexible enough, you should really consider using Flask i

by parham 12y ago

Django isn't built to be the main backend for an API, I've previously used Tastypie and it's just not flexible enough, you should really consider using Flask if you're planning to go API first.

mrfusion 12y ago
Why do you think flask is better?
- parham 12y ago
  Well Flask is just the "glue" the real thing I like is its flexibility, which allows you to use tools that fit your needs, which for handling data SQLAlchemy blows Django's ORM out of the water. Don't get me wrong I love Django and I do use it a lot for websites but for handling data... it's restrictive to say the least.
  - mahmoudimus 12y ago
    I am a die hard flask fan. I would highly recommend you look @ Pyramid. Much better for APIs than Flask, especially if it's core to your business.
    - lumpypua 12y ago
      Why do you think pyramid is better?
      - mahmoudimus 12y ago
        Flask's import time side-effects and has global objects everywhere. It's great for a quick hackathon and a great eco-system, though arguably you can just use Pyramid for that. In my experience, growing bigger with Pyramid has been much easier than it has been w/ Flask. We found ourselves writing most of Pyramid using Werkzeug when it would've made sense to start off with Pyramid in the first place. Pyramid's design for extensibility and design decisions are solid and really make a difference if you're building a real app vs a toy app.
        parham 12y ago
        I was wounded in what made VIM flake slow while I was using Flask, I'm guessing it's the amount of modules imported at one go. Thanks for making me aware of Pyramid I will look into it further.
        Svenstaro 12y ago
        Isn't that problem gone if you follow the app factory pattern? Then you only get fairly empty objects during import time.
      - Walkman 12y ago
        You only return a dictionary from Pyramid views and based on the request, you can choose a renderer like JSON. Look at this example[1] Steps 3, line 16-19. Basically you can develop a Rest API with template rendering side-by-side and you don't even need a framework for it like DRF! [1]: http://static.agendaless.com/pycon2014/json.html http://static.agendaless.com/pycon2014/json.html
  - crdoconnor 12y ago
    It doesn't blow Django's ORM out of the water. It provides some extra functionality for doing the more unusual queries using the ORM, but all of those things are achievable in a terse, neat fashion Django by plugging in raw SQL into the gaps. There's no real productivity boost between the two in my experience. Those holes in Django's ORM that need to be plugged by raw SQL aren't all that common anyhow. The VAST majority of SQL queries you will need the Django ORM can handle. In projects I've worked on that don't do weird, strange or bad things with the database (e.g. ignoring foreign keys), the total number of custom, raw SQL queries has been between 5 and 20. Using an ORM for them instead wouldn't have saved more than a couple of lines of code total, if that. What you DO get with Django's ORM that you don't with SQL Alchemy is the benefit of integration with all of the other django tools and modules - that saves you having to write a TON of code.
    - parham 12y ago
      Well it's really hard to sell SQLAlchemy when you have never used it (I'm assuming, correct me if I'm wrong), read this blog for an full comparison http://lucumr.pocoo.org/2011/7/19/sqlachemy-and-you/ http://lucumr.pocoo.org/2011/7/19/sqlachemy-and-you/ (quite old). For the Django part of your comment the other modules it provides are useful for building a website but not an API which was in the root comment. Indeed for a website Django is my preferred tool too. Although in a project where I know the API is the core I would choose something lighter weight (using flask in my current project but learning from comments here Pyramid is something to look into too) and then build the portal in Django, handle user authentication there and allow access to the authenticated users to the API via requests signed in Django or direct access via API keys. In my experience it's the fastest/most flexible approach in terms of dev.
      - crdoconnor 12y ago
        >Well it's really hard to sell SQLAlchemy when you have never used it (I'm assuming, correct me if I'm wrong) Consider yourself corrected. >read this blog for an full comparison http://lucumr.pocoo.org/2011/7/19/sqlachemy-and-you/ http://lucumr.pocoo.org/2011/7/19/sqlachemy-and-you/ (quite old). That's not a full comparison. It actually doesn't even touch on some of the advantages to using SQLAlchemy (i.e. in the more complex queries). It even says this at the bottom. Did you see that? >For the Django part of your comment the other modules it provides are useful for building a website but not an API which was in the root comment. So now APIs don't require integration work? When I build ANYTHING I want to be able to have as large an ecosystem of libraries to pull from as possible because it will save me from writing unnecessary code and reinventing the wheel. First thing I do before building anything is to check on pypi to see if somebody wrote it first. Too many junior developers make the mistake of thinking that their problem, project or app is somehow a unique snowflake and end up reinventing the wheel because they had no idea the wheel existed. Semi-experienced developers will still make this mistake by making bad architectural decisions in the name of flexibility or performance that end up locking them out of library ecosystems that means they are forced to reinvent the wheel even when they know it exists. Being an experienced architect means (among many other things) knowing when to make the trade off between not railroading your code unnecessarily and standardizing it enough to let you use the vast array of free libraries out there. >Although in a project where I know the API is the core I would choose something lighter weight It's a myth that Django is heavy weight. You can make a django app with about 10 lines of code in one file using just the URL router if you really want to. Each one of the components can be swapped out nearly seamlessly exactly like with Flask. You might not want to use it because it's slow, however, but flask will be too.
gtaylor 12y ago
It can be used as the main backend for an API just fine. It's also very easy to override just about every piece of what DRF offers. This is pure, unsubstantiated, subjective FUD. Use the tool that you are most comfortable with, change it up if/when you get big or busy enough to have to. There are some huge sites running Django/DRF successfully.
- parham 12y ago
  Well it really depends on the data you have. It can easily be substantiated, it's like saying I want to compete in F1 let me put the biggest engine in this tanker truck, in other words do you need most of Django's layers for an API? That's why I said if you're "planning to go API first" (Note: I love Django for building sites not APIs)
  - gtaylor 12y ago
    This analogy really isn't useful at all. You aren't ever going to use 100% of every tool your site is built on, and there's no shame in that. If you don't end up using everything that Django does, no big deal. There are some incredibly large sites with rich APIs that run Django very successfully, so I'm thinking that this is all some pretty subjective generalization that is of limited use.

by parham 12y ago

Django isn't built to be the main backend for an API, I've previously used Tastypie and it's just not flexible enough, you should really consider using Flask if you're planning to go API first.

mrfusion 12y ago

Why do you think flask is better?

parham 12y ago
Well Flask is just the "glue" the real thing I like is its flexibility, which allows you to use tools that fit your needs, which for handling data SQLAlchemy blows Django's ORM out of the water. Don't get me wrong I love Django and I do use it a lot for websites but for handling data... it's restrictive to say the least.
- mahmoudimus 12y ago
  I am a die hard flask fan. I would highly recommend you look @ Pyramid. Much better for APIs than Flask, especially if it's core to your business.
  - lumpypua 12y ago
    Why do you think pyramid is better?
    - mahmoudimus 12y ago
      Flask's import time side-effects and has global objects everywhere. It's great for a quick hackathon and a great eco-system, though arguably you can just use Pyramid for that. In my experience, growing bigger with Pyramid has been much easier than it has been w/ Flask. We found ourselves writing most of Pyramid using Werkzeug when it would've made sense to start off with Pyramid in the first place. Pyramid's design for extensibility and design decisions are solid and really make a difference if you're building a real app vs a toy app.
      - parham 12y ago
        I was wounded in what made VIM flake slow while I was using Flask, I'm guessing it's the amount of modules imported at one go. Thanks for making me aware of Pyramid I will look into it further.
      - Svenstaro 12y ago
        Isn't that problem gone if you follow the app factory pattern? Then you only get fairly empty objects during import time.
    - Walkman 12y ago
      You only return a dictionary from Pyramid views and based on the request, you can choose a renderer like JSON. Look at this example[1] Steps 3, line 16-19. Basically you can develop a Rest API with template rendering side-by-side and you don't even need a framework for it like DRF! [1]: http://static.agendaless.com/pycon2014/json.html http://static.agendaless.com/pycon2014/json.html
- crdoconnor 12y ago
  It doesn't blow Django's ORM out of the water. It provides some extra functionality for doing the more unusual queries using the ORM, but all of those things are achievable in a terse, neat fashion Django by plugging in raw SQL into the gaps. There's no real productivity boost between the two in my experience. Those holes in Django's ORM that need to be plugged by raw SQL aren't all that common anyhow. The VAST majority of SQL queries you will need the Django ORM can handle. In projects I've worked on that don't do weird, strange or bad things with the database (e.g. ignoring foreign keys), the total number of custom, raw SQL queries has been between 5 and 20. Using an ORM for them instead wouldn't have saved more than a couple of lines of code total, if that. What you DO get with Django's ORM that you don't with SQL Alchemy is the benefit of integration with all of the other django tools and modules - that saves you having to write a TON of code.
  - parham 12y ago
    Well it's really hard to sell SQLAlchemy when you have never used it (I'm assuming, correct me if I'm wrong), read this blog for an full comparison http://lucumr.pocoo.org/2011/7/19/sqlachemy-and-you/ http://lucumr.pocoo.org/2011/7/19/sqlachemy-and-you/ (quite old). For the Django part of your comment the other modules it provides are useful for building a website but not an API which was in the root comment. Indeed for a website Django is my preferred tool too. Although in a project where I know the API is the core I would choose something lighter weight (using flask in my current project but learning from comments here Pyramid is something to look into too) and then build the portal in Django, handle user authentication there and allow access to the authenticated users to the API via requests signed in Django or direct access via API keys. In my experience it's the fastest/most flexible approach in terms of dev.
    - crdoconnor 12y ago
      >Well it's really hard to sell SQLAlchemy when you have never used it (I'm assuming, correct me if I'm wrong) Consider yourself corrected. >read this blog for an full comparison http://lucumr.pocoo.org/2011/7/19/sqlachemy-and-you/ http://lucumr.pocoo.org/2011/7/19/sqlachemy-and-you/ (quite old). That's not a full comparison. It actually doesn't even touch on some of the advantages to using SQLAlchemy (i.e. in the more complex queries). It even says this at the bottom. Did you see that? >For the Django part of your comment the other modules it provides are useful for building a website but not an API which was in the root comment. So now APIs don't require integration work? When I build ANYTHING I want to be able to have as large an ecosystem of libraries to pull from as possible because it will save me from writing unnecessary code and reinventing the wheel. First thing I do before building anything is to check on pypi to see if somebody wrote it first. Too many junior developers make the mistake of thinking that their problem, project or app is somehow a unique snowflake and end up reinventing the wheel because they had no idea the wheel existed. Semi-experienced developers will still make this mistake by making bad architectural decisions in the name of flexibility or performance that end up locking them out of library ecosystems that means they are forced to reinvent the wheel even when they know it exists. Being an experienced architect means (among many other things) knowing when to make the trade off between not railroading your code unnecessarily and standardizing it enough to let you use the vast array of free libraries out there. >Although in a project where I know the API is the core I would choose something lighter weight It's a myth that Django is heavy weight. You can make a django app with about 10 lines of code in one file using just the URL router if you really want to. Each one of the components can be swapped out nearly seamlessly exactly like with Flask. You might not want to use it because it's slow, however, but flask will be too.

gtaylor 12y ago

It can be used as the main backend for an API just fine. It's also very easy to override just about every piece of what DRF offers. This is pure, unsubstantiated, subjective FUD. Use the tool that you are most comfortable with, change it up if/when you get big or busy enough to have to. There are some huge sites running Django/DRF successfully.

parham 12y ago
Well it really depends on the data you have. It can easily be substantiated, it's like saying I want to compete in F1 let me put the biggest engine in this tanker truck, in other words do you need most of Django's layers for an API? That's why I said if you're "planning to go API first" (Note: I love Django for building sites not APIs)
- gtaylor 12y ago
  This analogy really isn't useful at all. You aren't ever going to use 100% of every tool your site is built on, and there's no shame in that. If you don't end up using everything that Django does, no big deal. There are some incredibly large sites with rich APIs that run Django very successfully, so I'm thinking that this is all some pretty subjective generalization that is of limited use.