web socket

Author: rohan-paul

Javascript/OOP-Prototypal-Inheritence/Inheritence-OOP-Class-vs-Prototypes-Theory.md

@@ -1,7 +1,9 @@
 #### Class Inheritance:
+
 Instances inherit from classes (like a blueprint — a description of the class), and create sub-class relationships: hierarchical class taxonomies. Instances are typically instantiated via constructor functions with the new keyword. Class inheritance may or may not use the class keyword from ES6.
 
 #### Prototypal Inheritance:
+
 Instances inherit directly from other objects. Instances are typically instantiated via factory functions or Object.create(). Instances may be composed from many different objects, allowing for easy selective inheritance.
 
 JavaScript objects use prototype-based inheritance. Its design is logically similar (but different in implementation) from class inheritance in strictly Object Oriented Programming languages.
@@ -14,9 +16,10 @@ This is why in many tutorials you will see **String.prototype.split** written in
 
 Technically, just the light knowledge of the **class** and **extends** keywords is enough to write software. Trying to understand prototype is like venturing into the darker corners of language design. And sometimes that can be insightful.
 
- Just know that at the very top of the Prototype hierarchy there is the Object object. That’s why its own prototype points to null. There’s nothing else above it.
+Just know that at the very top of the Prototype hierarchy there is the Object object. That’s why its own prototype points to null. There’s nothing else above it.
 
 #### Further reading
+
 - 1.  [https://medium.freecodecamp.org/a-guide-to-prototype-based-class-inheritance-in-javascript-84953db26df0](https://medium.freecodecamp.org/a-guide-to-prototype-based-class-inheritance-in-javascript-84953db26df0)
 
 - 2. [https://tylermcginnis.com/javascript-inheritance-and-the-prototype-chain/](https://tylermcginnis.com/javascript-inheritance-and-the-prototype-chain/)

Javascript/call-apply-bind/bind-why-its-needed.md

@@ -1,4 +1,4 @@
-The bind() method creates a new function that, when called, has its this keyword set to the provided value, with a given sequence of arguments preceding any provided when the new function is called.
+The bind() method creates a new function that, when called, has its **this** keyword set to the provided value, with a given sequence of arguments preceding any provided when the new function is called.
 
 The bind() function creates a new bound function, which is an exotic function object (a term from ECMAScript 2015) that wraps the original function object. Calling the bound function generally results in the execution of its wrapped function.
 

Web-Development-In-General/websocket-basics.md

@@ -0,0 +1,20 @@
+### What is a WebSocket API?
+
+According to MDN, the WebSocket API is an advanced technology that makes it possible to open a two-way interactive communication session between the user's browser and a server. With the WebSocket API, you can send messages to a server and receive event-driven responses without having to poll the server for a reply.
+
+At the same time, WebSocket does not compromise with the security system of the web. All the WebSocket handshakes can be scrutinized by the browser using embedded developer tools in them.
+
+WebSocket represents a single TCP socket connection, thus eliminating the problem of connection limitation.
+
+### The differences between a WebSocket API and a FETCH API.
+
+- 1. WebSocket is a low-level protocol, based on the concept of socket and port, which are the underlying transport mechanism whereas REST is based on CRUD operation.
+- 2. WebSocket require the use of IP address and Port details, which are lower level details for any application whereas RESTful application needs to design operation based on verbs, and HTTP based.
+- 3. WebSocket is bi-directional in nature i.e. both way operation from client to server and vice versa is possible whereas REST follows a uni-directional approach.
+- 4. WebSocket approach is ideal for real-time scalable application, whereas REST is better suited for the scenario with lots of getting request.
+- 5. WebSocket is a stateful protocol whereas REST is based on stateless protocol i.e. client does not need to know about the server and same hold true for the server.
+- 6. WebSocket connection can scale vertically on a single server whereas REST, which is HTTP based can scale horizontally.
+- 7. WebSocket is ideal for a scenario where high loads are a part of game i.e. real-time scalable chat application whereas REST is better fitted for occasional communication, in a typical GET request scenario to call RESTful APIs.
+- 8. WebSocket works better, where client-server communicates over the same TCP connection for the life of web socket connection whereas, for HTTP request, a new TCP connection is initiated.
+- 9. WebSocket communication allows client and server to talk independently of each other whereas with the REST based approach, either client is talking to the client or server is talking to the client at any given time.
+- 10. WebSocket communication cost is lower whereas REST-based communication is comparatively higher end on the cost.

system-design/design-url-shortner.md

@@ -5,15 +5,16 @@ How to generate a unique ID for each URL?
 [http://blog.gainlo.co/index.php/2016/03/08/system-design-interview-question-create-tinyurl-system/](http://blog.gainlo.co/index.php/2016/03/08/system-design-interview-question-create-tinyurl-system/)
 
 At first glance, each long URL and the corresponding alias form a key-value pair.
-In a certain sense, a URL shortener is a giant hash table, which maps integer values to full URL strings.  The integer values are represented in the "shortened" URL by a short sequence of characters, which may encode this integer in something like base-64 notation.  An alphabet of 64 characters is used, each character representing 6 bits of an encoded number that is used as the key to the hash table.
+In a certain sense, a URL shortener is a giant hash table, which maps integer values to full URL strings. The integer values are represented in the "shortened" URL by a short sequence of characters, which may encode this integer in something like base-64 notation. An alphabet of 64 characters is used, each character representing 6 bits of an encoded number that is used as the key to the hash table.
 
 Therefore, the question can be simplified like this – given a URL, how can we find hash function F that maps URL to a short alias:
 F(URL) = alias
 and satisfies following condition:s
 
-###  Each URL can only be mapped to a unique alias
+### Each URL can only be mapped to a unique alias
 
 ### Each alias can be mapped back to a unique URL easily
+
 The second condition is the core as in the run time, the system should look up by alias and redirect to the corresponding URL quickly.
 
 ## Performance VS flexibility
@@ -30,11 +31,10 @@ On the flip side, using incremental IDs will make the mapping less flexible. For
 
 I can hardly not ask about how to evaluate the cost of the system. For insert/query, we’ve already discussed above. So I’ll focus more on storage cost.
 
-Each entry is stored as <ID, URL> where ID is a 7-character string. Assuming max URL length is 2083 characters, then each entry takes 7 * 4 bytes + 2083 * 4 bytes = 8.4 KB. If we store a million URL mappings, we need around 8.4G storage.
+Each entry is stored as <ID, URL> where ID is a 7-character string. Assuming max URL length is 2083 characters, then each entry takes 7 _ 4 bytes + 2083 _ 4 bytes = 8.4 KB. If we store a million URL mappings, we need around 8.4G storage.
 
 If we consider the size of database index and we may also store other information like user ID, date each entry is inserted etc., it definitely requires much more storage.
 
-
 ## How would you generate unique IDs at scale (thousands of URL shortening requests coming every second)?
 
 ## How would your service handle redirects?
@@ -46,14 +46,15 @@ If we consider the size of database index and we may also store other informatio
 ## How to track click stats?
 
 ## What characters can we allow in our randomly-generated slugs?
+
 [https://www.interviewcake.com/question/java/url-shortener](https://www.interviewcake.com/question/java/url-shortener)
 
-It turns out the answer is "only alphanumerics, the special characters "$-_.+!*'(),", and reserved characters used for their reserved purposes may be used unencoded within a URL" (RFC 1738). "Reserved characters" with "reserved purposes" are characters like '?', which marks the beginning of a query string, and '#', which marks the beginning of a fragment/anchor. We definitely shouldn't use any of those. If we allowed '?' in the beginning of our slug, the characters after it would be interpreted as part of the query string and not part of the slug!
+It turns out the answer is "only alphanumerics, the special characters "\$-\_.+!\*'(),", and reserved characters used for their reserved purposes may be used unencoded within a URL" (RFC 1738). "Reserved characters" with "reserved purposes" are characters like '?', which marks the beginning of a query string, and '#', which marks the beginning of a fragment/anchor. We definitely shouldn't use any of those. If we allowed '?' in the beginning of our slug, the characters after it would be interpreted as part of the query string and not part of the slug!
 
-Okay, so it seems like the set of allowed characters is A-Z, a-z, 0-9, and "$-_.+!*'(),". The apostrophe character seems a little iffy, since sometimes URLs are surrounded by single quotes in HTML documents. So let's pull that one.
+Okay, so it seems like the set of allowed characters is A-Z, a-z, 0-9, and "\$-\_.+!\*'(),". The apostrophe character seems a little iffy, since sometimes URLs are surrounded by single quotes in HTML documents. So let's pull that one.
 
 ## What about uppercase and lowercase?
 
 [https://www.interviewcake.com/question/java/url-shortener](https://www.interviewcake.com/question/java/url-shortener)
 
-Domains aren't case-sensitive (so google.com and Google.com will always go to the same place), but the path portion of a URL is case-sensitive. If I query parker.com/foo and parker.com/Foo, I'm requesting different documents (although, as a site owner, I may choose to return the same document in response to both requests). So yes, lowercase and capital versions of the same letter can be treated as different characters in our slugs.
+Domains aren't case-sensitive (so google.com and Google.com will always go to the same place), but the path portion of a URL is case-sensitive. If I query parker.com/foo and parker.com/Foo, I'm requesting different documents (although, as a site owner, I may choose to return the same document in response to both requests). So yes, lowercase and capital versions of the same letter can be treated as different characters in our slugs.