Gerhard

Our usage, okay.

Our usage, okay.

So let's talk through the roadmap. Okay. We have it right in front of us. We've added tests. We know there's more that we need to do here. But the same number of VCR lines, so that's still there. The functionality hasn't changed. The feeds backend, the only reason why this is not done is because I wanted to do pipely.tech. I thought that was a cool idea. That's the only reason.

So let's talk through the roadmap. Okay. We have it right in front of us. We've added tests. We know there's more that we need to do here. But the same number of VCR lines, so that's still there. The functionality hasn't changed. The feeds backend, the only reason why this is not done is because I wanted to do pipely.tech. I thought that was a cool idea. That's the only reason.

I did part of it, by the way. This now works. It didn't used to work, the feed XML. Now this loads. We only had HTTPS. So I've taken small steps towards it, but it's not complete. The reason why we need HTTP and not HTTPS is because we're using the open source varnish, and that does not terminate TLS. So we can only connect to HTTP backends. That's something that we discovered the hard way.

I did part of it, by the way. This now works. It didn't used to work, the feed XML. Now this loads. We only had HTTPS. So I've taken small steps towards it, but it's not complete. The reason why we need HTTP and not HTTPS is because we're using the open source varnish, and that does not terminate TLS. So we can only connect to HTTP backends. That's something that we discovered the hard way.

So this, in terms of configuration, we're talking a few hours to get it all done. Lift it from our existing VCL and maybe do a few changes, right? Because this already exists as VCL in our Fastly config. Then sending logs to Honeycomb, this again, a day, roughly.

So this, in terms of configuration, we're talking a few hours to get it all done. Lift it from our existing VCL and maybe do a few changes, right? Because this already exists as VCL in our Fastly config. Then sending logs to Honeycomb, this again, a day, roughly.

It's just like, I'm just basically making stuff up because I don't, only once you pick it up, you realize how much, like all the rabbit holes.

It's just like, I'm just basically making stuff up because I don't, only once you pick it up, you realize how much, like all the rabbit holes.

So it's more around making sure that we send logs to Honeycomb so that we can understand what's happening in the system. We want to keep the same structure as Fastly so that all the queries will work. So there'll be like no interruption of service or like no big changes. So that's why I mentioned this. We just need to have some way of sending all the request logs to Honeycomb.

So it's more around making sure that we send logs to Honeycomb so that we can understand what's happening in the system. We want to keep the same structure as Fastly so that all the queries will work. So there'll be like no interruption of service or like no big changes. So that's why I mentioned this. We just need to have some way of sending all the request logs to Honeycomb.

That's what I mean by this. We also need to send logs to S3. This is something that Jared mentioned last time when we talked about pipe dream and the roadmap. So we need, for stats, we need to set, just like to keep the compatibility, right?

That's what I mean by this. We also need to send logs to S3. This is something that Jared mentioned last time when we talked about pipe dream and the roadmap. So we need, for stats, we need to set, just like to keep the compatibility, right?

Is there any reason to not do that? It doesn't matter where we send the logs as long as we send logs to an S3 compatible API. Gotcha.

Is there any reason to not do that? It doesn't matter where we send the logs as long as we send logs to an S3 compatible API. Gotcha.

Interesting.

Interesting.

Exactly. Yeah. So once that's why we do like the first part, which seems a bit easier to just send the requests, it doesn't matter which way you do them, honestly, but this will ensure that the service behaves the way it should. And I think this is more valuable from a functionality perspective. Then fairly hard to implement purge across all app instances. I say fairly hard.

Exactly. Yeah. So once that's why we do like the first part, which seems a bit easier to just send the requests, it doesn't matter which way you do them, honestly, but this will ensure that the service behaves the way it should. And I think this is more valuable from a functionality perspective. Then fairly hard to implement purge across all app instances. I say fairly hard.