Why does Grafana use React for its frontend?
How we leverage React’s features at Grafana
What are some pain points we have ran into with using React at Grafana
What are lessons learned from adopting React for the past 5+ years?
How Grafana Uses React to Power the World of Observability
This talk has been presented at React Summit 2023, check out the latest edition of this React Conference.
FAQ
Nathan Mars is the tech lead of the data visualization squad at Grafana Labs.
React's ecosystem, performance optimizations, and ubiquity have allowed Grafana to ship features faster, reduce technical debt, and facilitate community contributions.
Grafana's BigTent philosophy supports a broad observability ecosystem, providing users with flexibility in visualizing data from various sources like Kubernetes clusters, Raspberry Pis, cloud services, and Google Sheets.
Users interested in learning more about Grafana and its new Dashboard Runtime Library, Scenes, should check out the upcoming GrafanaCon conference.
Grafana is an open-source platform that enables millions of users to visualize and analyze their data.
Grafana has faced challenges with state management and the Hooks paradigm, including issues like stale closures and the need to understand React internals.
Grafana uses a mixture of state management tools including Redux, RxJS, Props, and Context, adapting them to fit specific problem spaces.
No, initially Grafana used Angular. The team switched to React in 2018.
Grafana switched to React because migrating to Angular 2 was as much effort as switching to React, and React was more appealing to talented developers.
Grafana is developing a new approach called Scenes, which simplifies the development process and reduces the learning curve for developers. Scenes eliminate the need for complicated concepts such as useEffects and useCallbacks.
1. Introduction to Grafana's Use of React#
Hi, I'm Nathan Mars, the tech lead at Grafana Labs. Grafana uses React to power its open source platform, providing benefits like a vast ecosystem, improved performance, and community contributions. However, React's state management has posed challenges, leading Grafana to use a mixture of Redux, RxJS, Props, and Context. The choice of state management tool depends on the team's problem space.
Hi, my name is Nathan Mars and I'm the tech lead of the data visualization squad at Grafana Labs. Today, I'm excited to share with you how Grafana leverages React to power its widely used open source platform that enables millions of users to visualize and analyze their data.
Let's begin with a story. Grafana didn't always use React. In fact, it first used Angular. In 2018, the team came up at a crossroads. Either migrate to Angular 2 from Angular 1 or consider other options. Ultimately, the team decided to switch over to React as the effort wasn't too different migrating to Angular 2 required and React was what talented people wanted to work with. With the decision made to switch to React, the immense migration commenced. This is another story entirely, and it's still ongoing.
Today, we use React to power the entire front end of Grafana from dashboards to explorer to alerting and much more. React has provided us with some significant benefits. Firstly, React's ecosystem is immense. It's almost at the same level of there's an app for that, but, instead, it's there's a third party library for that. Being able to tap into this ecosystem has allowed us to ship features faster and reduce the technical debt we own. For example, we wanted to build a new panel type called Canvas that allows for creating custom layouts and UIs. A third-party library called Movable helped us out immensely, getting us to beta state months earlier than we otherwise would have. React's performance is another benefit that has allowed us to scale. The built-in rendering optimizations, as well as class-based components should component update and hooks dependencies arrays, have made it easier for us to optimize our codes' performance and ultimately provide a great user experience.
Another benefit of using React is its ubiquity. As Grafana is open source, being based on the most popular frontend library has helped facilitate community contributions to Grafana. However, Grafana has also experienced some challenges with React, especially when it comes to state management. React has never claimed to be a framework, unlike Angular, so the question of how to manage a complex app state while using React has long been open-ended. Before context, there was Redux. Before Redux, there was the good old unidirectional passing of props. What has Grafana's approach been to this? Well, to use them all in a mixture. From Redux, RxJS, Props and Context, and more. As Grafana matures, it is yet to be seen if this approach is sustainable. In general, we feel that a team should use a state management tool that best fits their problem space. The ambiguity of which solution to use is a classic problem for versatile, open source libraries and platforms.
2. Grafana's Use of React and Challenges with Hooks#
Grafana supports a wide range of data sources and aims to provide flexibility in visualizing data. However, this can lead to confusion for users in finding the best solution. React Hooks have posed challenges, but they have also been a powerful tool for developers. Grafana is excited to announce the new Scenes library, which simplifies development and reduces the learning curve. Despite challenges, React remains a powerful tool for complex frontends, and Grafana will continue to use it.
Grafana itself has a BigTent philosophy, supporting as much of the observability ecosystem as possible. This provides our users with a huge amount of flexibility in visualizing their data, no matter what the source, be it from their Kubernetes cluster, Raspberry Pi, different cloud services, or even Google Sheets.
At the same time, though, this can lead to confusion from our end users in figuring out how to construct the best observability solution for themselves.
Another challenge we have faced with React is with the Hooks paradigm. Some at Grafana have expressed their frustration with Hooks as they introduce stale closures and require learning and mastering Hook rules. Functional components, as they are called, are rarely pure functions. Hooks also introduce a much stronger coupling with the React runtime than before. The name Hook indicates this. You are hooking into React internals. So you need to understand those internals. Hooks are far from being a functional abstraction, as you need to know the internal details of their implementation. This becomes even more apparent when you try to test one hook in isolation.
React has followed a functional programming paradigm. And some fear with the introduction of Hooks that it may be straying from that paradigm and entering into framework land. Although some at Grafana have expressed concerns with Hooks, it's important to note that they have been a powerful tool for our developers. As with any tool, there may be a learning curve, but once mastered, they can greatly enhance the development process. At Grafana, we recognize the importance of exploring and experimenting with new tools and methodologies to continually improve our development processes. We appreciate the benefits that Hooks have brought to our development workflow and continue to explore new ways to enhance our tools and processes.
With that being said, we are excited to announce our new approach to building our next-generation dashboard runtime library, Scenes. We have taken a different approach that simplifies the development process and reduces the learning curve for our developers. With Scenes, each component subscribes to state build with ArcGIS, renders markup, and pipes callbacks back to the state model. We have eliminated the need for complicated concepts such as useEffects and useCallbacks. The state model takes care of any necessary mount effects, making the development process more intuitive and efficient. We are confident that our new library will be a game changer for our developers and we believe that this simplified approach will lead to a more positive development experience. Although the library is still in its early stages of development, we are excited to see how it will continue to evolve and improve the way we build our dashboards.
Despite our challenges, we believe that React is a powerful tool for solving the problem of implementing and maintaining complex frontends. Structural subtlety is key, and with it there is a freedom to consider a myriad of state management options and pick whichever makes the most sense. Moving forward, it's important to recognize that as an open source community, we have options. When a tool stops solving the problem we hire it for, we can throw it out and try a new one. React doesn't stay from this, and neither does Grafana. But for now, we are happy with our decision to switch to React, and will continue to use it for as long as it makes sense to. If you're interested in learning more about Grafana and our new Dashboard Runtime Library themes, please check out the upcoming GrafanaCon conference.
Check out more articles and videos
We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career
Workshops on related topic
Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.
Comments