ReplAPI-it / ReplAPI.it-NodeJS

[DEPRECIATED] ๐™€๐™ซ๐™š๐™ง๐™ฎ๐™ฉ๐™๐™ž๐™ฃ๐™œ ๐™๐™š๐™ฅ๐™ก๐™ž๐™ฉ, ๐™–๐™ก๐™ก ๐™–๐™ฉ ๐™ฎ๐™ค๐™ช๐™ง ๐™™๐™ž๐™จ๐™ฅ๐™ค๐™จ๐™–๐™ก. This is the single most extensive Replit package, allowing you to access various parts of the site with just a few classes and methods. Maintained by @RayhanADev.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Upgrade Fetching to HTTPS

rayhanadev opened this issue ยท comments

commented

Recently Replit blocked off the staging subdomain behind a username-password (htaccess?) and fetching the standard GraphQL endpoint via node-fetch has been blocked by CloudFlare. In search of solutions I tried the top five methods of fetching data:

  1. https native
  2. request (depreciated)
  3. node-fetch (current)
  4. r2
  5. axios

My research has yielded that native https, request, and axios work when fetching and the rest are blocked by CloudFlare. The particulars as to why I have not looked into.

I dropped request because it is depreciated, which leaves native https (headache) and axios.

Switching from node-fetch to axios should not be too hard and a restructuring of the package dogfooding the Custom classes was in order for some time however comparing the sizes of the packages (node-fetch and axios) there seems to be a huge difference. It is also possible to create custom fetching functions optimized for GraphQL while also using the native https package so that is also an option.

TL;DR The options are:

  • Switch everything from node-fetch to axios w/o any changes to the structure
    • Pros
      • ReplAPI.it will work
    • Cons
      • Huge dependencies size
  • Fix up the Custom classes w/ axios and dogfood off that
    • Pros
      • Clean package structure, no excessive codebytes and copy-pasted functions
      • One shot fetch change and then simply change all node-fetch instances to match with Custom class
    • Cons
      • Huge dependencies size
  • Fix up the Custom classes w/ https and dogfood off that
    • Pros
      • Clean package structure, no excessive codebytes and copy-pasted functions
      • One shot fetch change and then simply change all node-fetch instances to match with Custom class
      • No fetching dependencies
    • Cons
      • Messing with the https API is so bad and not human friendly in the least

While I think over these, I'm also open to any other ideas. LMK in the comments.

commented

I vote for https, but not any https, maybe we could make a wrapper on top of https to simplify its usage.

commented

I vote for https, but not any https, maybe we could make a wrapper on top of https to simplify its usage.

@EpicGamer007 yeah that's probably what I'm gonna shoot for as well, writing a wrapper for https would reduce dependencies (another thing I've been planning) and makes our requests more flexible and fine tuned.

commented

You might even be able to make another package called light-https or something.

commented

@EpicGamer007
Presenting... lightfetch! Lightfetch gives you the best of size, speed, and usability. Made specifically for this project, the added bonus is it's under 10kb too!

And when I tested it... it works! ๐ŸŽ‰

I'll get started on implementing it :).

commented

With the addition of the working BaseClass and all tiny bugs having been resolved, I'd say we're good to go with HTTPS!