under the hood
What’s the difference between operational and programmer errors?
an operational error happens during operation of the program; it is outside of the control of the programmer. programmer errors happen because people are infinitely stupid, and this certainly does not exclude programmers.
What is ‘event-driven’ programming?
event-driven programming is a programming paradigm characterized by its flow being dictated — driven — by user-actions broadly defined as events. javascript hint hint wink wink nudge nudge. if you’re anything like me (god save you), you might be wondering “well wtf isn’t event-driven?”…
so event-driven programming’s arch nemesis would probably be Procedural Programming Man. Procedural Programming Man captures his user’s inputs, ties them up, and puts them in the back of a large white van. and instead of event-driven programming, now you have user-driven programming.
maybe my metaphor is ambiguous. whereas event-driven programs go where the user tells it, procedural programs just finish a set of instructions, which could be thought of as a single event; event-driven programming is events all the way down. did you click that? there. that was an event.
javascript: 1 procedural programming: 0
you could also just say that event-driven programs love to listen.
non-event-driven programs take one request (but it could very well be the world’s greatest set of instructions ever recorded in binary).
What are ‘worker processes’?
worker processes are basically background processes written by a language, for a language. assuming the question means web workers, which is what javascript uses, they refer to user-defined processes that can run in a separate thread from the actual javascript runtime code. they actually exist in an entirely different “global context”. if you open your windows task manager and then click on the services tab, you’ll see some background processes. these could be thought of as worker processes for the windows os.
well, web workers are similar but on a much simpler scale (one app as opposed to a hub for hundreds or even thousands of apps on a single machine). as web developers, we’re not creating operating systems, so we naturally have less to worry about. but depending on how robust your app is (from ringtone apps to youtube) you’ll still want to process API requests, listen for user input like clicks and keystrokes, and otherwise manipulate the DOM. as app needs scale up, web workers (and sub workers, child processes of the web workers, and so on) are written as needed in order to maintain a smooth user experience (no load times, bad requests, unresponsive design, dead links, or the like).
Describe how Node.js can be made more scalable.
because of how node.Js operates under the hood, it is possible to scale apps in a way only limited by the imagination. there are 3 main things you can do to scale your application: cloning, decomposing, and splitting.
Cloning. create multiple instances of your app and have them handle separate parts of the workload (using a load balancer for example). node.Js has a built-in module, cluster, that makes this possible using a single server. this module uses load balancing to take advantage of the host machine’s multiple CPU cores, which javascript itself ignores entirely (save for the one thread it needs).
Decomposing. this is usually described as microservices. you chop your app up into its most essential functionalities. so your search page, your shopping cart, and your forum could all be different apps, and have different codebases. microservices is a misleading term because the size of the service is not what’s important, “but rather the enforcement of loose coupling and high cohesion between services.”
Splitting. horizontal scalability. also known as sharding your database. you can split your application into multiple instances where each instance is only responsible for a portion of the data. for example, you could partition your app based on the client’s country or native language.
Explain global installation of dependencies.
by default, node installs your dependencies in your local repo, and only your local repo. alternatively, you could install them globally, where they live on your local machine in a single location and are used in any environment you happen to call them from. this is almost never recommended, since different apps often require different versions of dependencies in order to work properly. having a single, global location for that module is almost never worth the amount of space it saves (which is very little as .js is so lightweight).
however, if you always want to run a package’s (usually a devDependency’s) executable commands from the CLI (the console), and you don’t want to just use npx (which is a pretty amazing tool i just learned about… yes, i’m a newb ¯\_(ツ)_/¯), then you can add -g to the normal npm install command.
for example: npm i cowsay -g.
now you can do this whenever you want from any repository or even console you have open…
Explain RESTful Web Service.
REpresentational State Transfer, is utilizing web standards to provide an interface for interacting openly with an application or system, oftentimes a database. this interface is comprised of HTTP methods like GET POST PUT DELETE which allow clients and servers to interact with each other — fetching, creating, updating, or deleting content as it fits client needs. by using open web standards it’s possible for unlimited interoperability e.g. java, python, windows, linux etc. can share resources seamlessly.
