django-channels VS fquery

Channels Medium Article

WebSockets or MQTT. If you’re open to Python and Django as a framework, check out Django Channels.

Creating a PWA is not like playing a card that wins the game. Moreover, users do not yet know the potential or do not know that they can be installed so they have a bit of a hard time catching on. At the moment I use Django + HTMX + AlpineJS to build my applications. This stack allows you to use WebSockets, but HTMX is not yet very mature in this respect. If you aim to create something complex on the user experience side, I have used the Django (+ Django rest framework) + React stack for years. It's good but it takes time both for creating things and to master it. Maybe you want to check out Django Channels too https://github.com/django/channels

Use Django channels package. I'm not very convinced for these reasons:

github issue

One program I sorta like is channels. You may have some luck searching for python example repositories (IIRC there is at least one project like this, with the structure and explaining what each stuff does, give preference to more recent projects as packaging is something that went through a lot of changes in the recent years).

Extra background information: * https://stackoverflow.com/a/49043121/1842286 * https://stackoverflow.com/questions/62199335/django-session-is-not-being-persisted-and-cookie-is-not-being-set-when-using-dja * https://github.com/django/channels/issues/1425 * https://github.com/django/channels/issues/1402 * https://github.com/django/channels/issues/1096

Similar benefits without codegen (based on decorator magic) for a python based stack:

https://github.com/adsharma/fquery

* Use dataclasses for both database schema and the user facing operations

Re: Conways law at Facebook

I was at Facebook when GraphQL was invented, maintaining a backend storage service where a core assumption was that storage should be reorganized based on access patterns and that predicates should be pushed down to storage where they can be executed more efficiently.

GraphQL was hard to push predicates down, because you don't know which of the edges were written in PHP.

My response was fquery[1], which is like what's being discussed here but with python as the source language instead of swift and amenable to preserving the largest possible query structure for backend optimizers, including SQL optimizers.

It has some early demos converting a GraphQL/fquery into SQL where possible. It should be possible to add enough metadata to fquery to identify if an edge is non-trivial (calls into another microservice) or trivial (can be optimized to a storage backend or SQL).

[1] https://github.com/adsharma/fquery