Not to long ago it would be unheard off to not store your information in a database on some remote server away from the client. Today though, terms such as JAMstacks, Serverless, and Pre-Fetched websites are popping up left and right. I thought it would be interesting to take a look at all the different ways to store data and its persistence in a typical server/browser architecture.
Values only persist as long as the window or tab is open.
Cleared when the browser session ends or when you close the browser/tab.
Information is much more publicly accessible and is limited to the current browser session, only. No other client, nor tab/window can access this data.
Similar to sessionStorage except that data stored in localStorage has no expiration time. Available on all browsers. This is also called DOM storage and is often treated similar to a cookie and is deleted only when the user clicks ‘Clear all cookies => Time Range: ‘Everything’. It is sometimes stored in the Cache (chrome). Only accessible from the Client-side.
Sent from the website, and stored on the user’s computer or browser.
Only 2kb of storage available; cookies are used for stateful transactions and information such as storing a shopping cart’s data on a website, a users tracking data, or even form fills.
They must be deleted by the user through the browser settings, unless they expire in some rare cases.
Persistence in this case refers to directing a client’s response to the same server. Login sessions can also utilize cookies which are stored in the browser. When stored on the servers, session ids will be created, managed, and stored on the server. OAuth, HTTP, SSH, all use sessions, but on a lower level TCP connections and virtual circuits can count as sessions as well.
Stored in database structures such as MySQL, SQLite, PostgreSQL, and can only be deleted if the admin or in certain case user deletes the data, which is executed by a query. Databases usually store information in the memory or a computer or server. This is what the majority of the internet uses to store and fetch data.
Client-side caching or HTTP cache is often implemented by storing data in a folder on the user’s system, which is determined by the browser. The cache is usually determined in the http header by calling the ‘Cache-Control’ for a set duration of time. The user can also clear their Cache.
Client-side sessions storage, usually on the server. Makes it faster when stored on the client’s browser. (Rails). Issue with this is lack of space (4kb), if there’s not enough space, its stored on the server.
Server-side caching is similar to client side caching except that the information is stored in a network of servers (or single server) once loaded, and therefore become accessible to the user while not having to load or fetch them from a remote service. Flushing the server-side cache is more complicated and often requires access or making certain call to the server to purge the cache. When persistent caching is utilized, the cache stays even after the session ends.
Servers can also pre-cache information that it assumes the user might want call.
Content deliver networks such as Akamai utilize this system on a world-wide level by loading servers around the globe in sync and mirror them so that the information is most accessible and nearest to the user, lower load times (high-level explanation).
Remote cache (e.g. Redis)
Keeps all memory in RAM, ideal for the caching layer. If your build is reproducible, the outputs from one machine can be safely reused on another machine, which can make builds significantly faster.
Cache is stored on the back-end, and can be mirrored in a network or WAN by utilizing General Parallel File Systems.
Redis for example is different than other database solutions in that it uses memory as the main storage and the disk only for persistence.
Issues that remote services are running across include keeping all servers in sync so that services can remain active and current throughout the network. Messaging protocols for example need to stay up to date to make sure that everyone is receiving the same messaging stream, and when you’re trying to max out efficiency and loading times.
Many messaging services have developed remote services and platforms.
AMQP and STOMP => Text-based protocol, works similarly to HTTP and works over TCP by extending with the commands ‘CONNECT’, ‘SEND’, ‘SUBSCRIBE’, ‘UNSUBSCRIBE’, and sending <key>:<value> pairs.
So how should you store information when interacting in a typical client-server relationship, well as we’ve seen it all depends, and remains a multifaceted question even today.
I hope this information was useful or informative in some way.