5 ms·

This is an excellent article, and SaaS Pegasus is a great solution for people starting a project. But some of the advice here is dated. The architectural patte

This is an excellent article, and SaaS Pegasus is a great solution for people starting a project. But some of the advice here is dated. The architectural patterns are still valid, but the specifics have changed: * Vite instead of create-react-app (which is unmaintained now) / webpack / babel / Parcel / etc. * Django-ninja as a lightweight API service. I think these are important to call out because they really simplify the frontend compared to the previous options.

bkovacev 2y ago
What seems to differentiate django-ninja over Flask or FastAPI or any Starlette derivative? You mention lightweight as well, can you expand further?
- nprateem 2y ago
  Ninja lets you use django. There's less config vs DRF
  - bkovacev 2y ago
    Aside from the obvious that ninja let's you use django.
    - WD-42 2y ago
      The ability to use django is the main attractor. The other frameworks are great but make you reinvent Django if you require auth, orm, admin, etc
      - globular-toast 2y ago
        Oh but you wouldn't reinvent Django, you'd build a properly architected, simple system.
        WD-42 2y ago
        Of course you would.
      - bkovacev 2y ago
        That would have been my argument exactly - I am not saying that Django fits every use case, but with my limited exposure to projects that have ended up using non-Django Python API framework, they ended up recreating the batteries included approach, with probably way too many issues waiting to be discovered with manually rolled out auth, middlewares and ORM.
        globular-toast 2y ago
        It's such a shame Pyramid isn't more popular. I think you'll find what they have recreated is not Django, it's Pyramid. The thing is, Django isn't just a web framework. Django is a CRUD app framework. It's great for building CRUD apps, but that's about it. In other words, it makes the easy stuff easy, but doesn't help with the hard stuff (in fact, it often hinders it). I think the real reason for using Django is the "app" ecosystem. You wouldn't be able to get Django-style packages with Pyramid. It's possible with Django, though, because it's a CRUD app framework. If you're not using "apps" then I guess the only other reason is the community support that you probably won't get from Pyramid + SQLAlchemy or similar.
        nprateem 2y ago
        The apps are a major sell like with any ecosystem. But don't forget you also get a stable, mature project, excellent documentation, a pool of developers, etc.
        globular-toast 2y ago
        > But don't forget you also get a stable, mature project, excellent documentation, a pool of developers, etc. You get all of that with any of Pyramid, Flask, FastAPI etc. As for "pool of developers", I would expect any backend web developer to be able to pick up anything in a couple of days at most.
        nprateem 2y ago
        > You get all of that with any of Pyramid, Flask, FastAPI etc. Yes, with fewer batteries, and so less consistency between projects, etc. > As for "pool of developers", I would expect any backend web developer to be able to pick up anything in a couple of days at most. Not some half-baked homegrown ORM, etc. Been there, seen it fail.
- deleted 2y ago
  [deleted]
blopker 2y ago
I agree with you on Django Ninja, so refreshingly simple compared to DRF. I think Django core needs to adopt something like it. However, Vite is pretty complicated. I prefer just esbuild if I don't need all the extra features of Vite, which is usually true with Django. I wrote a post[0] with an example repo[1] if anyone wants to see how everything wires up. With Solidjs, the minimum JS payload is around 9kb, and you get access to the whole JS ecosystem if you want it. [0] https://blopker.com/writing/07-django-islands-part-1/ https://blopker.com/writing/07-django-islands-part-1/ [1] https://github.com/blopker/typesafedjango https://github.com/blopker/typesafedjango
- michaelcampbell 2y ago
  > I agree with you on Django Ninja, so refreshingly simple compared to DRF. I think Django core needs to adopt something like it. I was going to ask about this with respect to DRF, but you answered it. I am re-learning Django after having been away from it and Python for ~4 years now, and my previous experience was with DRF in a somewhat toxic group so I had less than ideal feelings about it. I know PTSD is a real thing and I don't mean to sound glib about it, but I think I actually had the beginnings of it from that experience.
Capricorn2481 2y ago
I use both at work. I'm not sure I see any reason why you would use Vite over Webpack, other then a sense that Vite is newer. Is there a reason? They both seem perfectly fine but Webpack is mature with lots of support.
- hu3 2y ago
  Isn't Vite faster and less complex? That's my impression.
- MrJohz 2y ago
  All the different configuration you need for Webpack is built-in to Vite. This includes built-in support for a lot of stuff that would come as separate plugins in Webpack (CSS loading, Typescript support, asset bundling, minification, autoprefix/browserslist-based downleveling, env replacement, etc). But more importantly, it includes fairly optimal configuration. There's usually an optimal way to bundle your code, and one of the issues with Webpack was that finding that optimal way through a maze of documentation and third-party plugins. Vite does that work for you, because it's mostly a solved problem and it's not that hard. For example, rather than having a number of different CSS plugins that you need to enable and disable in different configurations — just use Vite, which will do hot-reloading of CSS in development and link to the CSS files as external files in production. In my experience, there are typically two types of Webpack configurations: fairly basic ones that include some essentials but are fairly unoptimised (either while developing or in production), or complex ones that include everything but are brittle and painful to update. Vite gives you the power and optimisation of the latter with the configuration ease of the former. Also, to be clear, I'm not trying to hype Vite up. There are other similar tools out there, and Vite isn't even the first tool to work like this — Parcel is older and also pretty good at doing zero/minimal-config builds that work how you expect out-of-the-box. Any of these tools are good, although Vite seems to be the most popular right now and so has the most support/documentation/information. But I would generally encourage any project using Webpack to migrate away from that where possible (and where time allows), because these low-config tools are such a timesaver in the long-run.
  - diggan 2y ago
scrollaway 2y ago
Adding to the pile that agrees with you on django-ninja. It's also worth noting that what Django brings to the table is getting less and less relevant in a world where frontend and backend are split. For example, we use django-ninja. As we started using it, we migrated away from allauth and into authlib for authentication, which doesn't have a tie-in to Django. We don't use templates, which means we don't use forms. We're moving away from external django apps because they consistently need to be extended, so we tend to copy the code into our codebase and extend directly. The settings are untyped, which is a PITA; so we replaced them with pydantic-settings: That allows us to use .env files, type them, and we just expose them in settings.py into globals() through a couple lines of code. Our management scripts make more sense as poetry script, so we don't go through manage.py but instead `poetry run <command>`, which is more standardized and doesn't depend on Django. We don't even use the django dev server: In order to be more consistent between production and development, we're using uvicorn in "development" mode as a dev server which works just as well. `poetry run dev` is how we run it. So what does that leave us with? 1. An ORM/data model definition system, which is mostly untyped and the source of many of our issues. This model system also contains weird quirks that have nothing to do with the sql model itself (for example you can't create a UUID field whose default is generated by the db; only in python). This also includes a pretty solid migrations system. 2. The great admin dashboard, which depends on the former. I see the way the wind is blowing. And for #1, we have this now, which we haven't tested yet but makes complete sense: https://sqlmodel.tiangolo.com/ https://sqlmodel.tiangolo.com/ We still need migrations and and admin dashboard. Once we have those, we will likely migrate away from Django entirely and our stack will look like a few prepackaged bits of FastAPI, SQLModel, authlib, and maybe some standardized db tables.
- halfcat 2y ago
  So you’re living out the trope of reinventing Django but lower quality :-) Maybe ask around about SQLModel. It sounds like the perfect solution, but I’ve never encountered someone that used it and didn’t have the opinion that it isn’t ready for production.
  - scrollaway 2y ago

bkovacev 2y ago

What seems to differentiate django-ninja over Flask or FastAPI or any Starlette derivative? You mention lightweight as well, can you expand further?

nprateem 2y ago
Ninja lets you use django. There's less config vs DRF
- bkovacev 2y ago
  Aside from the obvious that ninja let's you use django.
  - WD-42 2y ago
    The ability to use django is the main attractor. The other frameworks are great but make you reinvent Django if you require auth, orm, admin, etc
    - globular-toast 2y ago
      Oh but you wouldn't reinvent Django, you'd build a properly architected, simple system.
      - WD-42 2y ago
        Of course you would.
    - bkovacev 2y ago
      That would have been my argument exactly - I am not saying that Django fits every use case, but with my limited exposure to projects that have ended up using non-Django Python API framework, they ended up recreating the batteries included approach, with probably way too many issues waiting to be discovered with manually rolled out auth, middlewares and ORM.
      - globular-toast 2y ago
        It's such a shame Pyramid isn't more popular. I think you'll find what they have recreated is not Django, it's Pyramid. The thing is, Django isn't just a web framework. Django is a CRUD app framework. It's great for building CRUD apps, but that's about it. In other words, it makes the easy stuff easy, but doesn't help with the hard stuff (in fact, it often hinders it). I think the real reason for using Django is the "app" ecosystem. You wouldn't be able to get Django-style packages with Pyramid. It's possible with Django, though, because it's a CRUD app framework. If you're not using "apps" then I guess the only other reason is the community support that you probably won't get from Pyramid + SQLAlchemy or similar.
        nprateem 2y ago
        The apps are a major sell like with any ecosystem. But don't forget you also get a stable, mature project, excellent documentation, a pool of developers, etc.
        globular-toast 2y ago
        > But don't forget you also get a stable, mature project, excellent documentation, a pool of developers, etc. You get all of that with any of Pyramid, Flask, FastAPI etc. As for "pool of developers", I would expect any backend web developer to be able to pick up anything in a couple of days at most.
        nprateem 2y ago
        > You get all of that with any of Pyramid, Flask, FastAPI etc. Yes, with fewer batteries, and so less consistency between projects, etc. > As for "pool of developers", I would expect any backend web developer to be able to pick up anything in a couple of days at most. Not some half-baked homegrown ORM, etc. Been there, seen it fail.
deleted 2y ago
[deleted]

blopker 2y ago

I agree with you on Django Ninja, so refreshingly simple compared to DRF. I think Django core needs to adopt something like it. However, Vite is pretty complicated. I prefer just esbuild if I don't need all the extra features of Vite, which is usually true with Django. I wrote a post[0] with an example repo[1] if anyone wants to see how everything wires up. With Solidjs, the minimum JS payload is around 9kb, and you get access to the whole JS ecosystem if you want it. [0] https://blopker.com/writing/07-django-islands-part-1/ https://blopker.com/writing/07-django-islands-part-1/ [1] https://github.com/blopker/typesafedjango https://github.com/blopker/typesafedjango

michaelcampbell 2y ago
> I agree with you on Django Ninja, so refreshingly simple compared to DRF. I think Django core needs to adopt something like it. I was going to ask about this with respect to DRF, but you answered it. I am re-learning Django after having been away from it and Python for ~4 years now, and my previous experience was with DRF in a somewhat toxic group so I had less than ideal feelings about it. I know PTSD is a real thing and I don't mean to sound glib about it, but I think I actually had the beginnings of it from that experience.

Capricorn2481 2y ago

I use both at work. I'm not sure I see any reason why you would use Vite over Webpack, other then a sense that Vite is newer. Is there a reason? They both seem perfectly fine but Webpack is mature with lots of support.

hu3 2y ago
Isn't Vite faster and less complex? That's my impression.
MrJohz 2y ago
All the different configuration you need for Webpack is built-in to Vite. This includes built-in support for a lot of stuff that would come as separate plugins in Webpack (CSS loading, Typescript support, asset bundling, minification, autoprefix/browserslist-based downleveling, env replacement, etc). But more importantly, it includes fairly optimal configuration. There's usually an optimal way to bundle your code, and one of the issues with Webpack was that finding that optimal way through a maze of documentation and third-party plugins. Vite does that work for you, because it's mostly a solved problem and it's not that hard. For example, rather than having a number of different CSS plugins that you need to enable and disable in different configurations — just use Vite, which will do hot-reloading of CSS in development and link to the CSS files as external files in production. In my experience, there are typically two types of Webpack configurations: fairly basic ones that include some essentials but are fairly unoptimised (either while developing or in production), or complex ones that include everything but are brittle and painful to update. Vite gives you the power and optimisation of the latter with the configuration ease of the former. Also, to be clear, I'm not trying to hype Vite up. There are other similar tools out there, and Vite isn't even the first tool to work like this — Parcel is older and also pretty good at doing zero/minimal-config builds that work how you expect out-of-the-box. Any of these tools are good, although Vite seems to be the most popular right now and so has the most support/documentation/information. But I would generally encourage any project using Webpack to migrate away from that where possible (and where time allows), because these low-config tools are such a timesaver in the long-run.
- diggan 2y ago

scrollaway 2y ago

Adding to the pile that agrees with you on django-ninja. It's also worth noting that what Django brings to the table is getting less and less relevant in a world where frontend and backend are split. For example, we use django-ninja. As we started using it, we migrated away from allauth and into authlib for authentication, which doesn't have a tie-in to Django. We don't use templates, which means we don't use forms. We're moving away from external django apps because they consistently need to be extended, so we tend to copy the code into our codebase and extend directly. The settings are untyped, which is a PITA; so we replaced them with pydantic-settings: That allows us to use .env files, type them, and we just expose them in settings.py into globals() through a couple lines of code. Our management scripts make more sense as poetry script, so we don't go through manage.py but instead `poetry run <command>`, which is more standardized and doesn't depend on Django. We don't even use the django dev server: In order to be more consistent between production and development, we're using uvicorn in "development" mode as a dev server which works just as well. `poetry run dev` is how we run it. So what does that leave us with? 1. An ORM/data model definition system, which is mostly untyped and the source of many of our issues. This model system also contains weird quirks that have nothing to do with the sql model itself (for example you can't create a UUID field whose default is generated by the db; only in python). This also includes a pretty solid migrations system. 2. The great admin dashboard, which depends on the former. I see the way the wind is blowing. And for #1, we have this now, which we haven't tested yet but makes complete sense: https://sqlmodel.tiangolo.com/ https://sqlmodel.tiangolo.com/ We still need migrations and and admin dashboard. Once we have those, we will likely migrate away from Django entirely and our stack will look like a few prepackaged bits of FastAPI, SQLModel, authlib, and maybe some standardized db tables.

halfcat 2y ago
So you’re living out the trope of reinventing Django but lower quality :-) Maybe ask around about SQLModel. It sounds like the perfect solution, but I’ve never encountered someone that used it and didn’t have the opinion that it isn’t ready for production.
- scrollaway 2y ago