pull down to refresh
There's a steep benefit curve to
graphql. It's awesome when your API is evolving rapidly or you are caching on the client a lot. For something like git I'm not sure you need either of those much.I looked into
git-bug when I was hacking on https://gitern.com. I probably would've forked or rewritten it from scratch but that's how I imagined implementing github-like issues while maintaining portability.reply
I agree that it could be nice for rapid development in an ecosystem around a central service - iirc that's what FB developed it for - but it's indeed overkill for something simple that doesn't change much (and if it does, you need versioning) and you just want to install and run; especially if it's distributed by nature.
It's also funny that the caching is killing my experience with this particular web-ui because I need to literally hit refresh when navigating (using in-app navigation) to see new state on an issue - so in this instance it's also kind of awfully implemented.
I was thinking that
git-bug could be nice for git-collab-over-decentralized-protocol (like the nostr thing) because it can ultimately reduce the code needed, and technically I shouldn't need to run it as a server other than for some management GUI. But to support github-like code collaboration, review and communication, issues need to evolve to pull requests, so I am looking to hack that in.Also, it may be nice to have everything in a single repo when running transient containers for LLM coding workloads. I figured a while back that if we're going to let an LLM code like a pro, we should treat it like a pro: not some prompt and a log and that's it, but really integrate a fully tooled agile workflow into the process. No need a gui with an annoying chatbox then, and doing it via text files doesn't scale with all the bloat LLMs generate - something structured would be nice. Anyway I was thinking that if this works well, I could in theory automate a whole dev team fr.
reply
I agree that it could be nice for rapid development in an ecosystem around a central service - iirc that's what FB developed it for
Yes, and I think they also developed it for mobile because GraphQL also improves bandwidth since you can select exactly what you need, not more, not less. I think I heard that in here:
It's also funny that the caching is killing my experience with this particular web-ui because I need to literally hit refresh when navigating (using in-app navigation) to see new state on an issue - so in this instance it's also kind of awfully implemented.
yeah caching is hard for real haha, we also had many issues with our caching, but maybe it's just a "skill issue"
reply
since you can select exactly what you need, not more, not less.
That's a benefit; there is something similar in bitcoind for
getblockstat.maybe it's just a "skill issue"
I don't think so. Cache expiry / cached state transition is hard and really easy to get wrong, I can't remember a single instance where it was easy to make it smooth - and then I'm talking about back-end caching, which is easier than on the front-end.
I think that caching is hardest to consistently deliver when you are still rapidly adding or refactoring features/API, but you could design to overcome that by abstracting the mechanism.
reply
.patchcan get proposed as an issue and then have it picked up with some CI. The interface for server layer is...graphqland now I really feel for all poor souls that use that, while realizing that well designed REST APIs are the real luxury life, lol.