Is this finding the Customers that have purchased tracks that start with “c”?

Ah yep, it is…

I was thinking of the case where you have a specific customer node and want to
go from that customer to all their purchased tracks that start with “c”.

Oh sure. Yes, if doing await customer.populate({ invoices: { lineItems: "tracks" } }) and then doing gets/maps/flatMaps against the in-memory data structures, then, yes, it will load all ~3-4 levels into memory with one-per-level SQL queries. This is generally a very idiomatic pattern for us/Joist, and so far one-query-per-level vs. the obviously worse N+1 has been enough of an optimization for us.

That said, we also have lens-based path navigation, which is closer to what you mentioned, like:

const tracks = await customer.load(c => c.invoices.lines.tracks);

But currently they don’t support conditions (something like lines.tracks.if(t => t.name.startsWith(...))), but we can do the hops via just SQL (so hoisting, if I’m following your terminology–that code is the lensDataLoader from my previous comment), however the SQL-joined based “fast path” is behind an opt-in flag, like:

const tracks = await customer.load(c => c.invoices.lines.tracks, { sql: true });

The rationale is that traditionally Joist prioritizes a consistent view of any WIP changes in the unit-of-work/loaded graph, so if we were to execute ^ as SQL by default, then tracks might be missing Tracks that have WIP mutations to an InvoiceLineItem, or a newly created Invoice that has lines + tracks that would also match the condition, but are not yet flushed to SQL for the SQL join to find them.

So, I wrote the { sql: true } flag as a proof-of-concept optimization for our path navigation, but we have so much business logic in our app that relies on this “consistent view of WIP changes” assumption/principle, that we’re generally scared/hesitant to actually use the SQL-only feature, except in opt-in cases where we know there are no WIPs.

…granted, we have all the info to detect whether any Track.invoiceLine or InvoiceLine.invoice Fks have been mutated during this UOW, so we could potentially execute the fast-path method if we know for sure there are no WIP changes that affect that path.

Even then, we’d discussed this, but were nervous about the non-obvious performance difference from the same exact code, i.e. it opaquely changing from “faster” to “slower” because of out-of-sight WIP changes in the UOW.

But, perhaps we’re being too cautious…

The idea is that a SourceExpression consumes all the steps of a query it encounters

Ah! That’s interesting. We originally coupled our find/query DSL directly to a SQL query library (Knex), but eventually put an AST between the two, and that has been great + driven a lot of features that previously would have been a PITA (the big win being auto-batching of SELECT queries issued in a loop).

We’ve not yet gone to non-SQL backends, and honestly probably will not–I do really share the insight/opinion that the domain/entity model is a graph, and so business logic/graph traversal logic can be pleasantly uncoupled from the backend SQL/NoSQL/InMemory/etc.

But, that said, nearly all of Joist has been driven by day-to-day needs at the day job, where the pragmatism of “meh we’ll just assume postgres” (not just assume SQL :-)) has been an admittedly lazy but very pleasant simplification.

relate all your data, even across data stores.

Ooh! Yeah, that is fancy, and tempting… Because, yes, a lot of Joist’s principles (declarative business logic, cross-entity validation rules, etc.) are today implemented with a “just use a monolith and it’ll be fine” assumption/naivety, but the holy grail, for me, is, yes, applying the same principles across an enterprise’s entire domain model–which today requires programmers to use various glue, events, background jobs, RPCs, etc. to keep in sync. All of which is the same spaghetti code that frontend engineers wrote before declarative reactivity. But, that is a big fish to fry. Maybe someday. :-)