-
Someone above recommended https://connectrpc.com/ , which looks quite promising to me. Maybe I'll get time to play with it today
-
SurveyJS
JavaScript Form Builder with No-Code UI & Built-In JSON Schema Editor. Keep full control over the data you collect and tailor the form builder’s entire look and feel to your users’ needs. SurveyJS works with React, Angular, Vue 3, and is compatible with any backend or auth system. Learn more.
-
-
“the main thing your frontend devs like about GraphQL is its self documenting type safe nature”
I’ve been saying this for years: fetching multiple things in one query is not something normal-scale apps care about. What devs like about it is client generation and type safety. So OpenAPI, for all its flaws, covers that. GraphQL’s schema language is much more beautiful — hopefully Microsoft’s TypeSpec will take off and we can have the best of both worlds.
https://typespec.io/
-
You know you can just check before making these claims?
> In fact, for years, react didn't even tell in the doc you could use it without a transpiler so people had to learn a whole build chain before even getting to the hello world.
React's original documentation site from June of 2013 (when React was first introduced):
https://web.archive.org/web/20130607085014/http://facebook.g...
Feel free to click around that original documentation site.
Here's the README.md from the commit at the same time:
https://github.com/facebook/react/tree/a41aa76ef36471ba07b29...
> You'll notice that we used an XML-like syntax; we call it JSX. JSX is not required to use React, but it makes code more readable, and writing it feels like writing HTML. A simple transform is included with React that allows converting JSX into native JavaScript for browsers to digest.
At this point I would kindly ask you to go away.
-
It may not be an exact analog, but "swagger UI" for openapi is the best I've seen like GraphiQL. Example https://petstore.swagger.io/ . Not sure of other alternatives.
No analog for "subgraph federation systems", unless a load balancer will suffice.
-
There are a lot of proponents that some or all of the "JSON5" [1] improvements should be standardized by ECMA as well. Especially because there is a mish-mash of support for such things in some but not all parsers. (Writers are a different matter.) Primarily comments and trailing commas, are huge wish list items and the biggest reasons for all of the other "many" variant parsers (JSONC, etc).
[1] https://json5.org/
-
I will, once again, bring your attention to hashql, which is so pleasant to use. It's so minimal that it is almost more a pattern than a library. Try it out as an alternative to graphql if you are mainly querying a SQL database anyhow (although it can be easily configured to request data from other types of sources.) I don't think it can currently combine results from multiple data sources, but I think it should be within the realm of possible things
https://github.com/porsager/HashQL
-
Stream
Stream - Scalable APIs for Chat, Feeds, Moderation, & Video. Stream helps developers build engaging apps that scale to millions with performant and flexible Chat, Feeds, Moderation, and Video APIs and SDKs powered by a global edge network and enterprise-grade infrastructure.
-
> I seem to recall Meta/Facebook engineers on HN having said they have a tool that allows engineers to author SQL or ORM-like queries on the frontend and close to where the data is used, but a compiler or post-processor turns that into an endpoint.
I don't know about on-HackerNews but there's a discussion about their "all of Facebook optimizing compiler" infrastructure from when they did the site redesign in 2020: https://engineering.fb.com/2020/05/08/web/facebook-redesign/...
> perhaps not coincidentally, React introduced "server actions" as a mechanism that is very similar to [the above]
Yep - there's also the Scala framework LiftWeb (https://www.liftweb.net/), the Elixir framework Phoenix (https://www.phoenixframework.org/) and of course the system we're using right now (Arc) that do similar things. Scaling these kinds of UUID-addressed-closures is harder (because the client sessions have to be sticky unless you can serialize closures and send them across the network between servers).
-
webrpc
webrpc is a schema-driven approach to writing backend services for modern Web apps and networks
another project to take a look at for schema-driven approach to writing backend services and fully code-generated clients: https://github.com/webrpc/webrpc
it's similar to OpenAPI, but its simpler, and cleaner. In fact, you can generate webrpc schema's to OpenAPI and then generate OpenAPI clients.
-
This is a great write-up. I was already aware of most of the drawbacks that the author wrote about in the early days of GraphQL... But nobody would listen to me. Another category of solutions which was ignored completely is CRUD with field-granularity over WebSockets.
I've built platform which does just that: https://saasufy.com/
This approach has allowed me to create a library of highly generic components which can be composed into surprisingly complex front ends and where all data updates in real time (in a targeted, efficient and scalable way): https://github.com/Saasufy/saasufy-components?tab=readme-ov-...
It would have been impossible to do this with GraphQL because field-granularity is essential. GraphQL queries combine different resources and fields together and this makes it impossible to avoid real time update conflicts.
-
All good points! We built Yates (https://github.com/cerebruminc/yates) to solve the authz problem.
Yates implements Postgres RLS on top of Prisma, which we use as our ORM, and then our GraphQL schema is generated using TypeGraphQL (https://typegraphql.com/). Overall, it's a very nice setup and allows us to be versatile on the client side while still having strong authentication integrity.
-
All good points! We built Yates (https://github.com/cerebruminc/yates) to solve the authz problem.
Yates implements Postgres RLS on top of Prisma, which we use as our ORM, and then our GraphQL schema is generated using TypeGraphQL (https://typegraphql.com/). Overall, it's a very nice setup and allows us to be versatile on the client side while still having strong authentication integrity.
-
In my opinion, the single biggest issue with Newtonsoft.Json is https://github.com/JamesNK/Newtonsoft.Json/issues/862.
Sure, you can disable it, but the fact that it is opt-out to begin with - i.e. that by default the parser will try to creatively interpret any string it sees in JSON input and convert in a locale-specific manner that also quietly loses data - is, frankly, insane through and through. I've personally run into this issue many times in existing code - it usually happens when people first start using the library and just never run into any inputs that would trigger this behavior while testing. Then once that code is shipped, someone somewhere just happens to have the data that triggers it.
And if you look at the comments to that issue, there are numerous mentions from other GitHub repos due to bugs it caused for them, including some Microsoft projects.
The cherry on that cake was author's response indicating that he doesn't even understand why this design is problematic in the first place: "I like what it does, I have no plans to change it, and I would do it again if given the chance." I wouldn't trust any parser written with this kind of attitude.
-
-
openapi-ts
🚀 The OpenAPI to TypeScript codegen. Generate clients, SDKs, validators, and more. Support: @mrlubos
different tool for different aspect.
using OPENAPI, rpc, GQL types in client, etc to share typing (schema) information between client/server
resolver/dataloader in GQL, eager join in ORM is to handler internal data composition
presenter layer should not care about data composition, so that writing Query at presenter is an anti-pattern.
presenter should fetch schema info & data passively, like what https://github.com/hey-api/openapi-ts did, the job of implementation belongs to backend.
In fact what rest/rpc really need is the resolver and dataloader, to help backend easily extend or composing data together, and immediately transferring the schema & data to clients.
pydantic-resolve is the python binding for this idea.
-
drf-flex-fields
Dynamically set fields and expand nested resources in Django REST Framework serializers.
If anyone is reading this and is using Django there is a smooth transition to drf-flex-fields. The package gives GraphQL-like features while using REST.
- https://github.com/rsinger86/drf-flex-fields
- https://django.wtf/blog/graphql-like-features-in-django-rest...
-
InfluxDB
InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.
Related posts
-
dprint: A pluggable and configurable code formatting platform written in Rust
-
openapi-fetch-gen – Generate TypeScript API client from OpenAPI TypeScript interface definitions created by openapi-typescript
-
Everything about AI Function Calling (MCP), the keyword for Agentic AI
-
🚀 Biome Has Entered the Chat: A New Tool to Replace ESLint and Prettier
-
typia (20,000x faster validator) challenges to Agentic AI framework, with its compiler skill