Search results

It's often easier to use lab tests to make technical decisions for your system. Yet, behaviors can differ in production, and you may want to revisit your choices in the light of real case scenarios. At Deezer we experimented it with GraphQL JIT and here is my notes : https://deezer.io/graphql-jit-is-it-worth-it-64e66f21dbb8 #nodejs #graphql #performance

GraphQL JIT promet des performances accrues et une économie de CPU. Et sur le papier, comme dans les tests, ça tient la route. Mais après quelques années en production, la réalité est plus nuancée, et les promesses s’estompent. Je vous raconte tout sur mon blog ! https://blog.ztec.fr/2025/post/graphql-jit-est-t-il-vraiment-plus-performant/ #nodejs #graphql #performance

GraphQL: The Enterprise Honeymoon Is Over

Link: https://johnjames.blog/posts/graphql-the-enterprise-honeymoon-is-over
Discussion: https://news.ycombinator.com/item?id=46264704

#graphql

#introductionpost

Developer, first #java, then #frontend, then #scala (since a long time), recently #rustlang.
I maintain #sangria, a #graphql scala library, since its creator passed away (RIP Oleg).

I have organized meetups in Berlin, for the #playframework and then for #scala.

I really like #functionalprogramming but I struggle when I have to choose between performance & style.
I'm trying to be a good citizen in the open-source world, opening issues / PRs, helping others.

Hi, I'm Will. I'm the CTO of an e-commerce company. I enjoy solving problems.

Software can provide solutions. I've designed, written, deployed, maintained, and retired my share of systems. I derive particular satisfaction from coding in #Rust, though I often use #React, #GraphQL, #Ruby, and #golang too.

I have a wife, a bird, and a forest in northern MN where I'm trying to build a forever home.

#introduction

We're migrating Hackers' Pub to a pretty unconventional tech stack, and I'm honestly excited about it!

Thanks to my friend @xiniha, we're diving into #Solid, #SolidStart, #Pothos, #GraphQL, and #Relay. In a world dominated by Next.js and React, this feels refreshingly different. And yes, we're sticking with #Deno instead of Node.js too.

Some might call it contrarian, but I like to think of it as exploring what's possible beyond the mainstream. Sometimes the road less traveled leads to interesting places.

I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.

What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?

The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.

#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.

Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?

Curious what others think about this approach.

#fedidev