How Appwrite integrated Raygun for bulletproof error reporting: lessons learned

This guest post comes from Appwrite, an open-source backend-as-a-service platform helping developers build secure apps faster. Appwrite chose Raygun’s API for direct, lightweight error reporting that avoids SDK bloat and dependency risks. In this post, they share their journey integrating Raygun, the challenges they tackled, and the impact on their production environment. We’re excited to share these insights from the Appwrite team!

Error reporting is essential for production applications that take quality seriously. In Appwrite’s early stages, we already knew the importance of a reliable error reporting system. Let’s see what we learned when we integrated Raygun into Appwrite, what issues we faced, and what we learned along the way.

Why did we choose Raygun?

We didn’t. We actually didn’t pick any error reporting service. Back when Appwrite started, all developers were self-hosting on their own machines, and we didn’t want to enforce a single service on everyone. In the very first iteration, we already knew we needed to support multiple error-reporting services. Raygun made it into our TOP 3 list thanks to a few reasons:

• Support for a wide variety of languages: aligning with our vision to meet developers where they are. Raygun supports JavaScript, Python, PHP, and Java, all popular choices among Appwrite’s developers
• Open-source SDKs, allow us to find answers when documentation isn’t enough
• Free trial, giving us just enough time to finish development free of charge

Additionally, Raygun offered us a free project that we can use for automated CI/CD tests, which was a nice bonus. We run it on every pull request to this day, and it gives us confidence that our implementation is stable.

Overhead of SDK library

Once you install SDK into your project, or any dependency in general, chances are there are more underlying dependencies. Which comes with even more underlying dependencies.. Which brings even more… You get the point.

One potential downside is the security vulnerabilities that can come from additional dependencies, which can increase the risk of exploits over time. Relying heavily on external libraries also means that you’re at the mercy of those libraries’ update cycles and support timelines, which can impact a project’s long-term stability.

Another concern doesn’t present harm at the beginning, but once it pops up, you rely on willing open-source developers to save you from sleepless nights digging through someone else’s code. Not only that but in the future, you might be missing a feature you need as your product grows, forcing you to switch to a different library and learn everything again.

Well, that was not the reason why we didn’t use Raygun’s SDK.

One of the core values for us as a company was owning the tech stack we use, to our best ability. Since then, this decision proved itself to be the right one multiple times. We managed to switch process managers, add scheduling support to the queuing system, and most recently, it allowed us to release Deno 2.0 serverless functions the same day the Deno version was released.

All of that goes to show the importance of not relying on third-party libraries. Additionally, we knew we wanted to support multiple error reporting services, and grow the list over-time. If we used the SDK for every service, the codebase would grow quickly, making our image unreasonably big.

Using Raygun API directly

Credit where credit is due. We barely had to look into Raygun SDKs because they wrote and maintained very good documentation for communicating with API directly. The Raygun API reference was just enough for us to understand endpoints and payloads.

Using the API directly helped us avoid extra dependency bloat, which would have come with using SDK libraries, ensuring that our overall codebase remained lightweight and easier to maintain.

We soon found out that using Raygun API is very simple.

Authorization consists of a singular X-ApiKey header. I personally like this approach compared to an authorization server with access and refresh tokens, because it’s so much easier to work with. With the addition of key rotation, it’s also a highly secure approach.

Reporting an error to Raygun is done using a singular POST /entries endpoint, with a JSON body containing all details of the error you have. While there are dozens of parameters to set, very few of them are required. This allowed us to make a very basic implementation reporting the most critical data, only using a small portion of Raygun features. Over time, we can add more features as our community asks for them, which will allow us to save time on initial implementation.

One downside we faced with API communication is the lack of patch operations, which allows servers to send multiple errors at the same time. To my surprise, we didn’t hit any rate-limitations or scalability issues since introducing Raygun support, so my fear was likely unfounded.

Raygun in CI/CD environment

As mentioned earlier, Raygun generously provided us with a free project for testing purposes. Our goal was to have an end-to-end test solution that ensured our implementation could successfully deliver error reports in formats created by our platform.

With barely any additional work compared to our typical E2E tests, the tests were running automatically. We used GitHub Actions alongside GitHub Secrets to run tests safely in the Cloud, and keep the Raygun API key protected. We managed to automate tests, ensuring error was reported properly, as well as ensuring validity of the payload we provide.

We now run Raygun E2E tests on every push made to our repository. We once managed to trigger a false Raygun spike protection, causing small chaos at 1 a.m., but it’s nice knowing Raygun has our back covered in case our API key ever gets leaked. In another instance, the tests caught an error that would have otherwise reached production, emphasizing Raygun’s critical role in our development pipeline.

Conclusion

Support emails: Zero. Incidents: Zero. Problems since initial integration: Zero.

Raygun has been a great partner for us. Considering our use case, setting it up once and not having to touch implementation ever since is the best scenario possible. While our reasoning for Raygun doesn’t fit most other products, we are very happy about the stability and backward compatibility Raygun provides.

Raygun support

If you have a question about Raygun, Raygun API or their products, you can contact the support team here or read Raygun’s documentation.

Not a Raygun customer? Try out the full Crash Reporting application free for 14 days!

Curious to see how Appwrite can support your development workflow? We’re offering Raygun readers a $50 credit to explore Appwrite Pro and get hands-on with our suite of backend tools. Try it out, build something new, or test a few features. You can redeem your credit here.