DEV Community: Eyal Gilstron, Senior Manager

Caching Approaches

Eyal Gilstron, Senior Manager — Tue, 07 Jan 2020 09:05:25 +0000

Intro

Caching is storing the result of an operation so that future requests are served faster. Anything that might be slow to retrieve, can benefit if you store your data in advance, for future reuse of the time computed data.
In this article I will talk a bit on the major types of caching, but I will focus more on Server-Side Caching.

When do we need to cache?

• When computation runs multiple times.
• When computation is slow.
• When your hosted provider charges per database access – to save money.
• When we can predict and reuse the same output of the computation for a specific input, to reduce the need to recompute every time.

Major types of caching (in a nutshell)

Server Cache

Store queries, content, code on one or more servers. It's controlled by the server (not by the client).

CDN Caching - CDN is a Content Delivery Network, actually it's a cluster of servers that caches content that’s loaded using the server that’s closest to the end user for faster loading times.

Object Caching: Storing database queries in the back-end for a quick retrieval on page loads.

Client Cache

I want to focus here on Web Caching: Site, Browser, Proxy and Gateway.

A site cache, or also known as a page cache, is a mechanism that temporarily stores data such as web pages or media content when a web page is loaded for the first time.

A browser cache is also a type of site caching. It works in the same way and it’s a cache mechanism that’s built into a browser such as Local Storage, Session Storage and cookies.

Browser caching is controlled at the individual user level. Proxy and gateway is on a much larger scale.

Distributed Cache

Used by the big web sites like YouTube, Google web apps, Facebook and more.

Allow synchronization of distributed cache memory.

Allows the web servers to pull and store from distributed server’s memory.

Allow the web server to simply serve pages and avoid cases such 'out of memory' issues. Made up of a cluster of cheaper machines only serving up memory.

Common in-memory data stores

Redis and Memcached are the most common open-source in-memory data stores.
Memcached has high-performance distributed memory cache service, and Redis is an open-source key value store. Similar to Memcached, Redis stores most of the data in the memory.

You should read this blog before you pick one.

Let's now focus on the Server-side Caching

Very naive and simple example of caching to understand cache hit/miss

// Using Hashtable
var request = "someRequest";
var result; // Init it with default value...
if (myCache.ContainsKey(request))
result = myCache[request]; // Cache Hit - Faster
else
{
newVal = dbRead(); // Cache Miss - Slower
myCache.Add(request, newVal);
result = newVal;
}
return result;

Caching Approaches

No Caching – perform a database read every time we need to do query.
Naive caching - performs a database read just on cache misses. be careful folks as this method can trigger a bug, for example: when the front page becomes out of date.
Clear Cache - just on cache misses we need to do a database read. No potential bugs expected. (If its' done right)
Refresh cache - rarely performs database reads on page views, only on the initialization of the application. Hence the cache is empty and that first page view, and the following pages are cached. This generates one database read per submission.
Using this approach reduces the hits so that a page view does not hit the database hardly ever, and that's a nice thing to have.
Update cache - The fastest option, does zero database reads ever. This is slightly better than the forth one.

I created a snip to emphasis the fifth approach

Hence, the trade off will be then the faster but has complexity of inserts vs. slower database reads.

Caching Models:

Cache Aside

Pros: cache only what we need.
Cons: cache misses are expensive and implementation is complex.

Read Through

Pros: cache only what we need, transparent to the application.
Cons: cache misses are expensive, reliability.

Write Through

Data is written to the cache and the real DB at the same time. The good thing here is that I/O completion is only confirmed once the data has been written to both places.

Advantage: fast retrieval while making sure the data is in the real DB and is not lost in case the cache is disrupted.

Disadvantage: Writing data will experience latency as you have to write to two places every time.

When should I use it?

Good for apps that write and then reread data frequently. This will result in slightly higher write latency but low read latency. Spend a bit longer writing once, but then benefit from reading frequently with low latency.

Pros: data is always up to date.
Cons: write are expensive, redundant data.

Write Behind

Data is written to the cache and Then I/O completion is confirmed. The data is then typically also written to the real DB in the background, but the completion confirmation is not blocked on that.

Advantage: Low latency and high throughput for write-intensive applications.

Disadvantage: A risk to data availability because the cache could fail (and result in data loss) before the data is persisted to the real DB. This results in the data being lost.

When should I use it?

To achieve best performance for mixed workloads as both read and write I/O have similar response time levels. Down to earth, you can add resiliency by duplicating writes to reduce the likelihood of data loss.

Pros: no write penalty, reduce load on storage.
Cons: reliability, lack of consistency.

Write Around

Data is written only to the real DB without writing to the cache.
I/O completion is confirmed as soon as the data is written to the real DB.

Advantage: Good for not flooding the cache with data that may not subsequently be reread.

Disadvantage: Reading recently written data will result in a cache miss (hence a higher latency) because the data can only be read from the slower real DB.

When should I use it?

When accessing applications that don’t frequently re-read recently written data. This will result in lower write latency but higher read latency which is an acceptable trade-off for these scenarios.

I hope these help you folks (:

Speed up the development process without having a degradation in code quality

Eyal Gilstron, Senior Manager — Mon, 30 Dec 2019 11:22:00 +0000

Intro

Almost every development team is facing questions, like: How to enhance the quality of our code? How can I speed up the development process without having a degradation in the code quality?

"Before you implement, write the test" (Microsoft Research)

Why should I test?

It's important to understand: tests don't Improve quality, developers do.
JavaScript development could easily go to hell if the right conventions are not followed. This makes it necessary to utilize the right development and unit testing tools.

Pre-work - Writing tests first give you a clearer view on your API design.
It makes you think of the special cases in your algorithm.

Do you as a developer understand the problem enough to articulate in code all critical component requirements ?

You cannot remember all features that need testing. After making a change to refactor as an example: add new features, remove features and so on...
Automatically prevent broken builds from being deployed to production by testing.

Testing the Client vs. Testing the Back-end

Client tests focus on testing the usability and responsiveness of an application, whereas the back-end unit testing frameworks, focus on testing business logic and other micro-services. You should test them both !

Do I need the browser for these tests?

Not really, JavaScript unit tests for front-end mainly run on actual or headless browsers.

Understand the levels of testing (Microsoft Test Taxonomy)

L0/L1 - Unit tests

L0 - Broad class of fast in-memory unit tests. A L0 test is a unit test to most people. That is a test that depends on code in the assembly under test and nothing else.
L1 - A L1 test might require the assembly plus SQL or the file system.

L2/L3 - Functional tests

L2 - Functional tests run against "testable" service deployment. It is a functional test category that requires a service deployment but may have key service dependencies stubbed out in some way.
L3 - This is a restricted class of integration tests that run against production. They require a full product deployment.

Other Types of Testing that I will not talk about it in this article are:

Beta Tests
Alpha Tests
Regression Tests
Buddy Tests

Shift-Left

This terminology means that we want more L0/L1 tests compare to the L2/3 tests. We want more unit tests, easy to write, easy to maintain and less overhead.

Determining the code coverage types

Function coverage - Has each one of your functions in your program been called?

Statement coverage - Has each statement in the program been executed?

Branch coverage - Has each branch of each control structure, such as in 'if' and 'case' statements been executed? For example, given an 'if' statement, have both the true and false branches been executed?

Condition coverage - Has each Boolean sub-expression evaluated both to true and false?

Review the Most common Frameworks and testing environments (There are many more, focus on the common ones)

First you must distinguish between the Test Framework to the Runner environment itself.

Jest

is a test runner, assertion and mocking library - basically, a JavaScript unit testing framework. Single framework fit for NodeJS, VueJS, React, Angular and other Babel based projects. Well documented. Jest provides also Snapshot testing an ability to create a snapshot of a component during run-time and compare it with a previously created 'snapshot'. With live snapshots, it allows managing tests with larger objects.

Enzyme

is a JavaScript test utility for React applications that enables swift testing and interacting with elements. Enzyme is created by Airbnb. Both Jest and Enzyme are designed to test React applications. However, Jest works with any JavaScript applications like Angular and others, Enzyme is created for React. Jest, on its own, without Enzyme can render components and perform Snapshot testing as well. It is just that, Enzyme adds additional functionality to the testing. Jest and Enzyme are complementary tools that integrate well to provide effective test results.

Karma

is the default test runner for Angular applications. Karma includes the option to test the code on several browsers and even devices to ensure smooth operation of the code on the supported platforms.

Jasmine

is a Behavior-Driven Development (BDD) framework which enables clean and understandable Syntax for writing test cases making the process easy. It does not depend upon any other JavaScript frameworks. Alongside Karma, Jasmine is the recommended testing framework for Angular, and it actually doesn't require a DOM.

Mocha

is a JavaScript based automated test framework meant for testing applications that run using Node.js. Mocha is very common today.

Selenium

WebDriver is the most widely accepted automation testing framework for web-applications, mainly for UI tests and for end to end tests.

Protractor

framework dedicated to testing Angular applications. It is an end to end automation testing framework dedicated for testing your angular application on a real browser. It means that it is making automated interaction just like the real user.

React Testing Library

builds on top of DOM Testing Library by adding APIs for working with React components. Comes to solve the problem while you want your tests to avoid including implementation details of your components and rather focus on making your tests give you the confidence for which they are intended. As part of this, you want your test base to be maintainable in the long run so refactors of your components (changes to implementation but not functionality) don't break your tests and slow you and your team down!

Conclusion, How to pick the right one for my Teams?

It's really depends on your needs and your JavaScript framework/Library that you picked for your project. Let me share with you my opinion from the years that I managed development teams, for Angular I will vote Karma & Jasmine, whereas for React I will vote Jest and Enzyme and of course to enhance the power of your tests I will add React Testing Library as well.

References & Links:

https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/shift-left-make-testing-fast-reliable
https://jestjs.io/
https://karma-runner.github.io/latest/index.html
https://jasmine.github.io/
https://github.com/airbnb/enzyme
https://www.robinwieruch.de/react-testing-jest-enzyme
https://testing-library.com/docs/react-testing-library/intro
http://definitiontech.co/top-4-unit-testing-tools-for-angular-and-react-applications/
https://mochajs.org/
https://www.protractortest.org/#/
https://applitools.com/tutorials/selenium-javascript.html
https://medium.com/@richbray/why-should-you-write-tests-910a3175d33c
https://en.wikipedia.org/wiki/Code_coverage
https://help.crossbrowsertesting.com/selenium-testing/getting-started/javascript/
https://www.guru99.com/code-coverage.html