mercurius
jaeger
Our great sponsors
mercurius | jaeger | |
---|---|---|
22 | 94 | |
2,300 | 19,370 | |
0.9% | 1.1% | |
7.9 | 9.7 | |
5 days ago | about 17 hours ago | |
JavaScript | Go | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
mercurius
-
The Road to GraphQL At Enterprise Scale
GraphQL Gateway is primarily responsible for serving GraphQL queries to consumers. It takes a query from a client, breaks it into smaller sub-queries, and executes that plan by proxying calls to the appropriate downstream subgraphs. When we started our journey, there was only Apollo Federation in the arena, and we used it. Still, now you can look at other options (e.g. Mercurius, Conductor, Hot Chocolate, Wundergraph, Hasura Remote Schemas), compare benchmarks and decide what's important and preferable for your needs. The Gateway provides a unified API for consumers while giving backend engineers flexibility and service isolation.
-
Dynamic GraphQL queries with Mercurius
If you're using Fastify with Mercurius as your GraphQL adapter, you may be looking for some advanced usages. In this article, we'll explore a real world example with Dynamic GQL queries with Mercurius.
-
How to use DataLoader with Mercurius GraphQL
Loader: it is a built-in DataLoader-Like solution that is quick to set up and use.
-
Simple example with NestJS and Mercurius 😻
In this post I will show you how to implement NestJS😻 with GraphQL in code first mode, using Mercurius and the "platform" to Fastify.
-
Barrel Exports considered harmful
What this does is to overwrite or augment the types exposed by the pointed module, and can be used (for example) when relying on autogenerated code. One interesting case of this is GraphQL to TypeScript code generation, and how this is integrated with the amazing Mercurius library (made by some of my colleagues at NearForm! 😜).
-
Apollo Server v4 Breaking Changes. Time to move away?
When moving away from Apollo Server, and you're looking for a replacement built with JavaScript or TypeScript, let me give you some options. If you want to keep building your GraphQL API schema first, you might want to consider Mercurius (which relies on Fastify) or GraphQL Yoga. If you're going to build your GraphQL API code or resolver first, have a look at TypeGraphQL or Nexus. Alternatively, there are great GraphQL-as-a-Service solutions such as StepZen in case you no longer want to build, maintain and host your own GraphQL API.
-
Fastify DX and SolidJS in the Real World
Let's start with data. We live in amazing times and it's really easy and cheap (or free) to get started with storing and working with data online. Take for example a PlanetScale MySQL-compatible database, Fastify Node.js Server, Prisma database mapper and a GraphQL connector like Mercurius and you have an entire backend stack. For this example we assume you already have a backend or you want to connect to a 3rd party database like the GitHub GraphQL API.
-
Nest JS With Graphql World
In this chapter, we assume a basic understanding of GraphQL and focus on how to work with the built-in @nestjs/graphql module. The GraphQLModule can be configured to use Apollo server (with the @nestjs/apollo driver) and Mercurius (with the @nestjs/mercurius). We provide official integrations for these proven GraphQL packages to provide a simple way to use GraphQL with Nest. You can also build your own dedicated driver (read more on that here).
-
Shill me on Apollo client.
Why would I want to use Apollo Client? So far in my career I have used some server graphql scaffolding (webonyx/graphql-php for PHP and mercurius for Node) and just used the fetch API (or whatever ajax API around XMLHttpRequest) against that server with the body being an object with
-
Are there actually better alternatives than Apollo server?
Only for people who are clueless. Apollo server is probably the worst node.js server to use for your graphql schema. It's terribly slow. You should look into https://mercurius.dev
jaeger
-
Observability with OpenTelemetry, Jaeger and Rails
Jaeger maps the flow of requests and data as they traverse a distributed system. These requests may make calls to multiple services, which may introduce their own delays or errors. https://www.jaegertracing.io/
-
Show HN: An open source performance monitoring tool
As engineers at past startups, we often had to debug slow queries, poor load times, inconsistent errors, etc... While tools like Jaegar [2] helped us inspect server-side performance, we had no way to tie user events to the traces we were inspecting. In other words, although we had an idea of what API route was slow, there wasn’t much visibility into the actual bottleneck.
This is where our performance product comes in: we’re rethinking a tracing/performance tool that focuses on bridging the gap between the client and server.
What’s unique about our approach is that we lean heavily into creating traces from the frontend. For example, if you’re using our Next.js SDK, we automatically connect browser HTTP requests with server-side code execution, all from the perspective of a user. We find this much more powerful because you can understand what part of your frontend codebase causes a given trace to occur. There’s an example here [3].
From an instrumentation perspective, we’ve built our SDKs on-top of OTel, so you can create custom spans to expand highlight-created traces in server routes that will transparently roll up into the flame graph you see in our UI. You can also send us raw OTel traces and manually set up the client-server connection if you want. [4] Here’s an example of what a trace looks like with a database integration using our Golang GORM SDK, triggered by a frontend GraphQL query [5] [6].
In terms of how it's built, we continue to rely heavily on ClickHouse as our time-series storage engine. Given that traces require that we also query based on an ID for specific groups of spans (more akin to an OLTP db), we’ve leveraged the power of CH materialized views to make these operations efficient (described here [7]).
To try it out, you can spin up the project with our self hosted docs [8] or use our cloud offering at app.highlight.io. The entire stack runs in docker via a compose file, including an OpenTelemetry collector for data ingestion. You’ll need to point your SDK to export data to it by setting the relevant OTLP endpoint configuration (ie. environment variable OTEL_EXPORTER_OTLP_LOGS_ENDPOINT [9]).
Overall, we’d really appreciate feedback on what we’re building here. We’re also all ears if anyone has opinions on what they’d like to see in a product like this!
[1] https://github.com/highlight/highlight/blob/main/LICENSE
[2] https://www.jaegertracing.io
[3] https://app.highlight.io/1383/sessions/COu90Th4Qc3PVYTXbx9Xe...
[4] https://www.highlight.io/docs/getting-started/native-opentel...
[5] https://static.highlight.io/assets/docs/gorm.png
[6] https://github.com/highlight/highlight/blob/1fc9487a676409f1...
[7] https://highlight.io/blog/clickhouse-materialized-views
[8] https://www.highlight.io/docs/getting-started/self-host/self...
[9] https://opentelemetry.io/docs/concepts/sdk-configuration/otl...
-
Kubernetes Ingress Visibility
For the request following, something like jeager https://www.jaegertracing.io/, because you are talking more about tracing than necessarily logging. For just monitoring, https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack would be the starting point, then it depends. Nginx gives metrics out of the box, then you can pull in the dashboard like https://grafana.com/grafana/dashboards/14314-kubernetes-nginx-ingress-controller-nextgen-devops-nirvana/ , or full metal with something like service mesh monitoring which would provably fulfil most of the requirements
-
Migrating to OpenTelemetry
Have you checked out Jaeger [1]? It is lightweight enough for a personal project, but featureful enough to really help "turn on the lightbulb" with other engineers to show them the difference between logging/monitoring and tracing.
-
The Road to GraphQL At Enterprise Scale
From the perspective of the realization of GraphQL infrastructure, the interesting direction is "Finding". How to find the problem? How to find the bottleneck of the system? Distributed Tracing System (DTS) will help answer this question. Distributed tracing is a method of observing requests as they propagate through distributed environments. In our scenario, we have dozens of subgraphs, gateway, and transport layer through which the request goes. We have several tools that can be used to detect the whole lifecycle of the request through the system, e.g. Jaeger, Zipkin or solutions that provided DTS as a part of the solution NewRelic.
-
OpenTelemetry Exporters - Types and Configuration Steps
Jaeger is an open-source, distributed tracing system that monitors and troubleshoots the flow of requests through complex, microservices-based applications, providing a comprehensive view of system interactions.
-
Fault Tolerance in Distributed Systems: Strategies and Case Studies
However, ensuring fault tolerance in distributed systems is not at all easy. These systems are complex, with multiple nodes or components working together. A failure in one node can cascade across the system if not addressed timely. Moreover, the inherently distributed nature of these systems can make it challenging to pinpoint the exact location and cause of fault - that is why modern systems rely heavily on distributed tracing solutions pioneered by Google Dapper and widely available now in Jaeger and OpenTracing. But still, understanding and implementing fault tolerance becomes not just about addressing the failure but predicting and mitigating potential risks before they escalate.
-
Observability in Action Part 3: Enhancing Your Codebase with OpenTelemetry
In this article, we'll use HoneyComb.io as our tracing backend. While there are other tools in the market, some of which can be run on your local machine (e.g., Jaeger), I chose HoneyComb because of their complementary tools that offer improved monitoring of the service and insights into its behavior.
-
Building for Failure
The best way to do this, is with the help of tracing tools such as paid tools such as Honeycomb, or your own instance of the open source Jaeger offering, or perhaps Encore's built in tracing system.
-
Distributed Tracing and OpenTelemetry Guide
In this example, I will create 3 Node.js services (shipping, notification, and courier) using Amplication, add traces to all services, and show how to analyze trace data using Jaeger.
What are some alternatives?
apollo-server - 🌍 Spec-compliant and production ready JavaScript GraphQL server that lets you develop in a schema-first way. Built for Express, Connect, Hapi, Koa, and more.
Sentry - Developer-first error tracking and performance monitoring
graphql-helix - A highly evolved GraphQL HTTP Server 🧬
skywalking - APM, Application Performance Monitoring System
subscriptions-transport-ws - :arrows_clockwise: A WebSocket client + server for GraphQL subscriptions
prometheus - The Prometheus monitoring system and time series database.
graphql-tools - :wrench: Utility library for GraphQL to build, stitch and mock GraphQL schemas in the SDL-first approach
signoz - SigNoz is an open-source observability platform native to OpenTelemetry with logs, traces and metrics in a single application. An open-source alternative to DataDog, NewRelic, etc. 🔥 🖥. 👉 Open source Application Performance Monitoring (APM) & Observability tool
graphql-js - A reference implementation of GraphQL for JavaScript
Pinpoint - APM, (Application Performance Management) tool for large-scale distributed systems.
graphql-mesh - The Graph of Everything - Federated architecture for any API service
fluent-bit - Fast and Lightweight Logs and Metrics processor for Linux, BSD, OSX and Windows