Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno Queues

deno.com

Post reply on HN
Print view View original

81–90 of 168 posts

Re: Deno Queues

#81

Post by jallmann »

paxys wrote: post #14
nmca wrote: post #7

I 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 use Deno because I couldn't be bothered to figure out the Node ecosystem and how to actually wire together the Typescript compiler, package json, builders and bundlers, etc. I just do not care and the mess of tooling is frankly exhausting to wade through.

Deno Just Works for me. `deno run file.ts` and you are good to go.

Not to say it's been 100% smooth sailing; I have hit a few rough patches with deployment into my own infrastructure (some within Deno and its dependency management, some within libs like sqlite3) but overall I am happy to not deal with nodejs.

Re: Deno Queues

#82

Post by johnspurlock »

zoogeny wrote: post #36

I think what Deno is aiming for here is actually very forward thinking. I'm using Go for the first time this year and some aspects of the language are very C like. Of the list of things that isn't C like (e.g. GC allowing one to return what look like stack allocated pointers from functions) there is the obvious inclusion of things like `map[string]string`. I bring this up because it struck me that inventing a languag…

In this case, they've also documented the remote connection protocol: "KV Connect" https://github.com/denoland/deno/tree/main/ext/kv#kv-connect

I kicked the tires on this with a pure TS implementation of the protocol called kv-connect-kit that gives you the KV client api in any Javascript runtime (including Cloudflare workers, which does not have anything Deno namespace related)

- github: https://github.com/skymethod/kv-connect-kit

- npm: https://www.npmjs.com/package/kv-connect-kit

- deno/x: https://deno.land/x/kv_connect_kit

- demo: https://keyspace.deno.dev/

protocol seems to works as described on the tin, and it would be pretty straightforward to write another backend

Re: Deno Queues

#83

Post by lopatin »

leptons wrote: post #80
asim wrote: post #20

Earlier quoted context omitted.

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…

If Deno is only going after amateur devs by implementing simplistic features like this, then it will remain an amateur product. AWS/SQS may seem complex to some, but they are very powerful. Maybe Deno is doing what Apple did in the 80's by putting free Apple computers in classrooms - try to get new users hooked into their system and then they'll use it for life. Anyone doing anything serious with cloud computing is a…

Devs who know they need an event queue but are not technical enough to set one up in SQS sounds like a very niche market to me.

Re: Deno Queues

#84

Post by vineyardmike »

paxys wrote: post #38
zoogeny wrote: post #36

I think what Deno is aiming for here is actually very forward thinking. I'm using Go for the first time this year and some aspects of the language are very C like. Of the list of things that isn't C like (e.g. GC allowing one to return what look like stack allocated pointers from functions) there is the obvious inclusion of things like `map[string]string`. I bring this up because it struck me that inventing a languag…

I disagree. Tying a language runtime to a specific KV interface which is tied to a specific hosted service is the opposite of forward thinking. In fact the tech industry has made a lot of progress away from vendor locked-in stacks, and this just reminds me of those. What is really the difference between Deno.KV being shipped as part of the runtime vs adding an `import KV` statement at the top of the file (which could…

> If Google started adding Google Cloud specific primitives natively to Go would you call that forward thinking as well?

Go actually ships with a quite forward thinking SQL interface. It's an abstract interface over a DB, and you just import the "driver" that powers it. The driver conforms to a standard interface, so all of them behave roughly the same.

I think this is what everyone wants from Deno/etc - why can't there also be a KV interface that's universal, or a Queue interface that's universal?

People attempted this w/ go [1], where it attempts to use the same nice experience of the SQL logic, but it never seemed to gain traction.

https://gocloud.dev

Re: Deno Queues

#85

Post by zja »

dsherret wrote: post #71
paxys wrote: post #38

Earlier quoted context omitted.

I disagree. Tying a language runtime to a specific KV interface which is tied to a specific hosted service is the opposite of forward thinking. In fact the tech industry has made a lot of progress away from vendor locked-in stacks, and this just reminds me of those. What is really the difference between Deno.KV being shipped as part of the runtime vs adding an `import KV` statement at the top of the file (which could…

> Tying a language runtime to a specific KV interface which is tied to a specific hosted service is the opposite of forward thinking. This is not the case. The Deno runtime itself is not tied to the Deno Deploy hosting service. The KV feature in the Deno runtime can be used without the hosting service. You can read the details about how Deno KV works in the Deno runtime here: https://til.simonwillison.net/deno/deno-k…

> The KV feature in the Deno runtime can be used without the hosting service.

But one writes to foundation, and the other writes to a sqlite file. You wouldn’t be able to self host an app written for Deno Deploy and have it work out of the box.

Are there any plans to open source the KV backend so that people could host their own KV databases? Now that you can connect to remote Kv databases, I suppose someone could implement their own?

Re: Deno Queues

#86

Post by simonw »

Unless I'm missing something, it looks like each Deno.openKv() instance only gets a single queue.

For the local version you could get multiple queues by calling Deno.openKv("db-2.db") with different SQLite file paths each time, but that feels like a lot of overhead for a pretty common need.

I guess this is a Deno architectural style thing - maybe when you build complex apps on Deno it's expected that you'll have a microservice style architecture where lots of different scripts work together, each of them with their own KV store and hence their own queue?

Re: Deno Queues

#87

Post by ljm »

zoogeny wrote: post #36

I think what Deno is aiming for here is actually very forward thinking. I'm using Go for the first time this year and some aspects of the language are very C like. Of the list of things that isn't C like (e.g. GC allowing one to return what look like stack allocated pointers from functions) there is the obvious inclusion of things like `map[string]string`. I bring this up because it struck me that inventing a languag…

Deno is just trying to compete with other JS/TS SaaS with this. Vercel/NextJS has a KV service now; Cloudflare has it; in other cases it's Firebase.

I contend that this is not actually forward thinking, but monetising Deno as a SaaS, which every man and his dog is doing in the JS world lately with their 'cloud' offerings (reselling AWS with a framework). That's why there is a pricing page attached to this.

If Deno's KV depends on FoundationDB then they're hardly going to build adapters over other databases - switching DB tech is always a massive ordeal because they all have different use-cases and performance characteristics.

Re: Deno Queues

#88

Post by dsQTbR7Y5mRHnZv »

rubenfiszel wrote: post #76
nesarkvechnep wrote: post #74

Earlier quoted context omitted.

Amazing syntax? Isn’t this standard JS chaining?

Exactly! It looks and feel like normal JS and hides all the complexity behind it which is the print of great syntax.

Perhaps "API design" would be more apt than syntax here

Re: Deno Queues

#89

Post by [deleted] »

simonw wrote: post #67

I dug into the internals of the local, SQLite version of this just now and wrote up some notes here: https://til.simonwillison.net/deno/deno-kv#user-content-deno... The most interesting detail is probably the schema they're using for that: CREATE TABLE queue ( ts integer not null, id text not null, data blob not null, backoff_schedule text not null, keys_if_undelivered blob not null, primary key (ts, id) ); CREATE TA…

[deleted]
Post reply on HN