# Client-side resource IDs.
## Solving many problems with little to no drawbacks.

Usually, when you create a resource, the API will generate an ID for it before saving it. Or even database might do it for you. There is a different way, and you might like it.

## Resource IDs
Let's make sure we're on the same page when it comes to _resource IDs_. This would be the unique IDs that are assigned to an entity (a user, a blogpost, a product, etc.). It used to select, delete or update particular objects.

### Server-side IDs
Server-side IDs are the most common ones. These are the simplest to implement, most of the time requiring little to no input from the developer. It might be the database that can do it for you (like MongoDB adding `_id` fields), or you might generate some sort of UUID manually.

Whenever you wish to create, let's say a new User, you'd send something more or less like this.

```json
{
	"email": "hello@example.com",
	"fullName": "Tomasz Gałkowski"
}
```

You'd usually get something like that in response.

```json
{
	"id": "some-randomized-id",
	"email": "hello@example.com",
	"fullName": "Tomasz Gałkowski"
}
```

### Client-side IDs
Client-side IDs are created on the client, obviously. When talking web - that's usually a web application or a mobile app. On the client we can't leverage the database doing it for us, but we still have the possibility to generate random strings like UUIDs ourselves.

This time when creating a new User we'll generate the UUID on the client-side and send it with the payload.

```json
{
	"id": "some-randomized-id",
	"email": "hello@example.com",
	"fullName": "Tomasz Gałkowski"
}
```

We'll get the same response.

```json
{
	"id": "some-randomized-id",
	"email": "hello@example.com",
	"fullName": "Tomasz Gałkowski"
}
```

## Why would I ever bother?
Why would you ever bother? That's a good question. Client-side resource IDs have some advantages over the "good old ones".

### Decoupling
They force your backend developers to decouple their business logic from their infrastructure. By not relying on the behaviour of the database it creates some separation. Because you can't rely on your database generating those IDs for you. At some point in the product's lifetime business needs or performance might force you to change the database, and you'd be screwed.

### Types are neater
This one is true in TypeScript and Go, but I'm sure this applies elsewhere too.

If we take a look at the User example from the previous paragraphs our User could look like this.

```typescript
type User = {
	id: string;
	email: string;
	fullName: string;
	role: "admin" | "user";
}
```

What if for some reason (whatever it might be) we need to create that user before we assigned it an  `id`? Should we go ahead and go with `id?: string`? That feels wrong.

Should we have a `User` and `UserWithoutId`? Maybe `User` and `MongoDBUser`?

Or maybe we should create a separate command type.

```typescript
type CreateUserCommand = {
	email: string;
	fullName: string;
};

async function createUser(cmd: CreateUserCommand): Promise<User> {
	const user: User = {
		...cmd,
		id: generateID(),
		role: "user",
	};

	await saveUserToDatabase(user);
	return user; // 1
}
```

That's certainly a way to do it.

Notice `// 1`. We need to somehow return the result of creating the user because we have no other way to communicate the ID. How would our client delete this resource now without listing all of them?

Our commands shouldn't really return data though. Queries should do that. What if we go with this instead?

```typescript
type User = {
	id: string;
	email: string;
	fullName: string;
	role: "admin" | "user";
}

type CreateUserCommand = {
	id: string;
	email: string;
	fullName: string;
}

async function createUser(cmd: CreateUserCommand): void {
	const user: User = {
		...cmd,
		role: "user",
	};

	await saveUserToDatabase(user);
}
```

The client would have to generate the ID and pass it alongside any other required payload. We don't have to return anything to the user outside `201 Created` because they already have the ID handy.  

### Handling errors
You might be asking - OK, but what about ID collisions. Or any other error for that matter?

When using UUIDv4 or similar algorithm collisions wouldn't be a problem. They are rare enough to handle them as an error. Server-side resource IDs aren't free of that issue, but they could regenerate the ID when an error happens. On the client - we'd have to rerun the request.

### Idempotency
Outside from cleaning backend types and making it slightly easier to separate concerns there is one more thing that is very useful.

Let's imagine you're making a POST request. Let's say - add a comment. POST requests have permanent side effects and the result could be different if you send them once or many times. You might add one comment or five comments.

Client-side resource IDs can work as a poor man's idempotency tokens. If your app had some connection issues, and your user sent "add comment" ten times you only want to save a single one. Depending on how (and when) the IDs are generated - as long as the front-end sends 10 identical requests - only the first one will go through. Subsequent ones will fail due to unique constraints.

### Offline-first
Client-generated IDs have one more pro - they don't require a server. You can do a lot of things on the client now. You could easily move a big part of your logic to the client device and fallback to being offline when the server is down. Moreover, you don't have to wait for a connection to create new resources. This is even more true for complicated relations between objects.

It can be done with server-generated IDs, of course! It might be just that tiny bit easier to do it on the client though.

### Cons
OK, but what are the downsides? Not that much, frankly. Most of the problems that you could come up with would be possible with server-side generated IDs, or they are not really a problem.

#### Sending non-unique IDs?
There is a chance the client will send non-unique IDs. The chance of it when using something like UUIDv4 is small, however - it exists. What would happen? Ultimately the server would try to save them to the database and fail. The client would receive a message about failure, regenerate the ID and try again. No biggie.

However, a server-side application has to properly utilize transactions to rollback any actions it did before it failed on an insert or check for key uniqueness before starting work. That could be costly in performance.

My best bet would be to manually check uniqueness before some heavy operations and letting it fail (with proper error handling!) on the simpler cases.

#### Security?
One might be concerned about allowing clients to pick their resource IDs. That's true. However,However, in the simple example above I could inject anything in the `email` as well as the `id`. Nothing excuses not validating and sanitizing data, in Node.js you might want to use `joi` or `class-validator` to make sure the ID is in a correct format. In Go, you might take a look at `go-playground/validator`.

### Summary
There are surely some more sophisticated solutions, but I've grown to like generating IDs on the client. It makes some things easier while drawbacks seem to be outweighed by the pros.

What do you think? <a href="https://twitter.com/tkg_codes/status/1327638308843819010">Share your opinion on Twitter.</a>


Usually, when you create a resource, the API will generate an ID for that thing before saving it. Or even database might do it for you. There is a different way, and you might like it.

Client-side resource IDs.

# Using Serverless Framework with permission boundaries.
## Not authorized to CreateRole. A short post mortem.

Some time ago, we’ve changed the way we authenticate into our AWS accounts. We wanted to streamline how to add or revoke developer access and make our accounts more secure.

The unseen consequence of this was an error that kept popping up whenever we tried to deploy a fresh app stack using Serverless Framework.

```
An error occurred: IamRoleCustomResourcesLambdaExecution - API:
    iam:CreateRole User: <deployer-arn> is not authorized to perform:
    iam:CreateRole on resource: <arn>-IamRoleCustomResourcesLa-XYZ
```

This caused the deployment to rollback and made it impossible for us to deploy fresh environments. The error didn’t happen when deploying to existing apps, which is why the misconfiguration went unnoticed.

After consulting, I’ve learned that this is due to our Serverless trying to create a role without something called a „permission boundary”. Permission boundaries limit what permissions a thing can give when it tries to create other things. It is used as a compliance and security feature. Additionally, we can deny any creations by entities without permission boundary. And this explicit deny is what causes the error. 

In this example the user making the deploy (`deployer-arn`) was trying to create a role, but couldn’t because it didn’t have a boundary set and was being explicitly denied.

The solution to this problem is to add the permission boundary ARN in the CloudFormation generated by Serverless.

```yaml
resources:
  extensions:
    IamRoleCustomResourcesLambdaExecution:
      Properties:
        PermissionsBoundary: <permission-boundary-policy-arn>
    IamRoleLambdaExecution:
      Properties:
        PermissionsBoundary: <permission-boundary-policy-arn>
    AppIamRoleLambdaExecution:
      Properties:
        PermissionsBoundary: <permission-boundary-policy-arn>
```
  
This will extend those resources with the permission boundary. It will bypass the „explicitly deny whenever things don’t have boundary” policy. The first two roles (`IamRoleCustomResourcesLambdaExecution` and `IamRoleLambdaExecution`) were being created by the Serverless Framework, while `AppIamRoleLambdaExecution` was made by one of the plugins we’ve used.


Some time we've changed the way we authenticate into AWS accounts. The unseen consequence of "permission boundary explicit deny".

all posts