The GraphQL which ‘elegantly’ returns a 200 on errors? The GraphQL which ‘elegantly’ encodes idempotent reads as mutating POSTS? The GraphQL which ‘elegantly’ creates its own ad hoc JSON-but-not-JSON language?
The right approach, of course, is HTMX-style real REST (incidentally there needs to be a quick way to distinguish real REST from fake OpenAPI-style JSON-as-a-service). E.g., the article says: ‘your client should be able to request all data for a specific screen at once.’ Yes, of course: the way to request a page is to (wait for it, JavaScript kiddies): request a page.
The even better approach is to advance the state of the art beyond JavaScript, beyond HTML and beyond CSS. There is no good reason for these three to be completely separate syntaxes. Fortunately, there is already a good universal syntax for trees of data: S-expressions. The original article mentions SDUI as ‘essentially it’s just JSON endpoints that return UI trees’: in a sane web development model the UI trees would be S-expressions macro-expanded into SHTML.
N+1 is a solved problem at the framework level
If GraphQL actually affects your performance, congratulations, your application is EXTREMELY popular, more so than Facebook, and they use graphql. There are also persisted queries etc.
Not sure about caching, if anything, graphql offers a more granular level of caching so it can be reused even more?
The only issue I see with graphql is the tooling makes it much harder to get it started on a new project, but the recent projects such as gql.tada makes it much easier, though still could be easier.
We use the dataloader pattern (albeit an in-house Golang implementation) and it has solved all our N+1 problems.
E2E type safety in our case is handled by Typescript code generation. It works very well. I also happen to have to work in a NextJS codebase, which is the worst piece of technology I have ever had the displeasure of working with, and I don't really see any meaningful difference on a day to day basis between the type sharing in the NextJS codebase (where server/client is a very fuzzy boundary) and the other code base that just uses code generation and is a client only SPA.
For stitching we use Nautilus and I've never observed any issues with it. We had one outage because of some description that was updated in some dependency and that sucked but for the most part it just works. Our usage is probably relatively simple though.
on top of http level caching, you can do any type of caching (redis / fs / etc) just like a regular rest but at a granular level, for ex: user {comments(threadId: abc, page: 1, limit: 20) { body, postedAt} is requested and then cached, another request can come in thread(id: abc) {comments(page: 1, limit: 20) {body, postedAt} you can share the cache.
but of course, there is always the classic dataloader as well.
I am not saying that use graphql and all the problems will be solved, but i am saying that the problem that OP proposed has been solved in an arguably "better" way, as it does not tie the presentation (HTML) with the data for cases of multiplatform apps like web, or native apps.
Mathematics, Computer Science and UI/UX design specialist with 25+ years of experience.
I solve two of the most challenging software engineering problems: code organization and state management, using lightweight formal methods -- Applied category theory, Finite state machines -- to bring academic rigor to the full stack: https://www.osequi.com/studies/list/list.html
I'm a junior AI Engineer versed in prompting, agentic development with Vercel AI SDK. Finishing my first AI app, an agent/assistant helping to write likely-correct studies, articles and technical documents.
Seeking:
- Teams building better software, faster
- Particularly interested in fintech, health-tech, and developer tools
There are formal methods where the underlying model is mathematically sound. There are semi-formal methods where the underlying model is structured but not proven to be sound.
For example, in your case ("organizes knowledge") a formal method is ologs from category theory. That method assures that the concepts and their relationship in your knowledge base are mathematically correct.
When you want to transfer that knowledge base into a documentation system you might want look for a mathematically sound model, but I'm afraid there is no such model, so what's left is a semi-formal method / a likely-correct model.
Right now I'm building such a likely-correct model for writing, contact me for more info.
Thank you for introducing me to ologs - they're fascinating. I'm intrigued by the distinction you make between formal methods and semi-formal approaches.
I'd love to explore how your "likely-correct model for writing" might complement the MECE-based documentation system I've been developing. Since you're building a model focused on writing correctness, perhaps there's an opportunity to collaborate?
My approach addresses the organizational structure of documentation, while your work seems to focus on ensuring correctness at the content level. Together, these could potentially create a more comprehensive solution that combines hierarchical organization with formal correctness principles.
Would you be interested in discussing further? I'm curious to learn more about your model.
Perhaps there is no such thing like absolute truth.
In category theory / ologs, a formal method for knowledge representation, the result is always mathematically sound, yet ologs are prefixed with "According to the author's world view ..."
On the other way truth, even if it's not absolute, it's very expensive.
Lately AWS advocates a middle ground, the lightweight formal methods, which are much cheaper than formal methods yet deliver good enough correctness for their business case.
In the same way MIT CSAIL's Daniel Jackson advocates a semi-formal approach to design likely-correct apps (Concept design)
It seems there is a push for better correctness in software, without the aim of perfectionism.
The structure (ontology, taxonomy) is created with ologs, a formal method from category theory. The behavior (choreography) is created with a semi-formal implementation (XState) of a formal method (Finite State Machines)
The user-facing aspect of the software is designed with Concept Design, a semi-formal method from MIT CSAIL.
Creating software with these methods is refreshing and fun. Maybe one day we can reach Tonsky's "Diagrams are code" vision.
"Diagrams are code" exists as ladder diagrams for PLC, from which Structured Text can be derived, which typically are used by PICs for simple to estimate time behavior in very time-sensitive/critical (real-time) control applications.
Stack + dynamic memory and other system resource modeling would need proper models with especially memory life-time visualization being an open research problem, let alone resource tracking being unsolved (Valgrind offers no flexible API, license restrictions, incomplete and other platforms than Linux are less complete etc).
Reads and writes conditioned on arithmetic have all the issues related to complex arithmetic and I am unaware of (time) models for speculation or instruction re-ordering, let alone applied compiler optimizations.
Fascinating approach with ologs and FSMs I've been working on PAELLADOC (https://github.com/jlcases/paelladoc) which applies MECE principles to documentation structure. Similar philosophy but focused on knowledge representation correctness rather than software behavior.
The results align with your experience - structured conceptual foundations make development more intuitive and documentation more valuable for both humans and AI tools.
A Senior / Lead React Front-end Developer, Design Engineer, Software Architect is looking for a job.
I have dual skills: a degree in Computer Science and UI/UX design works featured in online galleries.
In the last 15 years I've been designing and developing websites and applications. From back-end to front-end, from architecture design to UI/UX design, on different stacks. I've built and managed front-end teams, shaped products.
Currently, I specialize in React and TypeScript, offering expertise in:
- Team Leadership: Building and guiding React teams, producing high-quality code even with junior developers.
- Design Engineering: Developing robust design systems, enabling rapid prototyping, shaping product design, and bridging developer-designer communication gaps.
Mathematics, Computer Science and UI/UX design specialist with 25+ years of experience.
I solve two of the most challenging software engineering problems: code architecture and state management, using formal methods (Applied category theory, Finite state machines) to bring academic rigor to the full stack: https://www.osequi.com/studies/list/list.html
I also facilitate product design by bridging design and development, leveraging my deep understanding of both visual design and its technical implementation.
Achievements:
- Built and led engineering teams (30+ engineers)
- Co-founded startups (1 successful exit)
- International consulting (Silicon Valley, UK, EU, Singapore)
- Featured in UI/UX design galleries
- Recently completed two-year R&D sabbatical focused on software correctness and rapid iteration methodologies
Seeking:
- Senior / Principal architect or technical leadership roles at companies valuing correctness, maintainability, and design excellence
- Joining teams building better software, faster
- Particularly interested in fintech, health-tech, and developer tools
Compared to GraphQL, Server Components are a big step back: you have to do manually on the server what was given by default by GraphQL
reply