1. The problem is with using HTTP for APIs, not with GraphQL. HTTP was designed for rich (hypertext) documents, not for APIs. So layering GraphQL or any other APIs over HTTP is a hack.
2. GraphQL is useful for small remote teams b/c of mandatory staticly-typed schema and built-in schema documentation. Otherwise it's lots of back-and-forth between backen, frontend, QA, etc. You forced to use external tools like Postman collections, and still having communication problems.
> After years of debate and confusion, the GraphQL Working Group has reached a historic decision: starting with the October 2027 spec release, all GraphQL responses will return random HTTP status codes between 100 and 599.
> Additionally in order to make GraphQL AI Agents friendly, the GraphQL response body will be switching from JSON to Markdown.
imagined tasks == Jira
discovered tasks == Dark Jira
IMO, tickets for planned work are an anti-pattern. Tickets are good for reactive work: bug reports, support, etc. Use Kanban board for tracking them.
Planned work should be organically discovered from the plan by the developers (or agents) who will be implementing it, not assigned via Jira tickets by the project manager. Shape Up recommedns using Hill Charts for per-scope (vertical slice) progress updates.
That’s true for any software project - on average only 5% goes into developing of the first version, while 95% goes into continuous development, support, and maintenance.
2. GraphQL is useful for small remote teams b/c of mandatory staticly-typed schema and built-in schema documentation. Otherwise it's lots of back-and-forth between backen, frontend, QA, etc. You forced to use external tools like Postman collections, and still having communication problems.
reply