DNS lookups in Gleam | The Gleam Programming Language | Page 1

vapid hearth Apr 1, 2024, 1:34 PM

#

Is there a de facto library in Gleam for performing DNS lookups? If not, I'd be interested in building a library supporting both Erlang and Node targets

I imagine it'd use Erlang's inet_res module and Node's DNS module for the respective targets

#

Nothing turns up in packages so mainly asking if the functionality is nestled in to another library https://packages.gleam.run/?search=dns

wary breach Apr 1, 2024, 1:41 PM

#

Not that I'm aware of

#

You'd need to have one library for Erlang and another for JS as they have different concurrency systems

vapid hearth Apr 1, 2024, 1:50 PM

#

I was thinking this library would be synchronous, at least the Erlang inet_res API is synchronous. And then I'd handle any promises directly in JS and return the result directly from the external function

wary breach Apr 1, 2024, 1:55 PM

#

It's impossible to unwrap a promise

#

That's the function colouring problem

vapid hearth Apr 1, 2024, 1:55 PM

#

Gotcha thanks been awhile since I developed JavaScript

#

Funny enough it looks like Node's DNS API is callback-based, no promises as far as I can tell

wary breach Apr 1, 2024, 1:56 PM

#

Same problem

#

There's no way to take a computation that happens later and return it now without a promise or a callback or some other wrapper

#

Not without blocking the event loop, which is likely a bad idea for most applications, and rarely there's an API that makes it possible to do

vapid hearth Apr 1, 2024, 2:04 PM

#

that makes sense thank you! Relatedly - now that I know we need separate libraries - would it make sense eventually for this DNS resolution functionality to live in gleam_erlang and gleam_javascript, as gleam/erlang/inet_res and gleam/javascript/dns modules respectively?

#

If they're gonna be separate libraries they may as well be direct wrappers , no?

wary breach Apr 1, 2024, 2:05 PM

#

Those libraries are for common platform specific functionality that many programs will need

#

This isn't common or specifically about JS or Erlang, so they wouldn't be in those libraries

vapid hearth Apr 1, 2024, 2:07 PM

#

understood

#

is there a naming convention for libraries wrapping a standard module in one of the targets, that doesn't fall under the gleam_erlang or gleam_javascript umbrellas? I'm interested in implementing this and want to comply with standards, if any

wary breach Apr 1, 2024, 2:17 PM

#

Nope

#

Just nothing that sounds official

robust coral Apr 1, 2024, 9:20 PM

#

I'm keen in using these wrappers if one gets made, I'll be a JS user.

vapid hearth Apr 2, 2024, 12:40 AM

#

I think I'm gonna make the erlang one first, only b/c I'm more familiar with that runtime. Willing to collab on a JS lib though!

robust coral Apr 2, 2024, 6:44 AM

#

erlang first is great. I'm keen to see the API you get too and happy to collab on the JS

zenith dew Apr 3, 2024, 1:37 AM

#

one thing to keep in mind is that currently bun doesn’t implement node’s dgram module, so getting at udp packets will be impossible. also any web api focused runtime will be challenging (or not possible) for udp support

but node, deno & erlang should be no problem to support

implementing DNS over HTTPS should be no problem anywhere.

#DNS lookups in Gleam