Experiment with alternative CloudFlare deployment

[humphd]

Reading https://blog.polyhaven.com/how-we-handle-80tb-and-5m-page-views-a-month-for-under-400/ last night, I wondered if there is anything we could do to improve our situation, specifically explore using CloudFlare for more aggressive caching (front-end assets, but also lots of our API calls). You can do a lot for free with them https://www.cloudflare.com/plans/free

[humphd]

CloudFlare Workers could also be an interesting way for us to replace some of our microservices with serverless functions. I also see they just shipped a local-dev version that would make this interesting to experiment with https://blog.cloudflare.com/miniflare/

[aserputov]

@humphd How bad Redis is caching individual Post. Do you think Cloudflare can do our front-end caching better? What I mean exactly is if our quantiy of front-end data is enough to think of Cloudflare caching, or should I focus on serverless functions to replace microservices? As I understand, this topic is for the far future because we better get rid of our monolithic backed first and finally launch Parser service?

[humphd]

Redis is amazing at caching, that's its primary job. I would focus on caching static assets in the front-end to start.

[aserputov]

@humphd, do you want me to cache the static files from the 'out' folder after building the front end?

[humphd]

I'm not sure what you're asking, can you give more details?

[aserputov]

1. First of all, CloudFlare is amazing! Start from this. After, for someone who will start implementing Cloudflare into Telescope, here is the best video to do it in a few quick steps. Cloudflare has servers worldwide, but precisely for our problem, it doesn't matter. Most of the requests to our servers come from Canada(Toronto), which will make our caching accuracy close to 100%. We need to create a new issue or implement it here, to move all our static files from src/web/public by simple: 1.1. creating an account in Cloudflare 1.2. Add DNS server. 1.3. Add CNAME: "link to our static files server." You can watch the video above for more details.
2. Serveless Functions - is a cloud computing execution model in which the cloud provider allocates machine resources on-demand, taking care of the servers on behalf of their customers. "Serverless" is a misnomer in the sense that servers are still used by cloud service providers to execute code for developers. Do we need to add serverless functionality to Telescope? After researching the topic, I would say that time has not yet come to use them. I don't think there is a vast necessity. Maybe in future. If you believe the opposite, I will be glad to look more on different sides of Telescope collaboration with Serverless functionality.

[tpmai22]

@aserputov let's talk about this tomorrow

[JerryHue]

I would move this issue to release 3.0-alpha, since @aserputov provided some feedback which can help us to implement it. I don't think it is doable for 2.9 (kind of risky to do something like this in 2 days!).

[humphd]

https://github.com/dijonmusters/supabase-data-at-the-edge is a fascinating use case for Supabase + CloudFlare workers + K/V Storage.

[humphd]

I've read a few posts recently that have reminded me of this issue, and I would love to see us experiment with building an alternative, edge deployment using CloudFlare:

• https://www.indiehackers.com/post/cloudflare-made-it-much-easier-to-become-an-indie-hacker-16be255f6a
• https://taras.glek.net/post/cloudflare-pages-kind-of-amazing/

Doing so should allow us to slim down what we actually host on our own servers, and move a bunch of things to the cloud.

CloudFlare is also nice because unlike Vercel, building teams to work on something together isn't hard.

[humphd]

There's a bunch of stuff we could do with CloudFlare, but we haven't come-up with actionable use cases. Let's re-open if/when we do.