• Cloudflare now supports cache invalidation for all plans. Nice! Not only that, purging the cache now takes 150ms for P50, which is insane 😮😮😮 the global cache is cleared with 150ms, which is incredibly fast. The whole architecture behind was so complicated but interesting.

• RUM (“Real User Measurements”) is a Cloudflare feature, the default behavior is to inject a JS snippet into the website for monitoring and analytics. This is good since traditional analytics solutions like GA are cumbersome and laggy and require cookie consent. I don’t like any banner on my site for cookie consent, that is fundamentally inefficient from my point of view. Also, very bad UX. I saw this term the first time when I migrated my site from using Firebase Hosting to Cloudflare pages. I love the way how Cloudflare makes it seamlessly. Lighthouse on my cloud without any configuration, this is awesome.

• Today I found a new use case when Hasura is powerful. It's nothing new but with a creative approach, it saves tons of time for bullshit REST. And it deserves a separate section for it. It’s popular when building a GraphQL API but for webhooks, not many.

---

Build a webhook system with Hasura

I was surprised when nobody ever talked about this, searching Google doesn’t help, and Claude 3.7 doesn’t give exact any use case related to this.

Let’s imagine the scenario when we need to implement a webhook system, it’s just a very basic

• We will configure the listener URL in our system

• When a desired event occurs, we send an HTTP request to the above URL

Nothing complicated here until the implementation part. The bullshit part is RESTful API design. It was terrible. I’m working with a Rails application for this, and it was very awful.

Rails has something called Serializer, basically, it’s just a mapping of one object to another object, and we use it to respond to the client (mostly the frontend).

The terrible part is we need to manually these serializers (mapping) in code, we need code review, and because it was in the code, we re-deploy the code whenever this shit changes.

When I need to add one single field, I need to deploy the code.

When I need to remove one single field, I need to deploy the code.

When I need to rename a field, I need to deploy the code.

This is very frustrating and a waste of time, I can’t believe why we still do this shit nowadays when GraphQL was released in 2015. It’s 10 fucking long years now.

Before this approach, I searched for good and big design systems like Shopify, and Stripe to learn how they handle this problem. We all know how big Shopify is, and Stripe is considered a well designed system.

• Shopify using a config file (yaml file at the time I read their documentation today)

• Stripe doesn’t allow to customize the payload

They’re still REST. I don’t know how Shopify handles the config file under the hood. If it doesn’t need to redeploy the code, that’s fine. However, we need to manage the config file ourselves.

The question is WHY? Why do we need to do that?

We are the webhook sender, we don’t know what the receiver actually needs, what we can do is try our best to guess what they want. When they need some field, let them do it by themself, or at least, we don’t need to redeploy the code. I don’t understand what’s the point of redeploying the code here, is there any logic changes? Fucking ridiculously stupid.

With GraphQL, we don’t even need a line of code for these serializers (mappings). Here is the way we would do

• Using GraphQLi to select the data we designed in visual, not in code.

• Save the query into the database (it’s just a string, again, A STRING)

• Before you send the request to the listener server, load the query from the database, and call a GraphQL query. Now we get the data

With Hasura, this is mostly straightforward, no fucking pain in the ass, no line of code, not only for these Serializers, but also for GraphQL resolvers, etc.

Here is what things look like with Hasura.

The cons of this approach is higher network latency regardless of how we set up our backend server, our database server, and our Hasura server.

Okay if you want to remove those latency? There is a way.

The key part here is the query string that we stored in the database, not in the code. So we don’t need to redeploy.

Now when you understand that, we can have a hack like this

• Using Hasura UI to generate the query for the data you want

• Use a tool like “Hasura explain” to convert that query to raw SQL, store this raw SQL in the database

• Now in the backend server, just execute this SQL to get the data

I’m not sure this even works, but I won’t give it a try. I don’t want to look at the raw SQL while I can understand the query string.

Okay, you may ask, how often does the webhook data change? If it rarely changes, is it worth the cost of network latency?

Well, for me, this is not the main concern. No technical solution is perfect.

My main concern here is the mindset of how we deal with the problem.

If you think redeploying the code even with no logic changes is good, it’s up to you, you need to manage that code (okay you may call converting full_name to fullName is a logic, that’s fine, but I don’t see any “logic” of what “logic” means here). I don’t see any good reason for doing that. The code I want to manage is the business logic, not the code that we can automate. If you are certain that in the next 5 years, you won’t change those things, keep your work. For me, even spending only 1 minute for them during 5 years of development, is still a waste of time.

Is no code better? Not exactly true, but the fact is, I don’t want to touch my own code after 1 year, but the SAAS still keeps the same API over many years. Why don’t you code a payment gateway for yourself instead of using Stripe? Regardless of the solution, for me, reliability means less maintenance, and lasting longer.

---

References

• https://blog.cloudflare.com/part1-coreless-purge/

• https://blog.cloudflare.com/rethinking-cache-purge-architecture/