?meta query param

[mxstbr]

We could add support for ?meta on GET requests that increment, which would allow users to save arbitrary information in the database. We allow them to send key-value pairs in the key:value format, and putting many of these pairs together delimited with a comma key:value,key2:value2 to not clash with other query params.

For example, this request:

service.com/car?meta=user:asdf123,sessionlength:1m2s

Would store this in the database:

{
  time: 12345,
  meta: {
    user: 'asdf123',
    sessionlength: '1m2s',
  },
}

By allow this we make users able to build more sophisticated analytics tracking where they can save things like the length of the session, how many pages were visited etc.

Do you reckon this is useful?

[tscharke]

What is happening in case of further tracking for a special key?

For example:

1. Adding this meta-tracking for the first time (as you described).
   service.com/car?meta=user:asdf123,sessionlength:1m2s
   Results in:

{
  time: 12345,
  meta: {
    user: 'asdf123',
    sessionlength: '1m2s',
  },
}

2. Wanna do a next tracking only for user inside of meta. Is this possible? Can you give me an example of the url todo this? What's the result in a good case? Something like this:

{
  time: 12345,
  meta: {
    user: {
      time: 7890,
      value:  'asdf123',
    }
    sessionlength: '1m2s',
  },
}

In the moment I've no real use case in mind - Sorry

[mxstbr]

I think you'd just add a new record. What's the use case for updating it?

First visit: service.com/car?meta=user:asdf123,sessionlength:1m2s
Second visit (by the same user): service.com/car?meta=user:asdf123,sessionlength:0m50s

Results in:

[{
  time: 100,
  meta: {
    user: 'asdf123',
    sessionlength: '1m2s',
  },
}, {
  time: 120,
  meta: {
    user: 'asdf123',
    sessionlength: '0m50s',
  },
}]

Then when you want to display your analytics, you can iterate through the records and display a graph of how long your users spend on their first and subsequent visits, and how much time non-registered users spend, for example.

There's tons of ways you could use this!

[sean-roberts]

FWIW, I do think this is pretty important since we largely throw out query params sent by the user. Another option could be that you put any query params that are not colliding with ours into the meta data:

so service.com/test?a=b&c=d would store:

{
meta: {
    a: 'b',
    c: 'd',
  },
}

The benefit here is that it's a pretty obvious pattern once you know it's available and you wouldn't have to worry about potent comma escaping problems. The drawback is that people could use params that we would want to reserve.

I think I am leaning towards ?meta=k:v,k2:v2 instead. But I wanted to throw it out there as an option.

[relekang]

I think this would be really useful 👌

I would vote for the meta key variant since putting everything in the query into meta will make every feature that needs a query option will be a breaking change since somebody might already be relying on that key. Also I don't like the idea of forcing users to change naming of things because we occupy the naming space of the query parameters.

[mxstbr]

Does that mean you're for using ?meta @relekang? Not sure I understand your post 😉

[relekang]

Yes, i am for using ?meta=k:v,k2:v2.

In the case of ?k=v&k2=v2 we run the possibility that we want to use a key for a new feature that someone is using for meta keys already and then it becomes a breaking change since they would need to rename their meta key.

[mxstbr]

Good call!

[sean-roberts]

Sounds good 👍