(on the off chance the devs read this) I can see pain in the future for the currently excellent KV ergonomics around access control --- is the solution just "implement it in userland and don't write bugs" or is there anything planned?
Deno Queues
11–20 of 168 posts
Re: Deno Queues
#12I don't want my programming language to "implement" task queues and charge me for it. What is this edit: people seem to be getting hung up on the "runtime" v "programming language" distinction. I'm not sure why--it's weird to me that this is "part of the language + runtime" at all. Clearly, reasonable people can disagree about that, but hopefully on points more substantive than pedantic If tomorrow, someone started a…
You're getting charged for the replication of deno kv across all regions when you use deno.deploy. KV is free to use locally as I assume this will be too.
Sure, but genuine question: How easy it is to run my own infrastructure for Deno Queue, and, crucially, how can I know that it will still be as easy and transparent in 5 years from now when the VCs want to see some $$$. That the company developing Deno and the services that monetize Deno is the same is a major conflict of interest. And if history is of any guide, in the end economic incentives always win, no matter how good-hearted people are.
Re: Deno Queues
#13Earlier quoted context omitted.
You're getting charged for the replication of deno kv across all regions when you use deno.deploy. KV is free to use locally as I assume this will be too.
Sure, but genuine question: How easy it is to run my own infrastructure for Deno Queue, and, crucially, how can I know that it will still be as easy and transparent in 5 years from now when the VCs want to see some $$$. That the company developing Deno and the services that monetize Deno is the same is a major conflict of interest. And if history is of any guide, in the end economic incentives always win, no matter h…
If Deno doesn't get adequate funding, the company developing Deno will not exist 5 years from now.
Re: Deno Queues
#14I find deno to be very exciting. Viable business model, great ergonomics, glorious lack of bullshit configuration busywork.
I have tried to be excited about Deno, but just don't see it. What are they doing that hasn't already been done a hundred times in the past? Deno itself is essentially Node.js + automatic TS compilation (which would otherwise have been 1 extra config file). When the project launched they made a big deal about escaping from the messy NPM ecosystem, but then ended up having to turn around and add support for it, taking that differentiator away as well. Deno Deploy is the same as dozens of other Lambda-like services out there. Their KV store and now Queues is equivalent to Redis/LevelDB/RocksDB/Dynamo/SQS or countless similar options. I have yet to come across a single feature that actually sets Deno apart from the rest.
I could maybe see the appeal if you prefer to have a single company in charge of your language runtime + compute hosting + data storage, but I'd personally want to avoid that, especially when the company doesn't have a track record in it.
Re: Deno Queues
#15(on the off chance the devs read this) I can see pain in the future for the currently excellent KV ergonomics around access control --- is the solution just "implement it in userland and don't write bugs" or is there anything planned?
User-level access control (like ACLs for authenticated users) or something else? Feel free to share longer form thoughts here and I can make sure we keep this concern in mind.
Re: Deno Queues
#16I don't want my programming language to "implement" task queues and charge me for it. What is this edit: people seem to be getting hung up on the "runtime" v "programming language" distinction. I'm not sure why--it's weird to me that this is "part of the language + runtime" at all. Clearly, reasonable people can disagree about that, but hopefully on points more substantive than pedantic If tomorrow, someone started a…
You're getting charged for the replication of deno kv across all regions when you use deno.deploy. KV is free to use locally as I assume this will be too.
I guess I remembered it incorrectly? This looks pretty good:
> Deno KV databases are replicated across at least 6 data centers, spanning 3 regions (US, Europe, and Asia). Once a write operation is committed, its mutations are persistently stored in a minimum of two data centers within the primary region. Asynchronous replication typically transfers these mutations to the other two regions in under 10 seconds.
Re: Deno Queues
#17> Leveraging public cloud infrastructure has traditionally demanded sifting through layers of boilerplate code and intricate configurations, often monopolizing a significant chunk of the developer’s time and energy.
I don't buy this line of reasoning. At the end of the day we are building infrastructure that needs to be reliable. Spending 30 minutes to set up an SQS queue (proven technology) doesn't sound as bad as putting all my trust in a toy queue that Deno built "on top of SQLite / FoundationDB". Is the 30 minute setup cost and added "developer experience" really worth the risk? How often are you setting up queues anyway.
Re: Deno Queues
#18I find deno to be very exciting. Viable business model, great ergonomics, glorious lack of bullshit configuration busywork.
I have tried to be excited about Deno, but just don't see it. What are they doing that hasn't already been done a hundred times in the past? Deno itself is essentially Node.js + automatic TS compilation (which would otherwise have been 1 extra config file). When the project launched they made a big deal about escaping from the messy NPM ecosystem, but then ended up having to turn around and add support for it, taking…
I'm not that familiar with these alternatives. What's a good service provider you recommend for a persistent KV store?
Re: Deno Queues
#19> Leveraging public cloud infrastructure has traditionally demanded sifting through layers of boilerplate code and intricate configurations, often monopolizing a significant chunk of the developer’s time and energy. I don't buy this line of reasoning. At the end of the day we are building infrastructure that needs to be reliable. Spending 30 minutes to set up an SQS queue (proven technology) doesn't sound as bad as p…
> How often are you setting up queues anyway.
Very infrequently. Even more infrequently as we move to IAC and use terraform or even cloudformation.
Re: Deno Queues
#20> Leveraging public cloud infrastructure has traditionally demanded sifting through layers of boilerplate code and intricate configurations, often monopolizing a significant chunk of the developer’s time and energy. I don't buy this line of reasoning. At the end of the day we are building infrastructure that needs to be reliable. Spending 30 minutes to set up an SQS queue (proven technology) doesn't sound as bad as p…
Many people don't have experience with AWS or SQS and even those that do will still need to think about it. Deno is taking a batteries included approach which means the Dev can just import something and go. If someone provided equivalent libraries for the cloud then I'm sure people would adopt them. In the case of Deno I'm sure they've identified a common problem many Devs in their ecosystem have and are tackling it by bundling in a good solution.