feat: implement new tracker

[koya0]

Resolves #74

[koya0]

the code I used for the worker was this js file:

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});

const corsHeaders = {
  "Access-Control-Allow-Origin": "*",
};

async function handleRequest(request) {
  const url = new URL(request.url);

  if (url.pathname === '/set') {
    const key = url.searchParams.get('key');
    const value = url.searchParams.get('value');
    
    if(key && value) {
      await userToReferral.put(key, value);

      return new Response(`Key '${key}' added with value '${value}'`, { headers: corsHeaders, status: 200 });
    } else {
      return new Response('Missing key or value in query params', { headers: corsHeaders, status: 400 });
    }
  }

  if (url.pathname === '/get') {
    const key = url.searchParams.get('key');

    if (key) {
      const value = await userToReferral.get(key);

      return value ? 
        new Response(`Value for '${key}': ${value}`, { headers: corsHeaders, status: 200 }) : 
        new Response(`No value found for '${key}'`, { headers: corsHeaders, status: 404 });
    } else {
      return new Response('Missing key in query params', { headers: corsHeaders, status: 400 });
    }
  }

  if (url.pathname == '/list') {
    const keys = await userToReferral.list(); // get at max 1000 keys
    const keyValuePairs = {};

    for (const key of keys.keys) {
      const value = await userToReferral.get(key.name);
      keyValuePairs[key.name] = value; 
    }

    return new Response(JSON.stringify(keyValuePairs, null, 2), {
      headers: {...corsHeaders, 'Content-Type': 'application/json' },
    });
  }
  return new Response('Not Found', { headers: corsHeaders, status: 404 });
}

The name of the KV namespace I used was "userToReferral" and I had to use the corsHeaders on the responses because they were getting blocked by CORS policy, when sent to the localhost.

[koya0]

I also made a quick demo of the tracker working

demo.tracker.mp4

[zugdev]

the code I used for the worker was this js file:

I believe it's best if you commit this, perhaps cloudflare-tracking-worker.js.

[0x4007]

Check the beta branch of pay.ubq.fi repo to see how we committed cloudflare workers along with the UI code. It automatically deploys with our CI as well.

Maybe @gentlementlegen @whilefoo and @EresDev can explain more on it

[whilefoo]

@koya0 you can put worker code as a page function. If you put the code in /functions/tracker.ts you can call it with https://worker-url.dev/tracker

[0x4007]

Commit TypeScript not JavaScript and run formatting

[koya0]

I realized we have two lock files, yarn is used by cypress so that's why its failing. Can you run yarn install, remove bun lock file and commit

when I ran yarn install, the file didn't change

[whilefoo]

Are you sure? When I run it, it changes

[koya0]

Are you sure? When I run it, it changes

I'm running with yarn 3.6.3, what is your version?

[zugdev]

Are you sure? When I run it, it changes

yarn might change structure only. it's very unpredictable, when I run in Ubuntu/Arch/Windows it generates completely different files from same package.json

[Keyrxng]

The org uses [email protected] in 95% of repos, there are a select few which use bun or a particular version of yarn, that's usually 4.22 or 4.2.2 maybe afaik. The yarn.lock gives hints as to what version generated the file.

I've advocated to the use packageManager field of the package.json to avoid this very scenario amongst other reasons.

[0x4007]

I use yarn 1.22.21 and don't have these problems.

[zugdev]

that's the problem with package managers, first you create npm, than with multiple versions people need to fix a version in each project, people have multiple projects so they need to run an npm version manager lol. soon you will need a manager for nvm which manages node versions

[0x4007]

We use node 20.10.0 across all our CI

I suppose it might make sense to enforce that in the package.json as well.

[koya0]

Are you sure? When I run it, it changes

@whilefoo I changed my yarn to v1.22.22 and updated the yarn.lock, maybe now it won't change

[whilefoo]

Tests are not passing but they also don't pass on the main branch so this is not a problem caused by your code, I think we're good to merge

[0x4007]

Looks like you now have two lock files. Is that correct? Actually it's a bit hard for me to tell for sure from mobile

[koya0]

I was having problems deploying the page with workers, because the version of yarn they use is 3.6.3, and it was getting conflicts, so I added a variable in wrangler to specify the yarn version worker will use.

[0x4007]

Where's the data stored then? How to get this in our database? @whilefoo perhaps you can tie up odds and ends if any?

[koya0]

Where's the data stored then? How to get this in our database? @whilefoo perhaps you can tie up odds and ends if any?

It's stored in my KV Namespace, you need to create a KV and then change the KV id in wrangler.toml to yours.

[0x4007]

Where's the data stored then? How to get this in our database? @whilefoo perhaps you can tie up odds and ends if any?

It's stored in my KV Namespace, you need to create a KV and then change the KV id in wrangler.toml to yours.

@gentlementlegen i think this might be easiest for you to set up given your recent kv work?

[gentlementlegen]

All of the KV setup is automated via the Action deployment script, these variables should be described there. This should not have been commited as such. Example from the plugin: https://github.com/ubiquity-os/plugin-template/blob/development/.github/workflows/worker-deploy.yml#L34

By hardcoding the bindings if we change org / try to deploy on our own, it will break.

[rndquu]

Is it working right now on production? I've tried it with https://work.ubq.fi/?ref=test but the KV store is empty in the Ubiquity DAO Workers project in cloudflare dashboard.

[0x4007]

Somebody with cloudflare access @gentlementlegen @rndquu please fix

[gentlementlegen]

This should not be fixed within cloudflare because the next deployment will erase the KV most likely, at least that's the behavior I had with earlier versions of wrangler. KV and secrets should be deployed from the actions like we do for plugins, refer to this comment.

[0x4007]

koya0 doesn't have access to our cloudflare and can't fix this problem.

[gentlementlegen]

We do not need Cloudflare to fix this problem but a proper deployment Action script.

[0x4007]

Then I suppose a task should be created because I wouldn't be able to implement a fix based on the context I have.

[0x4007]

@gentlementlegen