Adds serverside collection support for v2

[mackenly]

Adds support for collecting events sent serverside. This enables users to send analytics events without running client-side scripts on their user's browsers. Furthermore, it will also enhance #17 allowing the managed component to use serverside tracking rather than the client side script.

Leaving this in draft for now. Still needs:

• Better test coverage
• Documentation of the API endpoint

This is a recreation of #94 updated to use v2. I'll make the requested changes made to that PR here.

[mackenly]

@benvinegar Looking to get this wrapped up. Made changes to use the existing variable names.

Previously, there was some mention of responding based on content type. By that, do you want everything to go through GET request and branch based on the content type?

Right now, it's restful and when the collect endpoint receives a POST request, it accepts fields from the request body using the same field names and the parameter names (with a few additions) used for GET requests (with the pixel).

interface PostRequestBody {
    sid?: string; // site id
    h?: string; // host
    ua?: string; // user agent
    p?: string; // path
    c?: string; // country
    r?: string; // referrer
    bn?: string; // browser name
    dm?: string; // device model
    ims?: string; // if modified since
}

If ims is not present, it tries the header. Same thing for ua.

[benvinegar]

Thanks for coming back. This seems in the right ballpark.

By that, do you want everything to go through GET request and branch based on the content type?

I think what you have makes sense.

Give me some more time to review but at a glance it seems to make sense for me. I'm not sure I'd expect the POST client to bother with if-modified-since shenanigans though.

[mackenly]

Sounds good. I still need to write tests as well.

I'm not sure I'd expect the POST client to bother with if-modified-since shenanigans though.

My use case is saving the timestamp persistently in the user's client and passing that along with serverside requests. So, if being used in that type of setup, I do think there's value in keeping it available.

[stordahl]

Hey @mackenly - I've just raised #227 that I believe solves this in a more ergonomic way by adding a server module to the tracker package. This allows the server to remain unchanged, and doesn't require you to write bespoke post requests to counterscale from your web server. Going to close this as it's sat dormant for a while