Forem: ST1LLWATER

I got the need for speed...

ST1LLWATER — Thu, 23 May 2024 12:20:48 +0000

Databases

Databases, with no doubts are considered a critical part of an application. Data I/O speeds can be considered a direct factor deciding app's performance and hence the user experience.

I'd not say we need an external caching implementation on any system until it is on a considerable scale with visible performance degradation because databases themselves have tricks up their for speeding their I/O.. Didnt knew that? Damn! read this:
-> Frequently accessed data pages are cached in memory to reduce disk I/O and improve query performance.
-> Even recurrent query plans are cached by database to reduce overheads of repeated query planning!

Indeed databases are one interesting topics to look into.
Anyways getting back to what we shall discuss here, The following article will probable tell you something or two about the caching patterns followed in three-tier web architecture systems (client, server, database) or even similar systems.

What is database caching?

By its simplest definition, a technique to store frequently used data in a temporary memory.
A good caching strategy will ease the load on your database by routing the frequently used queries to read from cache before hitting our database.

A cache layer can exist at
-> Database layer (Internal)
-> Application layer (External)
-> A separate service layer (External)

So why cache? Coz we want things faster, faster, faster

Performance

Since it stores frequently accessed data separately, reduces the latency in data lookup and even the amount of work to be done by database

Availability

Not calling it as a backup plan but don't you think in case our database fails, we would have our cache with our data to not cause 100% downtime?

Scalability

I think if you understood the above points, you can perfectly imagine how caching can improve scalability of your application! Reduces workload on database, faster query responses blah blah.. yeah you got it right!

Let's move to the design patterns of caching!

The Caching Strategies

Cache-aside

Checks cache first for incoming query, if cache hit (found) responds with it else queries database -> responds -> updates caches.
A good general purpose caching strategy works for most cases.
Disadvantages? Yeah a window of inconsistency of data between db and cache.

Read-through

Sits between application and database, difference? application always reads from cache, in case of cache miss, data is populated to cache and then returned to client. The writes are always performed on database btw.
Disadvantages? Time delay of filling the cache first in case of miss and then returning the data.
Quick solution? Devs warm up the cache i.e refresh cache time to time with most in demand data, ik not the best solution out there but saves the day!

Write-through

Sites between client and database same as usual.. then the difference? maybe you can guess... yep data is first written to cache which immediately writes to database.
Benefit? New data is always available to cache.
Disadvantages can be the write latencies.

Write-back

Exactly same as write-through but but but... data is not immediately written back to db but is done at a delay.
This reduces the pressure and the load on the cache in a write-heavy workload.
It improves overall performance too if the delayed writes are batched up together (database will be happy too).
P.S. If cache fails in wrong window, you might lose your new written data which was not yet written to db.

Write-around

Usually coupled with cache-aside or read-through, one of the flows can be:

Data read through cache.
If miss, its read from database.
- Cache is also updated for next time.
Best when there is less write workloads.

Conclusion

We discussed various strategies for database caching which might one day
help you scale your application to new horizons!! (Well umm maybe not horizons but to better limits). Even if you're not implementing cache now, I'd say its better to know your cards well so you can play it right when time comes.

Thanks for your time, hope you learnt something new.

The = operator is an imposter ඞ

ST1LLWATER — Fri, 03 Feb 2023 18:41:10 +0000

I think we are all aware of the assignment operator, yeahh the old = symbol we all have been using everywhere in programming🤩. You all must have done something like

int x = 10

to assign values to variables, but not today😮.

I've always picked up programming languages quite quickly until I arrived at elixir.

Elixir was my first encounter with functional programming too, so not only the impostor operator but the whole methodologies were quite fascinating.

Ahh so judging things here assignment operator works differently in elixir... but how?

Assignment Operator

So in elixir we have this thing called pattern matching, so lets jump to pattern matching first 😅

Pattern matching

So in layman language, pattern matching is matching the data on the right to the pattern specified on left and binding them if matches (filling variables on left) 🤗 duh.

so back to the assignment operator

when we use the assignment operator somewhat like

x = 10

the compiler checks the left side has a pattern like the right so bam💥let's bind dem 😎.

since we are pattern matching so writing

10 = x

ain't giving us errors either.

and ofc this also works for other data structures too like

[x,y]=[1,2]

but writing

[x,y]=[1,2,3]

is making compiler 😡🤬 coz Pattern(RHS ≠ LHS)
This wouldn't have given us any errors in languages like javascript, it would have just destructured first two values from the list and stored them to x & y.

PS. overwriting variables is a thing so we can reassign values but then our above snippet will raise an exception saying RHS doesn't match LHS hehe i.e ( (MatchError) no match of right hand side value)!

PPS. We can prevent reassignments and make compiler give us error if assigning new value is ≠ old but that's a topic for another day.

Conclusion

So in conclusion all I have to say is that even if we know things from our past experiences. There can always be someone amogthem ඞ who has a new story to tell.

Hope this was interesting ✨

Do Like ❤️, Save 🔖 & Share 📈

Selecting The RIGHT way in CSS!! 🎨

ST1LLWATER — Wed, 05 Jan 2022 10:21:52 +0000

For all those frontend enthusiasts out there, I have provided this brief and as clearly as possible description of all CSS selectors and combinators. Do not hesitate to try them out because practice makes perfect! 😉

Core Selectors 🤌

Selectors in CSS are used to select the appropriate HTML element you want to style. 🥸
Several CSS selectors exist for versatility in selection.

Class Selector ( . )

Eg: .outer

Selects all elements which have the given class. (Outer class in our example)

ID Selector ( #️ )

Eg: #name

Selects the HTML element which has the given id. (name in our example case)
(Quick Fact: ID is unique in whole document unlike classes)

Element/Type Selector 🏷️

Eg: h1
Directly select all the specified HTML element on the document.

Universal Selector ( * )

Selector: *

Universal Selector! Selects Everything!!

Attribute Selector ( 🏷️[attribute] )

Eg: img[href]

Selects the given attribute of the given tag from DOM.
(Quick Tip: You can even specify the attribute value to select a particular element.

For Eg: a[href="https://example.com"]
This selects all anchor tags which have the given href!)

Pseudo Class Selector ( : )

Eg: button:hover

Pseudo classes are special keywords which specify a special state of an element. Like hover state on button, focus state on input etc. (Our example targets the hover state of all buttons on the DOM).

Check this to know more about all types of pseudo classes!

Pseudo Element Selector ( :: )

Eg: p::first-letter

Pseudo element selector are those which let you target a specific part of an element.
(Given example targets the first letter of all paragraph tags present in our DOM)

Check this to know more about all types of pseudo classes!

Combinators 👈

Combinators are used to specify relationship between two selectors. 🤝

Descendant Combinator ⬇️

Eg: h1 p ( space ) 🌌

The descendant combinator targets all the second mentioned elements (p in our example) who are the descendant or in other words have the first mentioned element as a parent or ancestor.

(Given example selects all p tags which have h1 as their parent or ancestor)

Child Combinator ( > ) 🧒

Eg: ul > li

This selects only those elements matched by the second selector that are the direct children of elements matched by the first.

(Given example selects all li elements which are direct children of ul)

Adjacent Sibling Combinator

Eg: h1 + p ( + ) 🧑‍🤝‍🧑

This combinator separates two selectors and matches the second element only if it immediately follows the first element, and both are children of the same parent.

(Example selects p tags if its followed by a h1 tag and both belongs to a same parent)

General Sibling Combinator ( ~ ) 👨‍👦

Eh: h1 ~ p

This matches all iterations of the second element, that are following the first element (though not necessarily immediately), and are children of the same parent.

(Our example selects all the p tags which are following h1 tag (can be multiple p tags) unlike the Adjacent sibling selector which selects only the first occurrence)

Forem: ST1LLWATER

I got the need for speed...

Databases

What is database caching?

Performance

Availability

Scalability

The Caching Strategies

Cache-aside

Read-through

Write-through

Write-back

Write-around

Conclusion

The = operator is an imposter ඞ

Assignment Operator

Pattern matching

Conclusion

Selecting The RIGHT way in CSS!! 🎨

Core Selectors 🤌

Class Selector ( . )

ID Selector ( #️ )

Element/Type Selector 🏷️

Universal Selector ( * )

Attribute Selector ( 🏷️[attribute] )

Pseudo Class Selector ( : )

Pseudo Element Selector ( :: )

Combinators 👈

Descendant Combinator ⬇️

Child Combinator ( > ) 🧒

Adjacent Sibling Combinator

General Sibling Combinator ( ~ ) 👨‍👦

Now go get some experience with these selectors by trying them yourself! 🤓😎