Sometimes you need to keep values stored locally, for example:

• to prevent data loss due to network failures.
• to keep unfinished editing for a long time (example, this editor)
• to exchange data between different pages without sending it to the server(implementing a shopping cart)

Using default local networks dns server frequently is not enough. Using additional dns servers helps a lot. Using google dns and some other services make a safe redundancy.

This video is kind of a map to the services we can find in amazon AWS.

Here you will can find some references to secure coding practices and how to test for security

Adding an extra level of security is increasingly important to avoid our data from being stolen. Using two factor authentication is a simple yet effective way to accomplish this goal.

Using the MessageChannel for this.

supporting https is mandatory for current sites. It’s not always obvious how to get a server that properly deals with this issue.

Requiring a schema to validate JSON data is a common task.
Usually, you start by simply sending the data to the service. As more data is added, one day dealing with data complexity turns out to be difficult.
So, validating that the data is as expected turns out mandatory.
The simplest way to come up with a first schema to be used for validation is to generate it based on json data.
In this post I present two tools that helps pull off this task very easly.

The web-vitals library is a tiny (~1K), modular library for measuring all the Web Vitals metrics on real users, in a way that accurately matches how they’re measured by Chrome and reported to other Google tools (e.g. Chrome User Experience Report, Page Speed Insights, Search Console’s Speed Report).

The library supports all of the Core Web Vitals as well as all of the other Web Vitals that can be measured in the field:

Creating your own npm libraries is useful if you want to smoothly share your code between projects.

Sometimes is simpler to mount a remote folder if you access it frequently.

Keeping your javascripts light is something pressured by UX requirements. Pages with big javascripts tend to load slowly, on the other hand for a provider is difficult to know in advance what tools to include because they are known only when the script is run.

Sometimes when you are editing a resource, if someone else edits it at the same time you could end up overriding the other person changes.
In order to avoid this, implementing an Etag could solve the issue.

If you want to load again and again a resource that is heavy, you could implement a kind of cache. This can be done implementing Etag in https.

Technical debt are decisions we make during development that we know are not optimal because they require more work to get optimal but we decide to deal with the consequences because we see more value in delivering at that time.

Free api is an option.

Different ways of implementing Core Web Vitals

Webpack is the best tool to bundle resources for javascript. It makes easy to organize your resources and bundle them into files that are ready for production. Also, it has a very flexible plugin system that extends its functionality beyond its core.

Really excellent video on how to replace inheritance with composition in javascript.

Heroku dyno filesystems are ephemeral, non-persistant and not shared between dynos. So when you do heroku run bash, you actually get a new dyno with a fresh deployment of you app without any of the changes made to ephemeral filesystems in other dynos. So, to be able to manage files on web using Heroku you have to resort to other solutions. See a couple in the note details…