FastUI: Build Better UIs Faster • Hacker News Board

Re: FastUI: Build Better UIs Faster

#221

Post by boxed » Mon, Mar 04, 2024, 8:09 AM UTC

Timwi wrote: post #210

boxed wrote: post #189

Earlier quoted context omitted.

The N+1 problem is solved in iommi (again, I am one of the authors) by simply: 1. keeping a log of queries per request with stack traces 2. at the end, checking if there are N+1 problems 3. print a big warning with example SQL and stack trace to the console During dev if I miss a prefetch_related/select_related the console will start to print gigantic stack traces telling me where the problem is. I don't have these p…

Can you explain what an N+1 problem is?

Example:

You grab all Albums. Then you make a table of the albums with name and artist name. The artist name is in a separate table linked with a foreign key.

So the code might be:

    for album in Album.objects.all():
        print(album.name, album.artist.name)

Django will need to query from the foreign key ID (album.artist_id) into the Artist table to get the name of the artist. This means every loop step does a query.

So "N+1" because it's N queries (every album) plus 1 (the original "all albums" query).

The fix in Django is to do `Album.objects.all().select_related('artist')`. Then there will be just one query.

Re: FastUI: Build Better UIs Faster

#222

Post by boxed » Mon, Mar 04, 2024, 8:11 AM UTC

skyde wrote: post #200

mvdtnz wrote: post #184

Earlier quoted context omitted.

I'm very familiar with Linq and Linq to SQL. It's as close as any ORM got to being "good enough" and was abandoned by Microsoft very early in its lifecycle. Linq in Entity Framework is a minefield of N+1's and excessive eager loading.

In EF line expression you can easily specify which navigation should be Eager loaded. var customersWithOrderDetail = context.Customers.Include("Orders").ToList(); Would generate : SELECT * FROM Customers JOIN Orders ON Customers.Id = Orders.CustomerId

Imo the issue isn't that it's hard or easy to fix. The issue is that you might not be aware that you need to fix it.

The awareness is the key imo. That's what iommi's tool gives you out of the box.

Re: FastUI: Build Better UIs Faster

#223

Post by LtWorf » Mon, Mar 04, 2024, 5:29 PM UTC

asyx wrote: post #219

LtWorf wrote: post #192

Earlier quoted context omitted.

But is it fast?

Fast enough. You get enough tools to optimize the queries. Keep in mind that Django is still a web framework. You can go nuts with Django and it starts to feel like maybe raw SQL would have been easier but I've rarely encountered this.

In a previous job we were using some ORM for mongodb and writing queries by hand gave massive speed gains.

Re: FastUI: Build Better UIs Faster

#224

Post by 4m1rk » Mon, Mar 04, 2024, 11:00 PM UTC

ic_fly2 wrote: post #110

Call me old fashjioned but what is wrong with django and htmx? Works beautifully and fast, send only rendered code to the front. Have db admin for when you scale

Actually, FastUI is repeating the same thing. It's cool but don't we get the same thing if we return HTML instead of JSON, combined with HTMX? We rely on the browser and battle-tested Django forms. No need to invent the wheel.

Re: FastUI: Build Better UIs Faster

#225

Post by ilirium » Tue, Mar 05, 2024, 12:15 PM UTC

Once upon a time there was Google Web Toolkit (GWT), ASP.NET WebForms. What approach do they use, the same as FastUI? Now there is Blazor for C#, how does its approach differ from FastUI? I think they all promise to write UI for Web without writing JavaScript code.

Re: FastUI: Build Better UIs Faster

#226

Post by hansvm » Wed, Mar 06, 2024, 3:51 AM UTC

LtWorf wrote: post #206

hansvm wrote: post #202

Earlier quoted context omitted.

That's mostly false for a nontrivial fraction of queries in most bigger projects. If your queries are doing sane things (not regularly full table scanning for each customer, ...), little things like datetime conversions as the rows are instantiated in Python easily dwarf the cost of the database (depending on your networking setup and exact queries, perhaps just in throughput instead of latency, but Python will the s…

To convert some dates? Really? Have you benchmarked this?

Yes!! I recently found a 12% overall latency win (_much_ higher in just the datetime code I changed) at $WORK replacing some of the native datetime conversions with something more intelligent, tailored to the specific context at hand.

Re: FastUI: Build Better UIs Faster

#227

Post by AlchemistCamp » Wed, Mar 06, 2024, 5:59 PM UTC

pjerem wrote: post #205

AlchemistCamp wrote: post #127

Earlier quoted context omitted.

I don't like Django as much as Phoenix (or Rails for that matter), but I'd take it over a Node-based backend any day of the week.

Phoenix looks really cool too but I’d have to learn Elixir and while that’s something I want to do (already started some years ago), my main prerequisite for this project was not to struggle and going comfy. Building something out of my hand with no roadblocks was more important to me than to learn something new.

It's a very simple language. I've worked on half a dozen projects where I helped an experienced dev new to Elixir ramp up to 80%-90% productivity within a few days.

Learning Phoenix (and a few other libraries like Ecto and now LiveView) is what would eat up your time.

Phoenix used to be very easy for Rails/Django/Laravel devs to pick up a few years ago, but now that LiveView is thoroughly built-in and Phoenix.View has been replaced by Phoenix.Component, it's much less familiar to those learners.

Re: FastUI: Build Better UIs Faster

#228

Post by xtagon » Thu, Mar 07, 2024, 4:14 AM UTC

ipaddr wrote: post #49

xtagon wrote: post #39

Earlier quoted context omitted.

Interestingly, you could accomplish a similar thing with GraphQL if the frontend uses the type introspection GraphQL provides and the backend graphql schema implements HATEOAS-like principles to let the frontend become a UI that's agnostic to different backends. That might not be how most GraphQL implementations are used, but it's kind of a cool pattern.

The kind of site that gets all of their data stolen. It can be a cool pattern.

The types are no less protectable by authorization policies than the data, although authorization is hard to get right anyways, all else the same this architecture doesn't worsen it much--perhaps just less reverse engineering required to exploit vulnerabilities you already had.

Re: FastUI: Build Better UIs Faster

#229

Post by denterosso » Thu, Mar 07, 2024, 10:12 AM UTC

It's like GWT for Python. Is that a fair assessment, you'd say?

Re: FastUI: Build Better UIs Faster

#230

Post by nsteel » Wed, Mar 13, 2024, 1:05 PM UTC

For me, the main technical difference with Pydantic over the host of other similar libs is runtime validation. Which, with modern typed Python, you often don't need and which you pay for in speed: even Pydantic v2 is still relatively slow.

"Pydantic models for UI components" seems odd to me. Surely runtime validation is unnecessary in this application and static analysis is a better fit. I am guessing it's the close integration with FastAPI that really holds the value here. For me, ideally this wouldn't use Pydantic but given the author and their situation, using Pydantic is probably the main reason this project actually exists.