hey Andy from Deno here. thanks for your comment. we reduced our Deno Deploy regions not because Deno is in decline. (in fact we have seen about 2x adoption since release of Deno 2.) it's just that we noticed more users using Deno Deploy for hosting applications vs. edge functions, which was our original vision for Deploy. in many scenarios, application performance is improved with fewer, more highly trafficked regions vs. many spread out but more idle regions. we will be covering that in more detail in a dedicated blog post next week.
hey HN, i'm Andy, part of the Deno team. we're really excited to get a release candidate out there for what will soon become 2. it's been a long road to get here and we're really just beginning. happy to answer any questions!
hey gang, andy from deno here. we're really excited about the possibilities of this API, especially around building real time applications or pushing UI changes to the client without a page reload.
we're looking for feedback and happy to answer any questions!
hey hn, andy from deno here. from working with larger companies interested in using our v8 isolate cloud infrastructure, its no surprise that terraform is a preferred approach for reliably provisioning and managing many projects on Deno Deploy/Subhosting at scale.
we know our documentation is a bit sparse (we're working on it!), but we've included a walkthrough on how to deploy local code/assets to Deno Deploy via Terraform. we'd love to get any feedback. is this something you'd use?
pulling from an API / scraping data, sending emails/notifications/reports, backing up databases/snapshots, checking availability of various services, pinging website, pre-warm up apps/scale applications, various maintenance tasks.
You can use Deno KV locally - the underlying tech is SQLite. It's as simple as writing code and you don't need to spin up any databases or setup any connections.