❔ Is there any difference between node-updown & updown.io?

[MichaelDeBoey]

Hi @woubuc!

Could you tell me the difference between your node-updown client and @ffflorian's updown.io please? 🤔

If they're about the same, maybe you guys could join forces? 🤔

I've asked the same question in the other repo, see ffflorian/api-clients#318

[woubuc]

At first glance, node-updown (this project) is somewhat smaller and more modular. It uses the built-in Fetch API when running in a browser, and it supports a treeshakeable functional API. This makes it more browsers-friendly than updown.io which is entirely class-based and uses axios for its HTTP requests.

Additionally, node-updown is MIT licensed while updown.io is GPL. This can make a difference to some users, though it generally won't make much of a difference.

I haven't maintained this module as well as I could have in the past, and for a while it wasn't fully compatible with changes made to the Updown API itself. So a year ago I would've said to use the other library. But I've since updated node-updown and I'm sure both modules will work just fine.

Performance aside, I think it's mostly a matter of which API you prefer and whether you're targeting a browser or not.

I fully agree that there shouldn't be a need for two libraries that do essentially the same. I would be open to discussing if and how we could merge the libraries and create an API client that is supported by both developers (which would benefit everyone). @ffflorian what are your thoughts on this?

[ffflorian]

Copying my answer from ffflorian/api-clients#318 (comment):

Hi @MichaelDeBoey,

my library uses axios while @woubuc's uses cross-fetch. Beside that, my library has a bit more documentation I think, but in general there is no real difference as we both don't really have tests 😃

If they're about the same, maybe you guys could join forces? 🤔

Sure, I'm totally up for that! I just wouldn't know where to start. Maybe @woubuc has some ideas 🙂

[woubuc]

I was about to comment in your issue, but it's probably better to keep the thread in one place 😃

The first question should probably be how far you would want to go with this collaboration - do you just want to share ideas to improve both our projects, or are you open to merging the two libraries entirely?

I think merging would likely improve the library, but we'd need to make some choices and probably discard some work since there is going to be a lot of overlap. And then there's the issue of conflicting licenses. So this would take some preparation and figuring this out (at least on my part, since I usually work solo on these kinds of libraries), but I think it could be interesting to explore this further.

[MichaelDeBoey]

Would be awesome if you guys could figure something out together and join forces! 🙂

[ffflorian]

So this would take some preparation and figuring this out (at least on my part, since I usually work solo on these kinds of libraries), but I think it could be interesting to explore this further.

I agree! Maybe you or @MichaelDeBoey already has some ideas about what he likes/dislikes in our libraries? IMO I like in node-updown that it has a functional API and in updown.io I like the JSDoc documentation 🙂

[MichaelDeBoey]

I like node-updown's functional API, but I think the typings could be a bit better (i.e. more "business logic" inside the types themselves).

Haven't used updown.io, so can't really give comments on that one.
Just found out there are 2 different packages doing exactly the same, so would be a shame and imo a waste of time/effort if 2 people are doing the same time separately.

[woubuc]

@MichaelDeBoey What do you mean with "business logic"? What specific logic are you missing in node-updown?

@ffflorian So I haven't really received an answer to my first question, are you interested in merging the two libraries or not? If you are, I think we should start by outlining the goals for our shared library and then see how we can fit our new merged library into those goals.

Some of the goals of my library are that it should be minimal & transparent (a 1-to-1 representation of the API) and that it should be as compact & lightweight as possible, especially when used in the browser. What are your goals for updown.io?

[MichaelDeBoey]

@woubuc If you look at the real data (not only at the API docs), the GroupedMetrics type for instance could be improved like:

export type MetricsGroup = 'host' | 'time';

type MetricsByHost = Metrics & {
  host: Pick<Node, 'city' | 'country' | 'country_code' | 'ip'>;
};
type MetricsGroupedByHost = { [key in Location]: MetricsByHost };
type MetricsGroupedByTime = { [key: string]: Metrics };

export type GroupedMetrics<Group extends MetricsGroup> = Group extends 'host'
  ? MetricsGroupedByHost
  : MetricsGroupedByTime;

Instead of just Record<string, Metrics>

You can check this out by going to

• https://updown.io/api/checks/:token/metrics?api-key=:apikey
• https://updown.io/api/checks/:token/metrics?api-key=:apikey&group=host
• https://updown.io/api/checks/:token/metrics?api-key=:apikey&group=host

[woubuc]

Interesting! I don't really use the grouped metrics so I didn't look into them too much when adding the types, but that definitely looks like an improvement. Could you submit a PR with those changes (and any other types you find lacking)?

[MichaelDeBoey]

I'll create a PR later this weekend 🙂
I'll probably change some function signatures too

[ffflorian]

@woubuc

are you interested in merging the two libraries or not? If you are, I think we should start by outlining the goals for our shared library and then see how we can fit our new merged library into those goals.

Yes, I am definitely interested! I just don't have enough time right now to work on that, sorry. I'll save this for later and will come back to you as soon as I have more time for that.

[MichaelDeBoey]

@woubuc @ffflorian Any news on this?

[ffflorian]

No news so far.

[Jobians]

No news so far.

Yes