bharathvaj-ganesan

Not all random values are created equal - for security-related code, you need a specific kind of random value.

A summary of this article, if you don't want to read the entire thing:

• Don't use Math.random(). There are extremely few cases where Math.random() is the right answer. Don't use it, unless you've read this entire article, and determined that it's necessary for your case.
• Don't use crypto.getRandomBytes directly. While it's a CSPRNG, it's easy to bias the result when 'transforming' it, such that the output becomes more predictable.
• If you want to generate random tokens or API keys: Use uuid, specifically the uuid.v4() method. Avoid node-uuid - it's not the same package, and doesn't produce reliably secure random values.
• If you want to generate random numbers in a range: Use random-number-csprng.

You should seriously consider reading the entire article, though - it's

bharathvaj-ganesan

Let's lool at the following example structure for RESTful API using Node.js, Express.js included tesing

app/
  |---models/
  |---controller/
  |---helpers/
  |---middlewares/
  |---tests/
      |---models/
      |---controllers/

bharathvaj-ganesan

Namecheap > Github pages

Pointing your domains to a gh-pages branch requires three steps.

1. Add the Github IPs as A records on Namecheap. Both Github IPs are 192.30.252.153 and 192.30.252.154.
2. Add your Github domain as the CNAME alias on Namecheap. your_username.github.io. (mind the extra period!)
3. Add a CNAME with your new domain name in your repository. lowercase and nothing else

bharathvaj-ganesan

 http {
    proxy_cache_path  /var/cache/nginx levels=1:2 keys_zone=one:8m max_size=3000m inactive=600m;
    proxy_temp_path /var/tmp;
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;

    gzip on;
    gzip_comp_level 6;

bharathvaj-ganesan

To follow best practices for running Alembic migrations on two separate PostgreSQL databases while using SQLModel, you should:

1. Assign Models to Specific Databases: Define separate metadata objects to distinguish models belonging to each database.
2. Use Separate Migration Folders: Store migration scripts in distinct directories to avoid conflicts and keep each database's schema changes independent.
3. Modify env.py to Handle Multiple Databases: Configure Alembic to run migrations sequentially for both databases by looping through their configurations and applying changes to the correct metadata.
4. Ensure Autogeneration Works Properly: Implement logic in env.py to apply --autogenerate migrations to the correct metadata.
5. Use Async and Sync Engines Correctly: Handle async database connections properly in the Alembic migration flow.

I'll prepare a detailed setup with env.py modifications, migration folder structures, and best practices to ensure Alembic knows which models

bharathvaj-ganesan

You can configure Alembic to run migrations on two separate PostgreSQL databases in a single alembic upgrade head command by modifying the env.py script. Here's the approach:

1. Modify env.py to Manage Multiple Engines:

   • Create two separate SQLAlchemy engines (one for each database) inside the env.py script.
   • Ensure that migrations are applied to both databases.

2. Use run_migrations_online for Both Databases:

   • Instead of a single engine, define and use two engines.
   • Use context.run_migrations() for each engine.