Hey, I’m on Cloudflare’s Developer Advocacy team — this is a top priority for the Pages team right now and big improvements to the build time are being actively worked on!
Wow, this looks so awesome! Really simple UI too — gonna have to give this a try. I was just struggling with some client-side image upload stuff last week, and I love the idea of doing the full service integration from client to backend as a product.
BTW - I’m part of the dev advocate team at Cloudflare, would you want to chat sometime about your experience with Images? Definitely would love to hear your perspective as a dev on what could be better!
Pages has actually been GA since April of this year[1] - since then, we've released support for deploy hooks, redirect/custom header files, GitLab support, and as you mentioned above, a Workers function integration.
We have a really excellent team building Pages, and we still think there's a lot of unexplored territory around Pages/Jamstack and how it interacts with serverless and edge functions. Exciting times!
The story around types in Workers should be leaps-and-bounds better than it was a few months ago (thanks to the work outlined in this blog post) - would love to hear your thoughts on this new work, and hope it helps!
Quick plug I'll drop in here (I manage Cloudflare's Developer Advocacy team) - in addition to Durable Objects reaching GA, we also released a great open-source codebase today to help scale your Durable Objects-based projects.
It has built-in sharding and communication between connections/shards - basically how we would recommend people build with DO if they want to hit the ground running.
hey, kristian from the workers team here - i wrote these docs, so this is good feedback :)
we don't have any plans to get rid of workers sites! but we do think that for most people deploying static sites, pages is a better fit than workers sites.
when we do talk about the future of pages versus workers sites, we're generally talking about making it easier to deploy serverless functions /with/ your pages sites - providing better tooling and DX around that is a super high priority for us.
the interplay between workers serverless functions and static asset serving via workers sites is still a really strong use case (and IMO a thing that workers is uniquely capable of doing) that we don't have any plans to shelf. again, i wrote the docs here so this is on me if it came across as "we're getting rid of workers sites" - i'll take a shot at improving these docs and helping clarify that next week!
I haven’t officially launched it yet, but starting to build up the Twitter (https://twitter.com/@jobsindevrel) and the mailing list so that when there is some actual traffic coming in, it should (ideally) be profitable pretty quickly. Hoping to launch this month!
Working on https://jobsindevrel.com, a job board for developer advocates and devrel jobs. So far it’s only cost ~$310: $300 for a nice lifetime deal on the job board software and $10 for the domain.
I haven’t launched it yet, but starting to build up the Twitter (https://twitter.com/@jobsindevrel) and the mailing list so that when there is some actual traffic coming in, it should (ideally) be profitable pretty quickly. Hoping to launch next month!
you can definitely do something similar with workers sites.
we recently added workers kv - the storage mechanism behind workers sites - to our free workers tier, so you can host your static sites on workers for free as well.
pages is an evolution of that with better tooling/dx for people who want to get a static site up on our network and want things like deploy previews and pre-configured github integration.
if you want to just have workers do the hosting and want to do all the CI stuff yourself, you can use something like wrangler-action[1] to simplify the process on github actions, or just install wrangler[2] (our CLI) as part of your CI workflow and do `wrangler publish` at the end.
i wrote our github action, so if you decide to go that route, happy to help debug or look over the project to make sure it'll do what you want - i'm @signalnerve on twitter, DMs are open :)
Not parent commenter, but Ghost is a pretty great way to “own your stack” - custom domain, software is open-source, supports paid memberships, and it can send blog posts as newsletters. (No association with Ghost either - just a happy user)
I wrote a blog post on how to accomplish a Stratechery-style newsletter/blog with paid memberships on my blog[1] — you can hook into Zapier so there’s lots of opportunity to build a full community around Ghost’s built-in membership system, in case you want to send Slack invites, add them to a Mailchimp newsletter, etc.
agreed on all of this - Slack is really tough to build a community on top of! Kurt’s quote in that post is very true; the moderation/role stuff in Discord makes it super appealing for building any sort of large community.
i’ve been working on a new discord server for people building mailing lists[1] and newsletters and built out an opt-in software channel section where people can opt into #mailchimp, #convertkit, etc. channels without any sort of moderation/admin input needed. it’s a really nifty “self-serve” thing that i’m pretty sure i wouldn’t have been able to pull off with slack.
fully expecting “discord communities-as-product” to be a big thing over the next few years as they’ve built a great platform to do that sort of thing.
hey hn! i'm the author of this tutorial, here to answer any questions.
as i wrote on twitter [1] i'm super excited about complex and interesting stuff like user authorization/authentication on the edge, and this tutorial was written after doing some explorations on that front over the last few months.
i'm particularly excited about one of the later parts of the tutorial, which shows how to take user info from auth0 and inline it directly into your application using Cloudflare Workers' streaming HTML rewriter. it's a very cool way to dynamically inject data into your static applications at the edge!
this is a really awesome improvement - a bunch of my projects all deploy w/ actions using the same api token to cloudflare workers (using wrangler-action[1]), so this makes it super easy to add new projects or re-roll the key without having to go in and change each project's config.
btw, if you're looking for an intro to github actions, i put out a video last december covering publishing your first github action workflow: https://youtu.be/J4EhgEskSZA