7 ms·

"Deno KV" looks uncomfortably shoehorned into Deno. Some people are of course gonna use it if it's built in, but it doesn't look something that a good language/

"Deno KV" looks uncomfortably shoehorned into Deno. Some people are of course gonna use it if it's built in, but it doesn't look something that a good language/platform would ship with, if it wasn't for the money.

satvikpendem 2y ago
Seems like these companies want to be like Vercel or Supabase, a full backend as a service where you just write code and deploy and the backend handles everything for you.
- BoorishBears 2y ago
  Doesn't just seem like it, follow Guillermo Rauch's investments. The same game plan every. single. time. Get into the JS developers' zeitgeist, wrap an existing cloud service with a new frontend, sell it at a markup. Bonus points if the services can sell for each other.
  - satvikpendem 2y ago
    True, however the DX is outstanding for Vercel, and the price is pretty decent enough, even though I know they all just wrap AWS. If I don't have to deal with AWS, I would (and do) pay extra to not do so.
    - BoorishBears 2y ago
      Vercel is not a problem. Pumping millions of dollars into the JS ecosystem through sponsorships and events to define the development landscape in terms of what helps your bottom line... that's bad. React has RSC because Vercel wanted to fight Shopify. NextAuth was practically bought out by Clerk to serve as sales funnel. <img> tags are marked as "not good" by a leading React framework because the hosting provider behind it wants you to pay them for image optimization. What Rauch is doing is the developer equivalent of private equity squeezing, and what's insane is how well it's working.
      - satvikpendem 2y ago
        Eh I'll disagree with much of that. RSCs are amazing and basically what I've been looking for for quite a while, using TypeScript and JSX as a templating language for HTML, as I used to use PHP, but in a much safer way. Similarly, the image optimization is a good thing too, not necessarily that it goes through Vercel's servers but good in general. Dealing with srcsets with many images can be a pain and you can always use alternative image optimizer too, even open source local ones like sharp. Finally, there are lots of alternatives to what you're stating, no one forces you to use NextJS over, say, Remix or Vite with SSR. You can even not use React at all, or even JS / TS, there are lots of languages that compile HTML together.
        BoorishBears 2y ago
        You're free to disagree but you didn't disagree at all. No one is saying they're not useful at all, the problem is Vercel (or really Rauch's entire cartel of companies) strong arm different technologies and topics to fit a narrative that's disproportionately in favor of "use our thing". RSCs are not amazing if you're not Vercel and don't have access to their closed build format (especially after they killed the serverless output format) I use image optimizers, I'm not about to go around telling people that img tags are bad. > Finally, there are lots of alternatives to what you're stating, no one forces you to use NextJS over, say, Remix or Vite with SSR. Remix had to reject RSCs to start because as one might expect, having one (1) design partner doesn't make for the most fully baked proposition. Also the "there's other choices" refrain ignores the fact that no one is developing in a vacuum. Vercel is pumping enough money into the ecosystem that the mindshare is shifting towards Next regardless of technical merit. So it's not enough to say "who cares if Vercel distorts what Next is, just use something else"
        satvikpendem 2y ago
        Remix is adding RSCs in the future, they've already stated. And Vercel isn't as big in influence as you think, many are also having problems with NextJS that are causing them to go elsewhere such as Vite or Remix as I mentioned. There is no monopoly in the frontend.
    - threatofrain 2y ago
      The DX used to be outstanding for Vercel, but for any new micro-cloud product some story of github-to-deploy or even drag-folder-here is now table stakes; look at Cloudflare for example. Vercel still has the best website dashboard for the other parts of running a website that isn't just deployment. One problem I saw with Vercel, and a reason why I steered people away, was that they were very slow to react to some of the challenges of serverless workflows, like building their own in-house services to reduce latency or allowing different kinds of serverless tiers for longer-lived workers. You could hit growing pains almost instantly.
hpeter 2y ago
Yes, vendor lock in. That's why you need to be careful what you use it for. You rely on it too much, you can't get away from it and can end up costing you a lot of money with the pay per request pricing. I don't want to write negatives about it, it's a well thought out product. But it 's not free. It is a paid service at the end and that is fine as long as you know what you are getting into.
- nimchimpsky 2y ago
  [dead]
galaxyLogic 2y ago
I guess the question is, is the interface to Deno-KV specified well enough that it could be replaced by another back-end? Is it a "replaceable part"?
jshen 2y ago
"it doesn't look something that a good language/platform would ship with" Why do you think that?
- nextaccountic 2y ago
  They have a huge incentive to not publish an open source backend that can run locally and isn't sqlite, to inhibit you from actually using Deno KV in production (past from the sqlite limits) outside of their cloud. Check out this quote from the OP: > So, we set out to build two versions of the Deno KV system, with the same user-facing API. A version of Deno KV for local development and testing, built on SQLite, and a distributed systems version for use in production (especially on Deno Deploy). This post is about the implementation of the production, distributed systems version of Deno KV. If you’re interested in the SQLite implementation of Deno KV, you can read the source code yourself as it is open source. Intentionally crippled open source software for the sake of selling a cloud subscription really isn't a great feature Deno should ship. I think this situation is very different than Supabase. Supabase really publish the whole thing as Git repositories, and you can run it on your own servers if you wish.
evbogue 2y ago
As many of the comments here are getting at KV is best suited for making your app state available at all edge servers at Deno Deploy. You can also use localStorage in Deno but it won't synchronize the data between edge servers on Deploy, so you have to figure out another strategy. and of course KV works without Deploy, so while you don't get the data distribution benefit, you can still use KV on other deployment platforms. The alternative, of course, is to use another database. You don't have to use KV in your Deno apps. Maybe what people want here is the ability to configure their own data synchronization mirrors? Is that already implemented?
- youngtaff 2y ago
  Edge Servers seem to be one of the most misused terms in the JS ecosystem Anyone know were Deno’s “Edge Servers” are? Is it anymore than EC2 instances because it doesn’t seem to follow the Akamai, Cloudflare, Fastly type approach of actually deploying their own hardware PoPs at the edge
  - evbogue 2y ago
    and don't get me started on "Serverless" which often involves servers to my own befuddlement.
vvpan 2y ago
Can a language that is not running on top of a VM pull this off? I do not think so? Which is why it seems to me we need to revisit JVM for example.
- ec109685 2y ago
  Why do you say so? It’s not that complex what Deno is doing (though I am not sure the complexity is needed over SQLite with replication).
afavour 2y ago
Welcome to the world of VC-driven tech ecosystems!
baq 2y ago
make it work, make it good, make it expensive.
- fidotron 2y ago
  For “good” meaning “we do all the sre/sysadmin stuff for you”. I am not sure it would apply for all the design decisions going in these things. I think it speaks to how out of control many sre groups are that people willingly spend so much on tools to avoid them. This has real echoes of how the cloud got traction as a way to avoid internal IT.
anonzzzies 2y ago
And most people don’t see through this; they become over the top fans, shoehorning it into every tech stack convo until they notice they are locked in (or change jobs) and then start the entire thing from start again with the tech du jour. Seems fine if you build stuff that is to survive 1-2 years at most, but how teams plan long term on this stuff, I don’t know. We have fast kv, easy to install, not vendor locked in and open source for a long decade+ time. I would like stable, not slightly more convenience that becomes inconvenient once you think about it enough.

satvikpendem 2y ago

Seems like these companies want to be like Vercel or Supabase, a full backend as a service where you just write code and deploy and the backend handles everything for you.

BoorishBears 2y ago
Doesn't just seem like it, follow Guillermo Rauch's investments. The same game plan every. single. time. Get into the JS developers' zeitgeist, wrap an existing cloud service with a new frontend, sell it at a markup. Bonus points if the services can sell for each other.
- satvikpendem 2y ago
  True, however the DX is outstanding for Vercel, and the price is pretty decent enough, even though I know they all just wrap AWS. If I don't have to deal with AWS, I would (and do) pay extra to not do so.
  - BoorishBears 2y ago
    Vercel is not a problem. Pumping millions of dollars into the JS ecosystem through sponsorships and events to define the development landscape in terms of what helps your bottom line... that's bad. React has RSC because Vercel wanted to fight Shopify. NextAuth was practically bought out by Clerk to serve as sales funnel. <img> tags are marked as "not good" by a leading React framework because the hosting provider behind it wants you to pay them for image optimization. What Rauch is doing is the developer equivalent of private equity squeezing, and what's insane is how well it's working.
    - satvikpendem 2y ago
      Eh I'll disagree with much of that. RSCs are amazing and basically what I've been looking for for quite a while, using TypeScript and JSX as a templating language for HTML, as I used to use PHP, but in a much safer way. Similarly, the image optimization is a good thing too, not necessarily that it goes through Vercel's servers but good in general. Dealing with srcsets with many images can be a pain and you can always use alternative image optimizer too, even open source local ones like sharp. Finally, there are lots of alternatives to what you're stating, no one forces you to use NextJS over, say, Remix or Vite with SSR. You can even not use React at all, or even JS / TS, there are lots of languages that compile HTML together.
      - BoorishBears 2y ago
        You're free to disagree but you didn't disagree at all. No one is saying they're not useful at all, the problem is Vercel (or really Rauch's entire cartel of companies) strong arm different technologies and topics to fit a narrative that's disproportionately in favor of "use our thing". RSCs are not amazing if you're not Vercel and don't have access to their closed build format (especially after they killed the serverless output format) I use image optimizers, I'm not about to go around telling people that img tags are bad. > Finally, there are lots of alternatives to what you're stating, no one forces you to use NextJS over, say, Remix or Vite with SSR. Remix had to reject RSCs to start because as one might expect, having one (1) design partner doesn't make for the most fully baked proposition. Also the "there's other choices" refrain ignores the fact that no one is developing in a vacuum. Vercel is pumping enough money into the ecosystem that the mindshare is shifting towards Next regardless of technical merit. So it's not enough to say "who cares if Vercel distorts what Next is, just use something else"
        satvikpendem 2y ago
        Remix is adding RSCs in the future, they've already stated. And Vercel isn't as big in influence as you think, many are also having problems with NextJS that are causing them to go elsewhere such as Vite or Remix as I mentioned. There is no monopoly in the frontend.
  - threatofrain 2y ago
    The DX used to be outstanding for Vercel, but for any new micro-cloud product some story of github-to-deploy or even drag-folder-here is now table stakes; look at Cloudflare for example. Vercel still has the best website dashboard for the other parts of running a website that isn't just deployment. One problem I saw with Vercel, and a reason why I steered people away, was that they were very slow to react to some of the challenges of serverless workflows, like building their own in-house services to reduce latency or allowing different kinds of serverless tiers for longer-lived workers. You could hit growing pains almost instantly.

hpeter 2y ago

Yes, vendor lock in. That's why you need to be careful what you use it for. You rely on it too much, you can't get away from it and can end up costing you a lot of money with the pay per request pricing. I don't want to write negatives about it, it's a well thought out product. But it 's not free. It is a paid service at the end and that is fine as long as you know what you are getting into.

nimchimpsky 2y ago
[dead]

galaxyLogic 2y ago

I guess the question is, is the interface to Deno-KV specified well enough that it could be replaced by another back-end? Is it a "replaceable part"?

jshen 2y ago

"it doesn't look something that a good language/platform would ship with" Why do you think that?

nextaccountic 2y ago
They have a huge incentive to not publish an open source backend that can run locally and isn't sqlite, to inhibit you from actually using Deno KV in production (past from the sqlite limits) outside of their cloud. Check out this quote from the OP: > So, we set out to build two versions of the Deno KV system, with the same user-facing API. A version of Deno KV for local development and testing, built on SQLite, and a distributed systems version for use in production (especially on Deno Deploy). This post is about the implementation of the production, distributed systems version of Deno KV. If you’re interested in the SQLite implementation of Deno KV, you can read the source code yourself as it is open source. Intentionally crippled open source software for the sake of selling a cloud subscription really isn't a great feature Deno should ship. I think this situation is very different than Supabase. Supabase really publish the whole thing as Git repositories, and you can run it on your own servers if you wish.

evbogue 2y ago

As many of the comments here are getting at KV is best suited for making your app state available at all edge servers at Deno Deploy. You can also use localStorage in Deno but it won't synchronize the data between edge servers on Deploy, so you have to figure out another strategy. and of course KV works without Deploy, so while you don't get the data distribution benefit, you can still use KV on other deployment platforms. The alternative, of course, is to use another database. You don't have to use KV in your Deno apps. Maybe what people want here is the ability to configure their own data synchronization mirrors? Is that already implemented?

youngtaff 2y ago
Edge Servers seem to be one of the most misused terms in the JS ecosystem Anyone know were Deno’s “Edge Servers” are? Is it anymore than EC2 instances because it doesn’t seem to follow the Akamai, Cloudflare, Fastly type approach of actually deploying their own hardware PoPs at the edge
- evbogue 2y ago
  and don't get me started on "Serverless" which often involves servers to my own befuddlement.

vvpan 2y ago

Can a language that is not running on top of a VM pull this off? I do not think so? Which is why it seems to me we need to revisit JVM for example.

ec109685 2y ago
Why do you say so? It’s not that complex what Deno is doing (though I am not sure the complexity is needed over SQLite with replication).

afavour 2y ago

Welcome to the world of VC-driven tech ecosystems!

baq 2y ago

make it work, make it good, make it expensive.

fidotron 2y ago
For “good” meaning “we do all the sre/sysadmin stuff for you”. I am not sure it would apply for all the design decisions going in these things. I think it speaks to how out of control many sre groups are that people willingly spend so much on tools to avoid them. This has real echoes of how the cloud got traction as a way to avoid internal IT.

anonzzzies 2y ago

And most people don’t see through this; they become over the top fans, shoehorning it into every tech stack convo until they notice they are locked in (or change jobs) and then start the entire thing from start again with the tech du jour. Seems fine if you build stuff that is to survive 1-2 years at most, but how teams plan long term on this stuff, I don’t know. We have fast kv, easy to install, not vendor locked in and open source for a long decade+ time. I would like stable, not slightly more convenience that becomes inconvenient once you think about it enough.