3 ms·

Can the rendezvous portion be self-hosted or this tool is tied to that "deno" thing? If it is dead in a water without it, this looks more like an ad for "deno"

by eps 4y ago

Can the rendezvous portion be self-hosted or this tool is tied to that "deno" thing? If it is dead in a water without it, this looks more like an ad for "deno" rather than anything else. Hence the tepid reaction here.

Contextualist 4y ago
Self-hosting outside Deno Deploy is also easy: the rendezvous service is simply a single Deno Typescript file. You can install Deno (a Nodejs-like js runtime) on any server and run `deno run --allow-net=:8000 edge/index.ts`. By doing so, the only difference is that your service is now running on a single endpoint.
Laaas 4y ago
How can you come to the conclusion that this is an "ad" for that "deno thing"? Is using a non-mainstream technology always an ad for it? What if there's no ulterior motive and they just prefer it?
KomoD 4y ago
An ad because it's tech you aren't familiar with?
Contextualist 4y ago
Your comment might be a bit blunt, but those harsh reactions to it do not help, either (but thanks for voicing for me though) I just want to be clear that I am not affiliated with Deno Deploy in any way. I think that vendor lock-in is a fair concern. I actually added documentation on self-hosting on a server after I saw your comment. The repository had a lot of reference to Deno Deploy, because it’s vendor-specific feature, BroadcastChannel, made it possible for the service to be distributive while maintaining low-latency, based on my own test results. Another great product that offers a similar feature is Cloudflare Worker (Durable Objects). However, it’s server framework is more restricted that I am not able to write a TCP hole-punching rendezvous service on top of it. Yes, I’ve been trying to implement this idea for long until I found Deno Deploy. IMHO, vendor-specific features can be carefully designed to avoid much of the migration cost. Usually, those features try to provide an interface that is close to open standard. For example, when I first tried to migrate a Python service from container to Vercel serverless function (now.sh at the time), I only changed one line of code and wrote a 10-line config, because they accepted any Python app written in WSGI. It’s not always a dilemma when it comes to decision on vendor-specific features.

by eps 4y ago

Contextualist 4y ago

Self-hosting outside Deno Deploy is also easy: the rendezvous service is simply a single Deno Typescript file. You can install Deno (a Nodejs-like js runtime) on any server and run `deno run --allow-net=:8000 edge/index.ts`. By doing so, the only difference is that your service is now running on a single endpoint.

Laaas 4y ago

How can you come to the conclusion that this is an "ad" for that "deno thing"? Is using a non-mainstream technology always an ad for it? What if there's no ulterior motive and they just prefer it?

KomoD 4y ago

An ad because it's tech you aren't familiar with?

Contextualist 4y ago

Your comment might be a bit blunt, but those harsh reactions to it do not help, either (but thanks for voicing for me though) I just want to be clear that I am not affiliated with Deno Deploy in any way. I think that vendor lock-in is a fair concern. I actually added documentation on self-hosting on a server after I saw your comment. The repository had a lot of reference to Deno Deploy, because it’s vendor-specific feature, BroadcastChannel, made it possible for the service to be distributive while maintaining low-latency, based on my own test results. Another great product that offers a similar feature is Cloudflare Worker (Durable Objects). However, it’s server framework is more restricted that I am not able to write a TCP hole-punching rendezvous service on top of it. Yes, I’ve been trying to implement this idea for long until I found Deno Deploy. IMHO, vendor-specific features can be carefully designed to avoid much of the migration cost. Usually, those features try to provide an interface that is close to open standard. For example, when I first tried to migrate a Python service from container to Vercel serverless function (now.sh at the time), I only changed one line of code and wrote a 10-line config, because they accepted any Python app written in WSGI. It’s not always a dilemma when it comes to decision on vendor-specific features.