rsinger87

Storing arbitrarily complex Boolean queries (think Elasticsearch's query syntqx). While this could be done in SQL tables, there are no gains with referential intregity and while there would be some in consistency, I don't think they're worth it.

I made a webapp called "Disqors" (https://www.disqors.com/latest). It's backend largely runs on Django.

I connect online articles into discussion graphs and intersperse the top tweets about them. There are feeds that filter the discussions in different ways (exchanges among top authors, most discussed articles). It's also possible to see a specific discussion graph in its entirety, e.g. the discussion around Marc Andreessen's "It's Time to Build" essay: https://www.disqors.com/discussions/36672

Hi, I wanted to share a web app I made to keep up to date on the most interesting discussions among political/social/economic commentators.

I connect online articles into discussion graphs and intersperse the top tweets about them. There are feeds that filter the discussions in different ways (exchanges among top authors, most discussed articles).

It's also possible to see a specific discussion graph in its entirety, e.g. the discussion around Marc Andreessen's "It's Time to Build" essay: https://www.disqors.com/discussions/36672

Any feedback is appreciated!

There is a package for DRF that adds automatic validation from type annotations: https://github.com/rsinger86/drf-typed-views (disclaimer: I'm the author)

Regarding other commentary on DRF: I wonder how many pain points result from trying to squeeze non-CRUD operations into DRF's ModelViewSet/ModelSerializer constructs? My company's approach has been to use that DRF magic for dumb CRUD resources and use plain function-based views for everything else, with the freedom to use Pydantic/Marshmallow/etc. This has made us very productive and I can't image having to write create/update/delete/get/list operations one at a time.

That said, I'm sure there are use cases that DRF isn't suited for and I would definitely look at FastAPI for new projects.

Huge thanks Angular team. A few years ago, my team desperately needed to pick and run with a frontend framework. After a couple months to learn the Angular fundamentals, we haven't looked back. We find the framework to be extremely intuitive and flexible enough to handle any scenario we've encountered. The productivity wins have been enormous. We have about a dozen apps and anyone on our small team can jump into any project and contribute. I can't imagine how fractured our knowledge would be if we had to stitch together multiple libraries and come up with our own constructs.

Postgres, Django (with Rest Framework) and TypeScript/Angular.

I wrote a package that allows use of type annotations for validation/serialization in Django Rest Framework: https://github.com/rsinger86/drf-typed-views

(Partly inspired by FastAPI)

Django Rest Framework, Postgresql and Redis. RQ for background jobs.

Very cool! Yeah, it seems like web frameworks could do more in terms of linking up HTTP contracts with the arguments to the controller/view/whatever. Though, sometimes you need a little more flexibility. For instance, often when updating an existing model, the validation depends not just on the incoming request data but also the value of the existing instance's fields.

I've followed GraphQL from a distance. Besides the typing part (which it seems like you can get from OpenAPI to some extent), the other big benefit seems to be being able to cater to many different and unpredictable use cases. But I haven't really had a need for that yet.

Cool, I've added the "Show HN:" prefix. Yeah, probably most useful for API view functions, since ViewSets often handle the CRUD endpoints automatically.

I wanted wanted to share a package I made to enable use of type annotations for automatic validation/sanitization in Django REST Framework.

I've borrowed ideas from the original API Star (https://github.com/encode/apistar) (before it was an OpenAPI toolkit) and FastAPI (https://fastapi.tiangolo.com/). Instagram engineering also had a recent blog post about how they do something similar with Django views (https://instagram-engineering.com/types-for-python-http-apis...).

I wrote this package to provide model lifecycle hooks (similar to Rails callbacks) because I didn't like the frequency that my codebase was overriding __init__(): https://github.com/rsinger86/django-lifecycle

Django's ecosystem (mainly DRF and django-filters) makes it very productive for me, but I find Django core to be lacking for developer ergonomics in certain areas.

I wanted to share a Django REST package for permissions/access control: https://github.com/rsinger86/drf-access-policy

There are some other great packages out there for permissions, but I wanted one that allowed defining access rules in a declarative, JSON syntax, similar to AWS IAM. I also wanted all access control logic for a given resource, or set of resources, to be in a single place.

I hope this will be useful for other Django Rest Framework users and I welcome any feedback.

I second this. Expose your backend with DRF (https://www.django-rest-framework.org/). Once you get over initial learning curve, you'll have an extremely powerful and flexible library for building your backend.

Cool :)

Yeah, my team hasn't found many cases where signals are preferable to overridding save(). The implementation of @hook is really just a wrapper around that approach - with the aim of a friendly, declarative interface.

Hey all -

Just wanted to share a little package I made to add lifecycle event hooks to Django models. I often find this style of hooking into events easier to reason about than Django's built-in Signals.

Feedback is welcomed and appreciated.

Django with Django REST Framework. Postgres for DB, Redis for caching. RQ/Django RQ for background tasks. OpenAPI for API documentation.