GraphQL on trial, Database for SQL haters, and Headless UI Library
Is GraphQL a bad idea for your new project?
In a blog post, Marc-André Giroux disputes the arguments of a Twitter thread claiming that “GraphQL is a trap“. The counterpoints are actually a good set of guidelines on what to expect and how to internalize GraphQL in an app architecture.
A generic GraphQL API actually goes counter to what most would consider best practice. In fact, the GraphQL Spec has consistently rejected proposals for generic / database-like features (like filtering, ordering, etc).
The ORM is now on the database
EdgeDB is a new contender in the post-SQL arena presenting itself as a graph-relational database. It is built upon Postgres and also open-sourced. EdgeDB bets on developer experience, embedding features often found on code libraries like migrations and high-level abstractions for data relationships.
(…) solves the object-relational impedance mismatch by returning a structured result object, not a list of rows—eliminating the need for a third-party ORM to denormalize the results.
A lightweight approach to UI components libraries
UI Components libraries like Bootstrap and Material UI can speed things up, especially at the begging of a web project. Nevertheless, they bring trade-offs regarding flexibility and pressure over your dependencies tree.
Libraries like Zag try to smooth the flexibility concerns by solving more hardcore problems like accessibility and interaction but leave the styling in the hand of the developer.
Zag [state] machine APIs are completely headless and unstyled. Use your favorite styling solution and get it matching your design system.