Generating GUID using JavaScript policy

Hi Google Cloud Community,

We are generating GUID for every request on our proxy. We are using math.random on our JavaScript and it works fine on our end. I just want to know the best way or other way on doing it to ensure that we will don't have a colliding IDs on the future. Thank you. Below is the code that we are using.

function generateGuid() {
    return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function(c) {
        var r = Math.random()*16|0, v = c == 'x' ? r : (r&0x3|0x8);
        return v.toString(16);
    });
}
var guid = generateGuid();

 

Solved Solved
0 4 1,231
1 ACCEPTED SOLUTION

There are three easy options for getting a UUID within the context of an API request being handled by Apigee:

  • JavaScript. The function you described will work fine.
  • The pre-populated messageid variable that Gana mentioned . 
  • through the static function available in message templates that creates a UUID for you. createUuid. We built this so that people didn't have to resort to JavaScript. 

In all three of these cases, There is an exceedingly low chance of collision.  Unless you plan to generate more than 1 billion uuids per second, and run your system for ~100 years, then you are pretty safe with any of these approaches. 

At small load, the performance difference among these options will be negligible.  Only at scale will the difference matter.  Performance will be fastest with the messageid variable.  You're just reading a value.   The createUuid function is 2nd fastest.  The JS will be the slowest.  The differences will be ~1 or 2ms.  Eg, the JS may take 2ms and the "read a variable" approach will take 10us (microseconds, not milliseconds)  You may not care about these differences. It's likely that whatever systen you are connecting to, will contribute much more latency to the request, than the act of generating a UUID. 

The other thing to consider is the required scope of the UUID.  If you need "at most one" uuid per request, then the messageid is suitable. If you need to create more than one uuid per request, then obviously you will want to rely on createUuid or the JS method. With either of those you could create 10's or 100's of UUIDs per API request. 

View solution in original post

4 REPLIES 4

Why not use the messageid value on the request, thats available as flow variable.
https://docs.apigee.com/api-platform/reference/variables-reference#messageid

Thanks.

There are three easy options for getting a UUID within the context of an API request being handled by Apigee:

  • JavaScript. The function you described will work fine.
  • The pre-populated messageid variable that Gana mentioned . 
  • through the static function available in message templates that creates a UUID for you. createUuid. We built this so that people didn't have to resort to JavaScript. 

In all three of these cases, There is an exceedingly low chance of collision.  Unless you plan to generate more than 1 billion uuids per second, and run your system for ~100 years, then you are pretty safe with any of these approaches. 

At small load, the performance difference among these options will be negligible.  Only at scale will the difference matter.  Performance will be fastest with the messageid variable.  You're just reading a value.   The createUuid function is 2nd fastest.  The JS will be the slowest.  The differences will be ~1 or 2ms.  Eg, the JS may take 2ms and the "read a variable" approach will take 10us (microseconds, not milliseconds)  You may not care about these differences. It's likely that whatever systen you are connecting to, will contribute much more latency to the request, than the act of generating a UUID. 

The other thing to consider is the required scope of the UUID.  If you need "at most one" uuid per request, then the messageid is suitable. If you need to create more than one uuid per request, then obviously you will want to rely on createUuid or the JS method. With either of those you could create 10's or 100's of UUIDs per API request. 

Thanks that was very helpful!

Thank you all for your response. It is now more clear to us and it gives us more confidence to implement those functionalities on creating a GUID/UUID on our proxies.