2

I want to generate a GUID/UUID for my web app to use but I'm not sure if I should generate it on the client or server or what should be the preference.

Basically, I'm working on a web app similar to e-commerce app.

Here are the steps:

1) User logs into the web app

2) User can create a new transaction or search for an existing transaction.

3) If user selects create transaction, a new transaction number will be generated and shown to the user while he's creating the transaction. On submitting the transaction, all the transaction details will be saved including transaction number + timestamp (for more uniqueness).

If user selects search, they can find an existing transaction by searching by the transaction number that was generated when the transaction was created.

In the end, I'm not sure if I should be generating the GUID/UUID on client (JavaScript/TypeScript) or backend/server (C#/.NET). The only con I can see to generating on client is avoiding an extra api call to get the generated number to display on the front-end but is that really something that would make me select doing it on the client than server?

What are the pros and cons for both? What is normally done?

Thanks!

  • 1
    Do you realy want to show a GUID to the user? Think critically about the percieved advantages of showing it. Perhaps not showing the GUID can avoid baffling the user and allow you to generate it server side and save an API call to you service. – Kasper van den Berg Mar 9 '18 at 5:37
  • There is virtually nothing to gain by allowing them to be generated client-side, and everything to lose in the event of security issues that you did not foresee. I would strongly recommend generating them server-side only. – Sean Burton Mar 9 '18 at 14:53
1

Do you have any security need for the GUID to be as unique as it should?

Never rely on client software to provide security1. If spoofing an old GUID just produces an error then it's fine. Just be sure it's fine.

Pushing work on to the client to make the experience more performant is a fine instinct. Just remember, that's not your computer over there.

| improve this answer | |
  • Yes it needs to be unique to avoid having duplicate transactions. Also, the user can search for a transaction at a later point and edit the transaction (user with certain permissions) and override any existing data tied to the transaction, so spoofing an old GUID can have consequences. – Euridice01 Mar 9 '18 at 0:48
  • 2
    unless they specifically spoof them the chance of a collision is very small. Just make sure your backend only accepts non-existing UUIDs. – BlueWizard Mar 9 '18 at 7:11
0

Both approaches work, and both are respectable, and there are not many pro's or con's.

Advantages of generating on the client: If for some reason the request reaches the server, but its response doesn't reach the client, then the client will probably try to recreate the object, in which case the server has 2 objects when you only want one.

Advantages of generating on the server: The server can generate shorter id's, e.g. consecutive numbers. It's easier to debug systems when URL's and id's in logs and in "debugger watch windows" are nice and short. But if you need the id's to be non-guessable, e.g. "possession of the GUID implies permission to access the resource", then you wouldn't want this.

| improve this answer | |
0

By default, I err on the side of serverside ID generation. ID generation is nowhere near expensive enough to consider needing to offload it to a client.

But a project I previously worked on required the mobile app to be able to continue its workflow even when offline, which meant that the client needed to be able to generate its own IDs in those circumstances. Here, the need for offline usability outweighed the default "better to do it on the server" argument that I tend to err towards.

I would still only suggest clientside generation if there is an actual benefit to doing so. All things being equal, I still err towards serverside generation.

If you do choose to do clientside generation, GUIDs are the way to go. Other data types simply run into too many collision opportunities.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.