When we think about storing API access key, we might consider the following approaches:

Let's take a more detailed look at each of them.

Using third-party cookies means, that your API domain handles storing api access key on its own. Sounds simple, but it doesn't work anymore. Safari and Firefox are <a href="https://www.infoq.com/news/2020/04/safari-third-party-cookies-block/">already blocking third-party cookies</a>. Chrome will <a href="https://www.theverge.com/2021/6/24/22547339/google-chrome-cookiepocalypse-delayed-2023">start blocking in 2 years</a>.

Conclusion: Not supported anymore.

LocalStorage is a simple client-side key-value storage. You just put your key on the storage and it will never expire, but even this approach is not ideal.

You can find tons of articles on how insecure LocalStorage is. The main argument is that if some malicious JS code get injected in your page, it can steal important data from LocalStorage.

That's true. Especially if you depend a lot on third-party scripts.

But, well, let's agree that if someone could inject malicious code into your code, it's not LocalStorage's fault.

LocalStorage is only a client-side storage

This can become a real problem if you need to make API calls, which require an access key, during server-side rendering.

Despite of it's recommended not to make API calls, that depend on access key, on server side, there might be situation when you need it. So in this case, LocalStorage is not a good choice.

LocalStorage can't be shared across multiple domains

If you use multiple domains for your website, LocalStorage is not a good choice.&nbsp;

Conclusion:&nbsp;Good for client-side requests. Can be insecure.

You can use cookie the same way as you use LocalStorage. It has the same cons. And cookies will be accessible during server-side rendering.

But the main problem is that you can't really manage cookies expiration date. For example, Safari prevents setting expiration date for more than 7 days. You can review all limitations here&nbsp;<a href="https://www.cookiestatus.com">https://www.cookiestatus.com</a>.

This is the most secure way that works both on client and server sides. But you will need to proxy all requests to API through your SPA server. It can affect response latency of your application.

Conclusion: Best solution if you decide to proxy API requests.

So we figured out that there are only 2 working options. Let's conclude when to use each of them.

There are only 2 cross-browser ways to store API access key in your SPA

NestJS utilises an idea of modules. Modules  act as isolated DI containers and serve purposes of responsibility separation. It helps to group code of your app by feature. One modules reuse business logic of other modules. Modules can be structured inside&nbsp;in any way you choose, the only important thing – decide on what logic they encapsulate.

But what if we need to reuse, for example, repositories of another module? We will want to export those repositories, but it will break SPR of a feature module. We can also duplicate implementation of a repository. 

Actually, I don't like those approaches and I think cross-app layered architecture can help to increase code reusability and preserve "feature modules" approach.

Let's see how it works on example of this blog, which I wrote using NestJS.&nbsp;I have the following feature modules:

But those are not usual NestJS modules. They don't even have *.module.ts files. The idea of feature module that lay in my approach is more about convention and code organisation. The more interesting is what they consist of. Here is where layers come into game.

Every feature module consists of 3 submodule types:

Does it remind you about anything? Yes, it's a usual 3-layers architecture. Let's dive into each module type deeply.

This type of modules is responsible for presentation.

Http modules depend on&nbsp;core modules&nbsp;of any&nbsp;feature modules.

Also this kind modules are the only modules that depend on NestJS framework. Uncle Bob taught us to consider frameworks as features. Here it serves as a feature – I use it for presentation layer to serve my business logic to outer world. I also use NestJS's DI container. That's all. Or not...

Actually there is one tricky thing, that make all my code depend on NestJS. It's DI container. I mark injectable classes using&nbsp;Injectable decorator&nbsp;and inject all dependencies using&nbsp;Inject decorator, which I import from NestJS.&nbsp;

This problem can be solved by creating a level of of abstraction on NestJS' decorators, but I consider it as excess practice, since mass-replacement of&nbsp;import { Injectable } from '@nestjs/common'; statement will cost you nothing in case if you decide to migrate to another framework.

This type of modules is responsible for business logic.

Core modules doesn't have its own DTOs, since it uses DTOs of persistence layer. I find this approach convenient, since it doesn't break a rule of downward flow.

Core modules depend on database modules of any feature modules.

Inject them into your http modules or any other presentation-level modules.

This type of modules is responsible for database manipulations.

Any library you choose to access database.

Inject them into your core modules of any feature modules.

I hope this article has helped you to decide on how to organise your NestJS project. Feel free to contact me if you want to discuss the described approaches or suggest yours

There are only 2 cross-browser ways to store API access key in your SPA

Layered architecture in NestJS