Flare 2.0 has been launched!
These past months, we've been busy redesigning our entire service. We're very proud to launch it today. Long-time users will immediately notice that both our marketing website and application have a new coat of paint.
We didn't only update the looks. We've also added some new features and improved others in the process.This blog post will look at Flare 2.0's history, features, and used technology. Let's dive in!
Instead of reading this blog post, you can see it all by yourself by starting a free 10-day trial now! Should you want to start using Flare after 10 days, we now offer a very affordable hobby plan. You can help us spread the good news by retweeting our launch tweet.
What is Flare?
In most cases, you start developing an app locally on your computer. At some point, the finished application is deployed to your production server, ready to use for the world!
Most applications are developed locally. On your computer, debugging can be done without hassle. You can place some dd, dump or ray statements within the application, or use xDebug. When an error occurs locally, an error message will be shown locally. In Laravel applications, errors are shown via Ignition, Laravel's default error page, which we created as well. More on that later. Here's how Ignition looks like for a common error in Laravel.
When deploying your application in production, adding dd's can break your whole application, and running Xdebug isn't possible. Ignition is also disabled on production because you don't want to show the inner workings of your code, possible environment variables, queries, and so much more to the users visiting your app.
What if you could keep Ignition on production but not show it to your users? That's where Flare comes in. Instead of showing the error in the browser of your application's user, you can let your application send it to Flare. In Flare, you can see exactly what went wrong, and this information will help you fix the issue. Here's what the error above looks like in Flare.
Flare will also send you a notification (via Mail, Slack, Telegram, webhooks...) when an error happens. This way, you can be aware of and fix the problem even if your user doesn't contact you.
In Flare, you get all of the niceties Ignition provides, like the queries which ran, possible solutions for the problem, job context if the exception happened on the queue, LiveWire data passed to your components, and so much more!
You can link exceptions with GitHub issues and track who in your team is working on the issue, and if it has already been solved. Our graphs provide insight into which applications have the most errors and which should be fixed first. You can even see which users had the error and contact them.
If you have a JavaScript frontend (or even a backend application), then Flare will be an ideal companion. We support the major frameworks like Vue and React or vanilla JS if that's your thing. You can upload sourcemaps that make your obfuscated code make sense again.
Four years of Flare history
Let's take a look at how Flare initially came to be. The first commit on the Flare repository was pushed on the 12th of February 2019, more than four years ago! Oh, how time flies.
The commit message "fire torpedoes" was a wink at the working title of our product: "Photon". Before launching our product, we decided that Photon sounded too aggressive, and after a long process, we landed on the name Flare. Notice that both the names Photon and Flare revolve around "Light", which is the theme behind the early naming scheme of Laravel (Illuminate, Spark, Nova, …). In the early days of Flare, Marcel Pociot was also involved in building Flare.
During the development process, we tried new technologies that weren't fully released yet. We were one of the first users of Laravel Vapor, the best serverless platform for Laravel apps. We also were very early adopters of Inertia.js, which we loved immediately. Our colleague Seb even coded the Inertia.js React adapter, which we still use today!
Our project deadline was set for Laracon EU 2019 in August. Within six months, we built not only the Flare application from scratch but Ignition as well. Ignition would go on to become the default error page in Laravel.
At Laracon EU 2019, Flare was shown in true Apple Keynote fashion to the public. Back at the Spatie office, all of us not attending Laracon were prepping the release and ensuring everything went live when the keynote was over. Everything went smoothly, and from that point in time, Flare was live!
In the next months and years, we didn't sit still and added a lot of new functionality to Flare. Here are some highlights:
-
The JS error tracking which didn't exist when Flare launched
-
And so much more ...
Since Flare became so stable, we had some time to think about the next big step, and that's when we started working on the redesign, Flare v2.
Why redesign Flare?
When Flare was launched, we were delighted with Ignition becoming the default exception page in Laravel. We always intended to have a unified experience for handling exception messages. Laravel users should feel right at home in Flare, as they already know Ignition visually.
Of course, design trends change over time. Early last year, we decided to work on a refresh of how Ignition looks. It was released around one year ago. Our initial plan was to launch the redesign for Flare around the same time, but unfortunately, we couldn't pull this off. You might think that Spatie is a big firm with many people, but we're quite a small team. We also perform client work, and our full schedule didn't allow us to complete the Flare redesign.
Instead of shipping something half-baked, we made the difficult decision to postpone the redesign.
When we had time to spend on Flare again, we decided to speed things up by letting the good people at DWY develop a new design for the marketing website from scratch. Dieter and Steve of DWY did a terrific job by providing a Sketch file from which we could cut the whole website.
With DWY having redesigned the marketing website, our app, which was still in its old style, looked way off. We decided to take hints from the marketing website to redesign our app. We didn't redesign it in one go but did several iterations. In these screenshots, you can see our app UI evolve.
What's new in Flare
We worked intensively with the whole team on this redesign and added some new functionality next to the new design. Let's go through it!
New onboarding
There's now a new onboarding experience. When you log in for the first time, you're invited to create a new project.
Here, you can create your very first project. Let's go ahead a pick Laravel as the used technology.
Next, we show detailed instructions on how to configure your Laravel app. You now get instructions tailored for the Laravel version that you use.
In one the final steps of the installation process, we added some real-time feedback to show you when we successfully received the first error sent by your app.
For JavaScript projects, we also offer similar specific instructions for the framework and tools you use
A new dashboard
We've completely rebuilt the dashboard from scratch. You'll immediately notice that we added a big error graph and the most important metrics for each project.
Fear not; if you rather have a simple list of all your projects, you can pick that list view at the top.
As you can see above, we've added a visual distinction between your projects' different stages and languages. A project can be set as production, staging, development, or local, each with its own color.
The new error list
When you open up one of our projects, you'll see all the errors for that project. The error list is completely revamped.
On top, you can see a graph showing the total of errors received at a time for that project. You can drag a period on that graph, and in the list, we'll only show the errors that occurred in that period.
You'll notice that we now also show graphs for all individual errors, so you better understand when and how often they occurred. When you hover one of the bars, you'll see the exact timeframe and error count.
On an error card, you'll notice that we add relevant, and sometimes Laravel-specific, info about that error. If your error occurred in a web request, we show the controller.
If it happened in an Artisan command, we show that command.
On the error cards, you'll find buttons to mark the error as resolved and snooze notifications. You can't see this visually, but we're using optimistic mutations when you use one of the buttons. That means when you click the button, you'll immediately get visual feedback that the error is resolved/snoozed; we don't wait for a positive response code from our internal API. This will make our UI feel lightning-fast.
The revamped error screen
Next, let's look at the screen you'll see when clicking on one of the errors in the project's error list. It's arguably the most important screen of Flare: here's what the error details screen looks like.
You can see that it's completely revamped. We start by showing the same error card with all details that you saw in the list.
When scrolling down, you'll see the stack trace of the error. It should feel very familiar, as it's rendered by the same component that also renders Ignition, the default Laravel error page.
When scrolling down some more, you'll see all the app-specific details, also shown in Ignition—a true treasure trove of information.
Error insights
Scroll back to the top of an error, and you'll see one of the most significant new features: error insights.
Using these insights, you can quickly see all the places where an error occurred and which of your users encountered it.
The URL insight shows a list of URLs where this particular URL was seen.
Each insight has a "Download CSV" button in the top right corner that allows you to download a list with results.
Let's take a look at a few other insights. Here are the jobs an error occurred in:
We think the users insight, which shows the list of users that encountered the error, will be very helpful. Here's a screenshot with fake, seeded email addresses.
AI Solutions
Flare already had solutions, which gave you some insight into the error and what might be the problem. We're now extending this list with AI solutions; these solutions will be generated using a GPT model.
Here's an error what occurred because there were too many connections to MySQL. The AI suggests some possible fixes and includes links to relevant documenation.
We're very proud of this feature and can learn more about how it works in the separate blog post on AI solutions.
Project switcher
An interface element that has got more common these years is a switcher. In our redesign, we added a simple project switcher you can invoke with Cmd+K on Mac or Ctrl+K on Windows, allowing you to jump quickly to another project.
No surprises there.
Simplified team management
In the previous version of Flare, you would have an overview of all the projects for all the teams you belonged to. Internally, this made grouping and sorting complicated.
Since only 2% of our users have more than one team, we decided to simplify this.
From now on, you'll see the projects for the team you're working in. Switching to another team can be done by clicking on your user avatar.
Technologies used
Flare is a love letter to the Laravel community. Behind the scenes, Flare is powered by the latest version of Laravel and PHP (at the time of writing, L10 and PHP 8.2). Of course, inside our codebase, we use a gazillion of our own packages.
Our payments are handled by Laravel Cashier and Stripe.
Our error ingress point is managed by Cloudflare. We use that service for authentication and spike protection.
The front end of our app is built us React, TypeScript, and InertiaJS.
Our admin panel, which is used to quickly look up customer info and impersonate users, is powered by Filament.
Though we started on Laravel Vapor, it was more cost-effective for us to use regular servers. These servers are hosted on Digital Ocean and provided by Laravel Forge.
In closing
We have put a lot of love into the Flare redesign, and we hope it shows. Of course, this is not the end of development on Flare. With the redesign launched, we can now concentrate on adding more features to Flare that are on our roadmap.
One of the bigger things we'll concentrate on is something not visible to our users. We've experimented with SingleStore and are pretty impressed by the performance improvements over MySQL it offers. We're going to experiment if we can improve the response times for Flare by making the switch to SingleStore. We'll be sure to write a few blog posts on that process as well.
Now is the perfect time to try out Flare. We support both PHP and JS projects. For Laravel apps, we've gone the extra mile: we recognize Livewire errors, for an error in a queue job, we display information about that queue, view errors will contain the decompiled Blade view, ... You can register here for a free ten-day trial; no credit card is required.
