Show HN: Nango, a Django extension providing SPA-like features

Show HN: Nango, a Django extension providing SPA-like features(github.com)

20 points by nicois 4 years ago | 5 comments

nicois 4 years ago |

Over recent weeks there have been a few HN posts relating to Django and how it interacts with "modern" ecosystems. Over Christmas I began working on a Django extension which would help leverage some features usually seen only in javascript-heavy websites, without the pain of writing custom code, in investing in browser-heavy automated tests.

The "killer" features I am hoping to bring to the Django community is the ability to have strong data consistency assurances between requests when editing data, as well as realtime server-driven validation of form inputs, alongside optional realtime "autosaving" of fields as changes are made. You can see how this looks here: https://user-images.githubusercontent.com/236562/153730557-a...

I have also attempted to minimise how much an existing codebase needs to be altered to use or test this. No database schema changes are required, and mostly it's just a matter of changing import statements from "django..." to "nango..."

This is very much a proof-of-concept at the moment and certainly not fit for production, and I welcome all suggestions and critiques. A quickstart script is included in the repo which should minimise the pain in running the code locally.

boxed 4 years ago |

Preventing accidental overwriting has been on my todo list for many years. But since it's so very rare in practice I haven't gotten around to it.

Django forms having this problem is, in my opinion, WAY down the list of problems. I originally wrote the forms library in iommi to be able to programmatically create forms in a sane way but it has since evolved to fix many more of the weaknesses of django. Some highlights:

- good rendering of forms to html!

- that can be customized without resorting to writing gigantic amounts of brittle template code

- render form errors

- strip space from inputs by default

- always writes the encoding attr so file uploads work by default instead of silently failing by default

- you don't need to manually pass request.FILES (another silent failure not just beginners get bitten by)

- don't allow misses like duplicate names that causes silent data loss

Plus the iommi features of nesting and having multiple forms/tables/menus/etc on one page with clean composition.

nicois 4 years ago | |

The inter-request integrity guarantee is nice, but you're right that on its own it seems something many devs don't value - or at least don't consider.

The main driver for getting it done is mostly to set the groundwork for the websocket autosave feature, which would be exceeding dangerous without this.

sergiomattei 4 years ago |

I’m curious about how this scales. All my previous experiences with Django Channels, even since 1.0 to 2.0, have faced serious reliability issues and tricky bugs even in small apps.

nicois 4 years ago | |

I can't speak for Channels itself, but I'm quite comfortable that my use of it is not exotic, so is less likely to hit rough edges. The pattern of use I have chosen (having each websocket endpoint subscribe to layer groups based on the model instances the form is using) means it's quite clean.

Remember that this is not a SPA, so websockets are recreated each time a page containing models marked for dynamic updates is served. This means there should be fewer problems associated with long-lived connections, and any instability will have more limited impact.