Introduction

For all the techies out there, we want to give more feature details regarding our web application, website, and everything in between!

Getting a web application to scale in production, while looking for dangerous bugs simultaneously and maintaining op-sec can sometimes be a daunting task.

It was really important for the team to release a proof-of-concept of our application before our mint. This first version was quickly developed by the initial developer just to show the world what our vision was and what we were capable of.

After our successful mint, we knew we couldn’t work with what was already in place because we felt it was —  to a large extent —  over-engineered for such a project. We decided that a rewrite would be the best course of action to ensure it tailor fit our needs.

Road to V1

Every project starts with a discussion about what stack a team could utilize – we needed something we were both familiar with. As our lead developer (Hayzam) is coming from a C/C++ background, he immediately gravitated towards the following technology stack:

Front-End

  • HTML5
  • VanillaJS
  • CSS

Back-End

  • Node.js with Express
  • MongoDB
  • EJS as our templating engine

Everything above plus the website and even the mint site was hosted on a single server (until V1)! It wasn’t a particularly powerful one, but it was well configured.

We also leveraged a lot of the features offered by Cloudflare such as caching, pages and workers to make everything run smoothly!

 

V1 Rankings Application Infrastructure Diagram

In V1 we only leveraged caching rules that we could set in Cloudflare, even with those rules we were not content with how the website performed. Ee knew we could do better hence the V2 scope-of-work started to take shape.

Road to V2

We needed to address the elephant in the room with V2… calling it a singular elephant would be a misnomer, “elephants” would be the ideal word to use.

Some of the issues that we really had to fix were:

  • Overall performance of the site
  • How user/wallet authentication was handled
  • Addition of features like voting and commenting
  • Discord alerts and additional goodies

There is a multitude of ways you could make a web application faster. Server-side rendering and caching is one of the best ways to achieve that goal. In frameworks like Next.js, these features are inherent but since we went old school with just vanilla node.js and JS on the frontend for the reasons aforementioned, we couldn’t easily leverage these features.

So we had to come up with our own ideas to implement an extensive caching mechanism.

You can see that the generation of static HTML is now a cron job. This means every few minutes the data is fetched from the database and stored in a super-fast Redis server as a rendered HTML file.

Now when a user visits app.radrugs.io, they will immediately get a response from the Redis database, instead of rendering it real-time. This shaved almost 2-3 seconds off of loading time from the site… which is amazing and exactly the kind of speed we were looking for!

The Authentication Problem

As you might already know, if you have 1 or more rugs you are eligible to use our premium section. Now the way the authentication is handled is quite tricky! Each time you “log in” essentially, we sign a small message with your Solana wallet and then send your address as well as this signed signature back to the backend.

Now verifying signatures is easy (once you get past the horrible documentation that exists for verifying signatures on Solana), but how do we verify that a person owns NFTs, or to make things further complicated: how do we know that they own RadRugs NFTs?

Well, the answer lies in using a custom Solana RPC API and A LOT of custom RPC querying code. The official RPC heavily rate-limits you to the point where it’s unusable. So we settled on using Quicknode‘s RPCs as our own. It has been incredibly fast, although a bit pricey. We might opensource our implementation of the NFT verification someday.

Now even querying the custom RPC each time a user logs in is insanely slow, especially if your users have hundreds of thousands of NFTs. So how do we mitigate it? You might have guessed it already based on our usual way of fixing things… caching!

Every 30 minutes, the backend queries all the mint addresses and fetches their owners, and stores the owners along with their rug IDs into the Redis cache. This is the reason why the login takes just milliseconds instead of seconds or even minutes!

Addition of Commenting and Voting into the Premium Section

Commenting and voting are part of the premium section of the application, both can be done by anyone with over 1 RadRug NFT. The authentication we use for voting and commenting is similar to the login authentication, where the users sign and send us their signature. We verify their signature and address on the backend and then we are all good to display it to other users!

We make use of a commenting engine known as remark42, which is hosted on a separate docker instance. It uses boltDB as its database and integration with it on our application has been excellent!

Discord Alerts and Smaller Goodies

Some smaller things we did for V2 are widgets on the website and discord alert. We use hooks for sending out messages to a channel on our discord server whenever a new audit has been published.

Conclusion

You can see all of these technologies in action by accessing our Project Reviews application: https://app.radrugs.io/

If you’re not a holder yet and would like to join our awesome community, you can buy RadRugs NFTs on MagicEden. 3 NFTs give you access to the Premium section of our reviews, with in-depth analysis and advanced metrics.

Thank you for your support!


Community 👋

If you have any questions or comments, feel free to contact us: