4 ms·

Just started building my SaaS startup with Python (FastAPI, Pydantic, postgres). Any tips on alternative stacks if they can massively impact productivity?

by exdsq 5y ago

marton78 5y ago
I've had great experience with Postgraphile. It creates a GraphQL API by inspecting your Postgres database schema.
travisjungroth 5y ago
The biggest productivity impact is not switching frameworks. That out of the way, Django is the OG batteries included (DRF is top API choice), Flask is the OG micro-framework, FastAPI is the new hotness, Starlette is in FastAPI (and maybe better?), Pyramid has some cool ideas, and then there are more that I can't say anything on (Bottle, Falcon, Sanic, Hug).
- holler 5y ago
  I'm using Starlette on it's own, with a few other deps likes Marshmallow, and it's been enjoyable and hassle-free. In the past I've done significant django/flask/DRF work and really feel like Starlette is the successor of all of them.
  - tomwojcik 5y ago
    I'm under the impression there's only a handful of people who use Starlette/FastAPI AND have a proper experience with DRF. I'm on a similar boat, I have experience with Django/Flask/DRF and was thinking about starting a project with Starlette (I used it before and I prefer it over FastAPI) but I've decided to continue my DRF journey. Would you mind sharing why, in your opinion, Starlette might be the successor of DRF?
    - holler 5y ago
      I would say my favorite things about Starlette are: - refined - it feels like all the lessons from DRF were put into Starlette. - lightweight - minimal dependencies, isn't built specifically for relational data (no orm or other constructs from django that were originally built around models etc) - flexible - has just enough to build the basics without being too opinionated (app/request/response), let's you choose how to handle things like serialization (e.g. add marshmallow) - documentation - like DRF, has very solid documentation. - asgi - the successor to wsgi in many ways, allows things like background tasks so I don't need to set up celery. - authentication/middleware - easy to set up and customize, again clear documentation and api surface There's probably more, such as it support for websockets, push, and more, but for me I'm just running a standard http api (sqwok.im).
      - tomwojcik 5y ago
        Thanks for your response. I guess that's the point, I prefer more opinionated framework with it's own ORM. And I can't say I'm a fan of async. I'd say Starlette will be the successor of Flask.
        holler 5y ago
        totally, if you'd like to hear more about it feel free to reach out.. I'm happy with the pattern I'm using and it feels pretty extensible.
- exdsq 5y ago
  > The biggest productivity impact is not switching frameworks Totally agree but I'm 2/3 days in with 500 loc - it's worth rebooting if there's something seriously good out there!
  - travisjungroth 5y ago
    Okay, that’s totally valid lol
davidkell 5y ago
We recently started working with "traditional" Django + Hotwire + React wrapped into web components for interactivity. We've previously tried React+Hasura/Postgraphile and React+DRF/GraphQL, but this is next level productive and a joy to use, and bugs are rare. Particular love for Django CBVs.
- cutler 5y ago
  Hotwire + React? Hotwire was built as an alternative to SPAs/React.
spamizbad 5y ago
Assuming you are a Python developer: That's a great stack. I work at a recently minted unicorn and that's what a big chunk of our service layer is written in. Only caveat is that it's not as opinionated as Django, so you'll need to document some rules as to how you structure your code. For what it's worth, this article gives some good advice you can apply. Best productivity hack I can recommend is that it's worth investing time into observability once you reach product/market fit: you will slowly have to invest more labor into troubleshooting your application rather than merely adding more product features. And depending on your market, some customers might be very sensitive to that.

Just started building my SaaS startup with Python (FastAPI, Pydantic, postgres). Any tips on alternative stacks if they can massively impact productivity?

by exdsq 5y ago

Just started building my SaaS startup with Python (FastAPI, Pydantic, postgres). Any tips on alternative stacks if they can massively impact productivity?

marton78 5y ago

I've had great experience with Postgraphile. It creates a GraphQL API by inspecting your Postgres database schema.

travisjungroth 5y ago

The biggest productivity impact is not switching frameworks. That out of the way, Django is the OG batteries included (DRF is top API choice), Flask is the OG micro-framework, FastAPI is the new hotness, Starlette is in FastAPI (and maybe better?), Pyramid has some cool ideas, and then there are more that I can't say anything on (Bottle, Falcon, Sanic, Hug).

holler 5y ago
I'm using Starlette on it's own, with a few other deps likes Marshmallow, and it's been enjoyable and hassle-free. In the past I've done significant django/flask/DRF work and really feel like Starlette is the successor of all of them.
- tomwojcik 5y ago
  I'm under the impression there's only a handful of people who use Starlette/FastAPI AND have a proper experience with DRF. I'm on a similar boat, I have experience with Django/Flask/DRF and was thinking about starting a project with Starlette (I used it before and I prefer it over FastAPI) but I've decided to continue my DRF journey. Would you mind sharing why, in your opinion, Starlette might be the successor of DRF?
  - holler 5y ago
    I would say my favorite things about Starlette are: - refined - it feels like all the lessons from DRF were put into Starlette. - lightweight - minimal dependencies, isn't built specifically for relational data (no orm or other constructs from django that were originally built around models etc) - flexible - has just enough to build the basics without being too opinionated (app/request/response), let's you choose how to handle things like serialization (e.g. add marshmallow) - documentation - like DRF, has very solid documentation. - asgi - the successor to wsgi in many ways, allows things like background tasks so I don't need to set up celery. - authentication/middleware - easy to set up and customize, again clear documentation and api surface There's probably more, such as it support for websockets, push, and more, but for me I'm just running a standard http api (sqwok.im).
    - tomwojcik 5y ago
      Thanks for your response. I guess that's the point, I prefer more opinionated framework with it's own ORM. And I can't say I'm a fan of async. I'd say Starlette will be the successor of Flask.
      - holler 5y ago
        totally, if you'd like to hear more about it feel free to reach out.. I'm happy with the pattern I'm using and it feels pretty extensible.
exdsq 5y ago
> The biggest productivity impact is not switching frameworks Totally agree but I'm 2/3 days in with 500 loc - it's worth rebooting if there's something seriously good out there!
- travisjungroth 5y ago
  Okay, that’s totally valid lol

davidkell 5y ago

We recently started working with "traditional" Django + Hotwire + React wrapped into web components for interactivity. We've previously tried React+Hasura/Postgraphile and React+DRF/GraphQL, but this is next level productive and a joy to use, and bugs are rare. Particular love for Django CBVs.

cutler 5y ago
Hotwire + React? Hotwire was built as an alternative to SPAs/React.

spamizbad 5y ago

Assuming you are a Python developer: That's a great stack. I work at a recently minted unicorn and that's what a big chunk of our service layer is written in. Only caveat is that it's not as opinionated as Django, so you'll need to document some rules as to how you structure your code. For what it's worth, this article gives some good advice you can apply. Best productivity hack I can recommend is that it's worth investing time into observability once you reach product/market fit: you will slowly have to invest more labor into troubleshooting your application rather than merely adding more product features. And depending on your market, some customers might be very sensitive to that.