For the best code quality, especially on large changes, innovative changes, or tasks where you're not sure of a solution but think the LLM might crack it open for you, you're still gonna want Zed's paid plan + Claude.

The frontend code is all type-safe, too. For example, the return type of this snippet is automatically inferred as an array of game objects:

// Get a list of the user's active games
relatedResources.get({
from: { kind: 'user', id: 'ABC' },
kind: 'is-playing',
to: { kind: 'game' },
})

Here's a bunch of frontend examples, querying the graph structure to get lists of resources that I can render in a loop:

This is the data structure I'm using on a project right now. It supports an arbitrary number of different relationships between any two resources in the app, and returns info about where and when the relationship was established.

Across every API and every page load, the payload going over the network is always the same data structure, just with different data, describing different subgraphs in the app.

You never have to design custom API payloads, write custom schemas, or sync custom TS types.

When a user takes an action, update the graph adding new nodes and/or relationships based on the action.

Re-render optimistically. Locally, store events that describe the changes. Depending on your needs, store graph snapshots.

Send the updated graph to your API to sync the backend.

When you load a page, request a subgraph, based on what the user needs and is authorized to see.

On the frontend, write utility functions so you can walk/parse/read/render the graph more ergonomically.

*eye twitches*

I'm a month into Zed and loving it. Multibuffers 🪄

This comment is art

@zed.dev + claude is S tier for me, maybe slightly lower for people who are heavier into VS Code extensions. The Zed multibuffer is a gamechanger when reviewing agent code, and when refactoring in general

I have no clue if this is going to be fast or memory-efficient at scale, but the querying feels great, and I've completely avoided the complexity of Eloquent relationships and helper tables. Gonna make it work before I make it fast

I think Laravel + single-table design might be groundbreaking stuff, but let me know if you've seen any projects do this! I'm currently running it with Inertia and SQLite, but in theory you could easily swap those out

This works because the entire app is written with a DynamoDB-inspired single-table design.

Resources' profile data is denormalized—I duplicate it and store in a JSON column as needed to support access patterns.

DB writes are complex, but my reads seem cheap and extremely easy so far.

The only emotion I associate with exclusive accordions is frustration