Озеро «Лиси», Тбилиси

Парк вокруг озера «Лиси», Тбилси

Станция метро «Церетели», Тбилиси

Черепашье озеро с видом на Тбилиси

Дезертирский рынок

Here I gather interesting articles / books.

And how it works in browsers: <a href="https://html.spec.whatwg.org/#event-loops">https://html.spec.whatwg.org/#event-loops</a>

1. <a href="https://use-the-index-luke.com">https://use-the-index-luke.com</a> 2. <a href="https://postgresql.kr/docs/8.3/textsearch-indexes.html">Postgres: GIST vs GIN for fulltext</a> 3. <a href="https://peterevans.dev/posts/gaps-and-islands-merging-contiguous-ranges/">Gaps and Islands in Postgres</a> 4.&nbsp;<a href="https://richyen.com/postgres/2021/09/03/less-is-more-max-connections.html">https://richyen.com/postgres/2021/09/03/less-is-more-max-connections.html</a>

Passwords hashing: Argon2id vs Scrypt vs Bcrypt

1. <a href="https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html">https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html</a>

1. <a href="https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake">https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#the_websocket_handshake</a>

Readme

It's true, TypeORM doesn't implement Repository pattern, despite it has something called a repository. Let's figure out why.

There is a Data Mapper pattern, which has one responsibility – to transfer data between a domain model and a database,&nbsp;in other words, create objects with data and save them back to database.

In the view of many developers, behaviour of a data mapper pattern is exactly what repositories do. But repositories have a different purpose – to imitate a collection.

We all know that objects are passed by reference. And, therefore, having received a reference to an object, you can mutate this object as you wish. But in the case of the data mapper, this ideal picture of the world collapses. Firstly, a data mapper returns a new object with each call, and secondly, it will not know about any manipulations with an object, and as a result, you will have to call <code class="inline-code">dataMapper.save</code> to write an object state to a database.

It looks like there is need for another layer on top of data mapper.

Here a repository comes into play, which, as I already said, imitates a collection of objects. If you correctly implement a repository, it is enough to write the following code to change state in the database:

But how changes will get into the database? A data mapper still can't detect that object has been mutated. It seems that we still need the <code class="inline-code">repository.save</code> method...

No. This problem has a solution called Unit of Work – this is another pattern that is implemented on top of the previous two and determines boundaries of working with objects.

Code with Unit of Work, Repository and Data Mapper will look like:

As a result of the code above, UoW will count all changes that have occurred in repositories and call necessary methods on a date mapper, so there will be 2 records in the database: one with the old user whose name was updated, and a second with the new Гриша.

TypeORM doesn't have repositories

Лестница в доме, Тбилиси

Тбилиси

This articles explains how to securely store API token in Single Page Applications.

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

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.

Readme

TypeORM doesn't have repositories

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