Professional Documents
Culture Documents
Frontend Tricky Questions
Frontend Tricky Questions
1. package.json Vs package-lock.json
npm i <package-name> — save
, it will install the exact latest version of that package in your project and save the dependency in
package.json with a carat (^) sign. Like, if the current version of a package is 5.2.3 then the installed
version will be 5.2.3 and the saved dependency will be ^5.2.3. Carat (^) means it will support any
higher version with major version 5 like 5.3.1 and so on. Here, package-lock.json is created for locking
the dependency with the installed version.
To avoid differences in installed dependencies on different environments and to generate the same
results on every environment we should use the package-lock.json file to install dependencies.
Ideally, this file should be on your source control with the package.json file so when you or any other
user will clone the project and run the command “npm i”, it will install the exact same version saved in
package-lock.json file and you will able to generate the same results as you developed with that
particular package.
During deployment, when you again run “npm i” with the same package.json file without the package-
lock.json, the installed package might have a higher version now from what you had intended.
You can also add the --save flag to that command to add it to your package.json dependencies, or --
save --save-exact flags if you want that exact version specified in your package.json dependencies.
npm install
Since you have the actual source, it is clear that you want to develop it, so by default,
both dependencies (since you must, of course, run to develop) and devDependency dependencies are
also installed.
The babel and webpack packages will go into the devDependencies section because these packages
are used in when transpiling and bundle-ing your code into vanilla javascript in the bundle.js & etc
file(s).
In production you will run your code off the bundle.js build/generated code will not require these
dependencies anymore.
• BabelJS provides backward compatibility to all the newly added features to JavaScript and can
be used in any browsers.
• BabelJS has the ability to transpile to take the next upcoming version of JavaScript - ES6, ES7,
ESNext, etc.
• BabelJS can be used along with gulp, webpack, flow, react, typescript, etc. making it very
powerful and can be used with big project making developer’s life easy.
• BabelJS also works along with react JSX syntax and can be compiled in JSX form.
• BabelJS has support for plugins, polyfills, babel-cli that makes it easy to work with big projects.
• BabelJS code changes the syntax while transpiling which makes the code difficult to
understand when released on production.
• The code transpiled is more in size when compared to the original code.
• Not all ES6/7/8 or the upcoming new features can be transpiled and we have to use polyfill so
that it works on older browsers.
Here is the official site of babeljs https://babeljs.io/
http://nicholasjohnson.com/blog/what-is-babel/
10. .editorconfig
EditorConfig helps maintain consistent coding styles for multiple developers working on the same
project across various editors and IDEs. The EditorConfig project consists of a file format for defining
coding styles and a collection of text editor plugins that enable editors to read the file format and
adhere to defined styles. EditorConfig files are easily readable and they work nicely with version
control systems.
https://editorconfig-specification.readthedocs.io/
11. Tslint
TSLint is an extensible static analysis tool that checks TypeScript code for readability, maintainability,
and functionality errors. It is widely supported across modern editors & build systems and can be
customized with your own lint rules, configurations, and formatters.
You can use tslint npm package in your project for better coding structure and quality.
npm i tslint
This tslint package will be installed as devDependencies in package.json.
The primary benefit of CSP comes from disabling the use of unsafe inline JavaScript. Inline JavaScript – either
reflected or stored – means that improperly escaped user-inputs can generate code that is interpreted by the
web browser as JavaScript. By using CSP to disable inline JavaScript, you can effectively eliminate almost all
XSS attacks against your site.
14. What is Cross-Site Scripting (XSS)
Cross-Site Scripting (XSS) is an attack that occurs when an attacker uses a web application to send malicious
code, generally in the form of a browser side script, to a different end user.
The page provided by the server when someone requests it is unaltered. Instead, an XSS attack exploits a
weakness in a page that include a variable submitted in a request to show up in raw form in the response. The
page is only reflecting back what was submitted in that request.
https://www.acunetix.com/websitesecurity/cross-site-scripting/
• Object Oriented Languages supports all the features of Oops including inheritance and polymorphism.
• They support built-in objects.
• C#, Java, VB. Net are the examples of object oriented languages.
1. Protocol
• RESTful services use REST architectural style. It uses one and only one protocol – HTTP.
• RESTless services use SOAP protocol.
2. Business logic / Functionality
• RESTful supports various data formats such as HTML, JSON, text, etc,
• RESTless supports XML format.
5. Flexibility
ASP Dot NET MVC 4 is REST-Based while Microsoft WEB API is RESTFul
https://ahmetozlu93.medium.com/mastering-rest-architecture-rest-architecture-details-e47ec659f6bc
17. WebSocket
WebSocket is a technology that allows a client to establish two-way (“full-duplex”) communication with the
server. (A quick review: the client is the application on a user’s computer, and the server is the remote
computer that stores the website and associated data).
The key word in that definition is two-way: with WebSocket, both the client and the server can trigger
communication with one another, and both can send messages, at the same time. Why is this a big deal? To
fully appreciate the power of WebSocket, let’s take a step back and look at a few common ways that computers
can fetch data from the server.
In a traditional HTTP system, which is used by the majority of websites today, a web server is designed to
receive and respond to requests from clients via HTTP messages. This traditional communication can only be
initiated in one direction: from the client to the server.
• You (the client) places an order (an HTTP request) that a waiter takes to the kitchen (the server).
• The kitchen receives the order and checks if they know how to make it (the server processes the request).
• If the kitchen knows how to make the dish, they prepare the order (the server fetches data from a database
or assets from the server).
• If the kitchen doesn’t recognize the order or isn’t allowed to serve it, they send the waiter back with bad
news (if the server doesn’t know how to or isn’t allowed to respond to the request, it sends back an error
code, like a 404).
• Either way, the waiter returns back to you (you get an HTTP response with an associated code, like 200 OK
or 403 Forbidden).
The important thing to note here is that the kitchen has no idea who the order is coming from. The technical
way to say this is that “HTTP is stateless”: it treats each new request as completely independent. We do have
ways around that—for example, clients can send along cookies that help the server identify the client, but the
HTTP messages themselves are distinct and are read and fulfilled independently.
Here’s the problem: the kitchen can’t send a waiter to you; it can only give the waiter a dish, or bad news,
when you send the waiter over. The kitchen has no concept of you—only the orders that come in. In server-
speak, the only way for clients to get updated information from the server is to send requests.
Imagine a chat app where you’re talking to a friend. You send a message to the server, as a request with some
text as a payload. The server receives your request and stores the message. But, it has no way to reach out to
your friend’s computer. Your friend’s computer also needs to send a request to check for new messages; only
then can the server send over your message.
As it stands, you and your friend—both clients—need to constantly check the server for updates, introducing
awkward delays between every message. That’s silly, right? When you send a message, you want the server to
ping your friend immediately to say “Hey, you got a message! Here it is!” HTTP request-response works just fine
when you need to load a static page, but it’s insufficient when your communication is time-sensitive.
Short polling
One dead simple solution to this problem is a technique called short polling. Just have the client ping the server
repeatedly, say, every 500ms (or over some fixed delay). That way, you get new data every 500ms. There are a
few obvious downsides to this: there’s a 500ms delay, it consumes server resources with a barrage of requests,
and most requests will return empty if the data isn’t frequently updated.
Long polling
Another workaround to the delay in receiving data is a technique called long polling. In this method, the server
receives a request, but doesn’t respond to it until it gets new data from another request. Long polling is more
efficient than pinging the server repeatedly since it saves the hassle of parsing request headers, querying for
new data, and sending often-empty responses. However, the server must now keep track of multiple requests
and their order. Also, requests can time out, and new requests need to be issued periodically.
WebSockets
So, we need a way to send information to the server, and receive updates from the server when updates come
in. This brings us back to the two-way (“full-duplex”) communication we mentioned earlier. Enter
WebSocket! Supported by almost all modern browsers, the WebSocket API allows us to open exactly that kind
of two-way connection with the server. Moreover, the server can keep track of each client and push messages
to a subset of clients. Great! With this capability we can invite all of our friends to our chat app and send
messages to all of them, some of them, or only your best friend.
So, how exactly does this magic work? Don’t be intimidated by the setup—modern WebSocket libraries
like socket.io abstract away much of the setup, but it’s still helpful to understand how the technology works. If,
at the end of this section, you’re interested in even more detail, check out the surprisingly readable WebSocket
RFC.
In order to establish a WebSocket connection with the server, the client first sends an HTTP “handshake”
request with an upgrade header, specifying that the client wishes to establish a WebSocket connection. The
request is sent to a ws: or wss:: URI (analogous to http or https). If the server is capable of establishing a
WebSocket connection and the connection is allowed (for example, if the request comes from an authenticated
or whitelisted client), the server sends a successful handshake response, indicated by HTTP code 101 Switching
Protocols.
Once the connection is upgraded, the protocol switches from HTTP to WebSocket, and while packets are still
sent over TCP, the communication now conforms to the WebSocket message format. Since TCP, the underlying
protocol that transmits data packets, is a full-duplex protocol, both the client and the server can send messages
at the same time. Messages can be fragmented, so it’s possible to send a huge message without declaring the
size beforehand. In that case, WebSockets breaks it up into frames. Each frame contains a small header that
indicates the length and type of payload and whether this is the final frame.
A server can open WebSocket connections with multiple clients—even multiple connections with
the same client. It can then message one, some, or all of these clients. Practically, this means multiple people
can connect to our chat app, and we can message some of them at a time.
Finally, when it’s ready to close the connection, either the client or the server can send over a “close” message.
18. Webhooks
There are two ways your apps can communicate with each other to share information: polling and webhooks.
As one of our customer champion's friends has explained it: Polling is like knocking on your friend’s door and
asking if they have any sugar (aka information), but you have to go and ask for it every time you want it.
Webhooks are like someone tossing a bag of sugar at your house whenever they buy some. You don't have to
ask, they just automatically punt it over every time it's available.
Webhooks are automated messages sent from apps when something happens. They have a message—or
payload—and are sent to a unique URL—essentially the app's phone number or address. Webhooks are almost
always faster than polling, and require less work on your end.
They're much like SMS notifications. Say your bank sends you an SMS when you make a new purchase. You
already told the bank your phone number, so they knew where to send the message. They type out "You just
spent $10 at NewStore" and send it to your phone number +1-234-567-8900. Something happened at your
bank, and you got a message about it. All is well.