4 ms·

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://lucum

by 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.
- parham 12y ago
  > 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? Well those are most of the comparisons that could be made, from the top of my head I can't think of any other features that the two share. > 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. Doesn't sticking with Django lock you into the ORM and it's capabilities itself? Unless the library you're using is a Django extension you have the same pool of libraries available to you, so that's an invalid point. > It's a myth that Django is heavy weight. I saw that blog post too, however by heavy weight I meant all the remaining stuff you don't need for an API, e.g. you don't need the template, view, form, ... layers Again my argument is based on building an API not a Website.
  - crdoconnor 12y ago
    >Doesn't sticking with Django lock you into the ORM and it's capabilities itself? Not really. You're always free to use raw SQL, and it makes it pretty convenient to do so for the occasions when what you want exceeds the ORM's capabilities (which will likely happen). >Unless the library you're using is a Django extension you have the same pool of libraries available to you, so that's an invalid point. I was talking about the django extensions. Stuff like a rate limiter, for instance, or a pluggable social media authentication backend. Or the one mentioned by the OP. All useful when making APIs. >I saw that blog post too, however by heavy weight I meant all the remaining stuff you don't need for an API, e.g. you don't need the template, view, form, ... layers You're not railroaded into using any of those things if you don't want to (the same way you are with RoR). All of them are optional and most of them are even swappable without too much effort.
    - parham 12y ago

by parham 12y ago

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.

parham 12y ago
> 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? Well those are most of the comparisons that could be made, from the top of my head I can't think of any other features that the two share. > 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. Doesn't sticking with Django lock you into the ORM and it's capabilities itself? Unless the library you're using is a Django extension you have the same pool of libraries available to you, so that's an invalid point. > It's a myth that Django is heavy weight. I saw that blog post too, however by heavy weight I meant all the remaining stuff you don't need for an API, e.g. you don't need the template, view, form, ... layers Again my argument is based on building an API not a Website.
- crdoconnor 12y ago
  >Doesn't sticking with Django lock you into the ORM and it's capabilities itself? Not really. You're always free to use raw SQL, and it makes it pretty convenient to do so for the occasions when what you want exceeds the ORM's capabilities (which will likely happen). >Unless the library you're using is a Django extension you have the same pool of libraries available to you, so that's an invalid point. I was talking about the django extensions. Stuff like a rate limiter, for instance, or a pluggable social media authentication backend. Or the one mentioned by the OP. All useful when making APIs. >I saw that blog post too, however by heavy weight I meant all the remaining stuff you don't need for an API, e.g. you don't need the template, view, form, ... layers You're not railroaded into using any of those things if you don't want to (the same way you are with RoR). All of them are optional and most of them are even swappable without too much effort.
  - parham 12y ago