Rant: UUIDs and primary keys

Muhammad Ali Naeemi — Mon, 13 Dec 2021 22:54:04 +0000

Disclaimer:This post is about my experience regarding using UUIDs as primary keys. If you defer from my opinion and you have "real world experience" on this matter, then please correct me, politely.

In this episode of rants with Ali, we will touch a subject about, why I don't use UUIDs as primary keys anymore.

After having built a fairly complex application with UUIDs as sole primary keys and later switching them back for ints, but still keeping UUIDs for public..that was painful..

You see, UUIDs work fairly fine if you are just going to call db for fairly simple things, i.e. fetch me this by id. However, this whole thing starts to fall apart, when you have complex joins or a lot of inserts/updates, due to nature of UUIDs.

Now, among many things, the indexing cannot be ordered and so that is going to affect inserts and update. Besides, it is going to take a lot more resources, because UUIDs are bulky and your joins will suffer a lot!

In most applications, you wouldn't really mind having slow updates or inserts but sacrificing on joins..they are quite important, specially if you want to keep your application fast without too many roundtrips and in memory calculations where db is almost always going to win. And having a crippling system defeats any "elegant" solution that anyone can muster!

Now one could argue that they will go with NoSQL where everything is "repeated". Sure. You can. But you will still need aggregations at some point (Not talking about DDD aggregations) and that will still be slower anyways due the database being inherently slower at such tasks.

So, what I instead do now is keep int as primary key (in relational database at least) while adding UUID for public facing entities. This gives me best of both worlds.

I am not going to provide exact "numbers" since you can find it all over the internet.

And finally, please don't base your decisions off of 10 minutes of "googling" around..

How state management works (roughly)

Muhammad Ali Naeemi — Tue, 07 Dec 2021 12:26:33 +0000

Alternative title: How to fail at explaining why you should use state manager

We have all heard about state managers in frontend. Maybe used one or two as well, either out of necessity or requirement from your senior developer or maybe "hyyyype!".
But have you ever thought how they are useful? Why it is recommended to use a state manager where it is possible?

Unfortunately, most of the "tutorials" out there just talk about "YOU SHOULD USE A STATE MANAGER AND HOW TO CREATE A NOTORIOUS COUNTER" but always fails to explain why to use it! And what exactly is happening in the background.

In this episoooode of "Rants with Ali", we will "try" to dive a little into this void and try to create our own very basic state manager. And see how state functions in the background. We will not discuss why you should use state managers. By reading this document, you can get an answer to "why", but if you are still in doubt, you can ping me

Before we begin to create our V100000x_MEGA_AWESOME_STORE, we will go through with some basics, as roughly as "sanely" possible. No super duper definitions from wiki boom boom.

Btw, the example at the end doesn't follow any "specific" state managing library for a very good reason. Go figure!

Store

It's a mega container, which:

contains state of your application (see below)
has ways to mutably or immutably modify your state
- As stupid as "modify" and "immutable" sounds together, that is the truth of reality
- Yes, mayyybe..we will get into how some state managers can handle immutability in JS
- For example:
  - Vuex mutates
  - Redux immutably provides a new state
  - Arguably, both are doing almost the same thing

can have accessors to access parts of your state

In a class like syntax, think of them like "getters"

class Something {
    constructor(obj) {
        this.obj = obj;
    }

    get name () {
        return this.obj.deeply.nested.name;
    }
}

const testObject = { deeply: { nested: { name: 'ali' } } };
let a = new Something(testObject);

console.log(a.name); // ali - watermark level pikacu!

has actions, that..as the name suggests, does "x" (even asynchronously) and can modify the state

State

In plain english, it's just a container that:

has some properties attached to it
is immutable in some state managers (duh)
has maybe a few more things, but basically your data that you want to be shared in your components etc

const defaultState = {
    a: '',
    default: 'xD',
    state: true,
    nested: {
    values: 'yep',
        are_also: '...',
        possible: '🤯🤯'
    }
}

Actions

These are functions that:

have access to your state
have a predictable "key" as either their name or return this "key" as type, so they can be globally "predictably" called/dispatched (see below)
can ultimately end up modifying your data. Either through reducers or commits
are, I guess, only a piece of thingies, that can be asynchronous
- technically other parts of the store can be, but this is usually where you want to put your async stuff.
- Trust papa!

// action type
const INCREMENT = 'INCREMENT'; // THIS AN BE LOWERCASE OR lIkEThiS. but would you!?
const DECREMENT = 'DECREMENT';

const actions = {
    [INCREMENT]: async (...) => {...},
 [DECREMENT]: (...) => {...}
}

Reducer & Commits

Well, these are what ultimately modify your state, mutably or immutably

they receive usually:
- a payload (data)
- if a reducer, then an action type, so it knows which part of state is being modified and has logic accordingly
- otherwise in commit scenario, the party that commits knows which commit method to call

Let's Build it now...

Firstly, we will create a generic store
Read above if you have difficulty grasping what is going on here. I invested my time (that nobody asked for) writing those for a reason you know..
filename: 'store_factory.js'

Creating a generic store factory

class Store {
    /** @typedef {Object} State */

    /** @type {State} */
    #_state;
    constructor(state, actions, reducer, commits) {
        this.#_state = state;
        this._actions = actions;
        this._reducer = reducer;
        this._commits = commits;
    }

    /**
     * @param {String} action
     * @param {...*} payload
     * @returns {Promise<*>} returns the result of action
     */
    async dispatch (action, ...payload) { // this has side effects
        if (this._actions[action]) {
            const actionData = await this._actions[action](...payload);
            this.#_state = this._reducer( this.#_state, actionData );
            return actionData;
        }
    }

    /**
   * @param {String} commitType
   * @param {*} payload  
     */
    commit(commitType, payload) {
        if (this._commits[commitType]) {
            this.#_state = this._commits[commitType](this.#_state, payload);
        }
    }

    /**
     * @returns {State}
     */ 
    getState() {
        return this.#_state;
    }
}

Creating a store that will use the store factory

imagine you have, filename: 'userinfo_store.js'
First we will create a default state.
- Every state must have a default state to make sure that validity of store and to also provide a footprint

Default state

const defaultState = {
    name: '',
    age: {
        day: null,
        month: null,
        year: null
    }
}

Actions

Then we define our actions, that can help us modify our state
We will first define global identifiers
Afterwards, we will use these "global identifiers" to use as action's method key or their name
We do this, because having a unified place to define name of your method, can be used anywhere in your codebase without having to worry about their name change.
- When we write a reducer you will have even better understanding to why defining it like this makes sense
Plus, you get intellisense in good IDEs / editors. gth sublime!

// our actions global identifiers
const ACTIONS = {
    CHANGE_NAME: 'CHANGE_NAME', 
    CHANGE_DAY: 'CHANGE_DAY',
    GET_DATA: 'GET_DATA'
}

// action methods that uses the global identifiers as their key/name
const actions = {
    [ACTIONS.CHANGE_NAME] (name) {
        return {
            type: ACTIONS.CHANGE_NAME, // this is used by reducer o
            payload: name
        }
    },
    [ACTIONS.CHANGE_DAY] (day) {
        return {
            type: ACTIONS.CHANGE_DAY,
            payload: { day } // sending object for the sake of example and completion
        }
    },
    async [ACTIONS.GET_DATA] () {
        return {
            type: ACTIONS.GET_DATA,
            payload: {
                name: 'ali',
                age: {
                    day: 28,
                    month: 6,
                    year: 1990
                }
            }
        }
    }
}

Reducers

Now we will create our reducer (maybe in the same file, it's up to you how to structure your codebase! )
You will see that in each case, we always return state.
- This is because reducer takes whatever comes through action, and reduces it to one thing; that is, "State"!
Another thing you will notice is that we use destructure when returning our state.
- This is to ensure, that we will have consistent viable state, despite anything that is sent to modify it.
- This provides stability, as well as ensuring that any input will consistently have same output!
- Destructing makes sure that we always return "copy" of modified data and not the same reference. Remember, that in javascript objects are passed by reference!
- as such, it helps in immutability!
We are not doing JSON.stringify "hack" because that is very inefficient. And we want to keep the same reference for unchanged nested objects
In reducers, we usually use switch/case. You can use if/else if but in large store, we want things to be fast and switch/case is definitely faster than other alternatives.
In these switch cases, we use the name of our action and having "global identifiers" as action names for lookups is helping us here!

const reducer = (state, action) => {
    switch (action.type) {
        case ACTIONS.CHANGE_NAME:
            return {
                ...state,
                name: action.payload
            }

        case ACTIONS.CHANGE_DAY:
            return {
                ...state,
                age: {
                    ...state.age,
                    ...action.payload
                }
            }

        case ACTIONS.GET_DATA:
            return {
                ...state,
                ...action.payload
            }

        default:
            return state;
    }
}

Lets's also create Commits

const COMMIT_TYPES = { // kind of same way of writing as actions
  CHANGE_MONTH: 'CHANGE_MONTH'
}

const commits = {
    [COMMIT_TYPES.CHANGE_MONTH] (state, monthData) {
        return {
            ...state,
            age: {
                ...state.age,
                month: monthData
            }
        }
    }
}

Instantiating our store and using it!

First, lets define our component that would use our store

class BaseComponent {
    constructor(store) {
        this.store = store;
    }

    get state() { // think of these "get" as "computed" in vuejs, for example
        return this.store.getState();
    }

}

// parent
class MyComponent extends BaseComponent {
    constructor(store) {
        super(store); // we instantiate our base component
        this.children = [];
    }

    get name() {
        // this.state is coming from "BaseComponent". Learn OOP please?
        return this.state.name;
    }

    async fetchData() {
        return this.store.dispatch(ACTIONS.GET_DATA);
    }

    changeName(name) {
        return this.store.dispatch(ACTIONS.CHANGE_NAME, name);
    }

    addChildComponent(component) {
        this.children.push(new component(this.store));
    }
}

// child. I will not create a 
class ChildComponent extends BaseComponent {
    constructor(store) {
        super(store);
    }

    get ageDay() {
        return this.state.age.day;
    }

    get ageMonth() {
        return this.state.age.month;
    }

    changeDay(day) {
        this.store.dispatch(ACTIONS.CHANGE_DAY, day);
    }
}

No let's instantiate our store and create a few components with these stores
We will also add some child component to a parent component
This should help us see how easy it is to share data between components. Be it sibling components, child components or components from another galaxy!

// we create one store outside of any context
// so it can be used by any component
const myStore = new Store(defaultState, actions, reducer, commits);

// now we utilize out component and use our store
(async () => {
    const componentA = new MyComponent(myStore);
    const componentB = new MyComponent(myStore);
    // here our third component is using a different state from same store footprint
    const componentC = new MyComponent(
        new Store({...defaultState, name: 'naeemi'}, actions, reducer, commits)
    );

    // let's also add a child component inside component B
    componentB.addChildComponent(ChildComponent);

    // component A and B share the same state
    console.log({
        componentA_name: componentA.name, 
        componentA_state: componentA.state,
        componentB_name: componentB.name,
        componentB_child_age_day: componentB.children[0].ageDay,
        componentB_child_age_month: componentB.children[0].ageMonth,
        componentC_name: componentC.name
    });

    await Promise.all([
        componentA.fetchData(),
        componentC.fetchData()
    ]);

    // component A and B share the same state
    // the footprint of fetchData is same, so component is also getting same kindish value
    console.log({
        componentA_name: componentA.name, 
        componentA_state: componentA.state,
        componentB_name: componentB.name,
        componentB_child_age_day: componentB.children[0].ageDay,
        componentB_child_age_month: componentB.children[0].ageMonth,
        componentC_name: componentC.name
    });

    // let's change the name from componentA 
    // and se how it will also affect componentB, since they both share state
    await componentA.changeName('Sensei');

    // let's also change age from componentB's child
    // this child is also sharing the same state as componentA and componentB
    await componentB.children[0].changeDay(5);

    // we will commit from outside of a component, through store attached to it
    // for the sake of example
    componentB.store.commit(COMMIT_TYPES.CHANGE_MONTH, 4);

    // component A and B share the same state
    console.log({
        componentA_name: componentA.name, 
        componentA_state: componentA.state,
        componentB_name: componentB.name,
        componentB_child_age_day: componentB.children[0].ageDay,
        componentB_child_age_month: componentB.children[0].ageMonth,
        componentC_name: componentC.name
    });
})()

Nuxt: Ignore SSL issues for axios proxy (Development only)

Muhammad Ali Naeemi — Fri, 26 Mar 2021 09:29:59 +0000

I just recently came across an issue, where me and my colleague were live sharing backend (in .net) and I was consuming it in Nuxt application but I was getting UNABLE_TO_VERIFY_LEAF_SIGNATURE and DEPTH_ZERO_SELF_SIGNED_CERT, SSL issues with nodejs and axios proxy.

All the ajax requests in (my) nuxt app goes through axios proxy plugin.

Usually this SSL issue happens because you are running or consuming a HTTPS server, but your machine cannot validate the SSL certificate.

After some research, I found an easy way to disable SSL checks (only for local development environment, please).
Here is what I am doing in my nuxt.config.js file.

(Here I am also assuming that you already have ENV environment variable setup)

{
// nuxt.config.js
...
    proxy: {
        '/api/': {
            target: process.env.MAIN_API_URL, // a url for your api
            secure: !process.env.ENV === 'development'
        }
    }
}

Again, secure: false should be only setup when you are testing locally. Hope this saves you some hours of frustration :)

DEV Community: Muhammad Ali Naeemi

Rant: UUIDs and primary keys

How state management works (roughly)

Alternative title: How to fail at explaining why you should use state manager

Store

State

Actions

Reducer & Commits

Let's Build it now...

Creating a generic store factory

Creating a store that will use the store factory

Default state

Actions

Reducers

Lets's also create Commits

Instantiating our store and using it!

Nuxt: Ignore SSL issues for axios proxy (Development only)