Describe how a typical AJAX call on a web page works. Please describe the various systems involved, what they do, and how they interact.
AJAX requests are requests made from a client (browser) to a server after the initial page has already been loaded. It starts with some sort of user code that sets up an HTTP request with all the parameters needed for the request (status code, headers, body). In javascript, this is done with the XMLHttpRequest object. The client then makes the HTTP request to an URL which points to the server. On receiving the request, the server can act upon it and return data (which nowadays is usually in JSON) back to the client. The important thing with AJAX here is that it's asynchronous, so the client wasn't blocked and could perform other actions while waiting for the server to respond. Once the server does respond, the client can parse the incoming data and update the DOM with the results if it'd like to. In addition to userland code that's typically written in javascript to perform AJAX requests to a server, browsers typically make additional requests to the server after initial page load to load things like stylesheets, images and scripts, but those happen implicitly and client code has little control over those requests.
Describe the common components of web application frameworks. What purpose does each component serve? What is the benefit of separating each component from the others?
The lines of what constitutes a web application framework are pretty blurry. You have things like Meteor (which provides you abstractions on the client AND server) to help with handling data, but there's also things like React which focusses solely on a client-side rendering abstraction. Meteor and React are both called web application frameworks (according to Wikipedia anyway), but they do completely different things. In fact, the two can even be used together. That example makes it really hard to say "A framework does X" when React might do it, while Meteor might not.
So instead, let's just talk about thing I LIKE about using React over vanilla HTML and JS. React gives you a declarative component-based system, and a shiny new syntax (called JSX) to go along with it. It makes it so you can write chunks of "HTML", CSS and JS to create a completely reusable component that wraps a lot of functionality. Your "HTML" (which is really just JSX) is simply a declarative representation of the current application state. Update the state and let the framework update your DOM. Easy. Since your presentation markup now lives inside a scripting language, you now also get the added benefit of being able to use the entire ecosystem of javascript (a good example is being able to use moment.js to render timestamps however you'd like).
I guess a web application framework is really just any code that improves the developer experience (often at a cost) when solving multiple problems involved in writing code, as opposed to solving one specific problem (the reason why React or jQuery would be a framework, whereas moment.js or redux are not frameworks). Sorry for not answering the actual question, but I figured this answer would still give you a fair idea of who I am ☺
The benefit of splitting components out and making lighter individual components of a framework, instead of an entire framework, is that it gives the author of a web app to ability to pick and choose different tools that she needs for her use case instead of a single magic black box (a term often associated with DHH's Ruby on Rails). At the same time, one must be careful with how much splitting is done, since more configuration also increases the cost to a developer, and sometimes a magic black box that prefers convention over configuration works really well (the case for Github with RoR). There's actually a really good talk about configuration, convention and the associated developer cost by Dan Abramov here
How would you model emergency contacts for animals at a veterinary clinic? There should be a way to designate a primary contact for a given animal. Please describe the tables involved and how they relate to each other.
When making this decision, I made the following assumptions/observations:
- A pet has multiple emergency contacts, at least one contact, and one of the emergency contacts is a "primary" contact, all the others are secondary
- A pet owner may have multiple pets and would like to use the same set of emergency contacts for all their pets.
- A pet owner might create new, update existing or delete existing emergency contacts, and the latest set should always be used for all pets.
This means the relation can be modelled as:
Owner <--- one to many ---> Pet
Owner <--- one to many ---> EmergencyContact
The tables:
/* Pet */
_id: ID! /* pet ID */
owner: ID! /* (ID in Owner) ID of pet's owner */
... /* other information */
/* Owner */
_id: ID! /* owner ID */
primaryContact: ID! /* (ID in EmergencyContact) primary contact */
secondaryContacts: [ID] /* (ID in EmergencyContact) secondary contacts */
... /* other information */
/* EmergencyContact */
_id: ID! /* emergency contact ID */
... /* other information */
You may notice that there is only a unidirectional lookup path from a Pet -> Owner -> EmergencyContact, and this is good enough for the 2 common use cases:
- Given a pet, I'd like to find the pet's emergency contact
- Given an owner, I'd like to add/update/delete the owner's emergency contacts
Since an EmergencyContact object will seldom live by itself out of context, it makes no sense to have a backwards relation from EmergencyContact to Owner. However, the Owner object might live by itself and may need access to related Pets (For instance, if a pet owner has access to a website that lets her check the status of her pets). If such a case does come up, it may make sense to add a backwards relation to Owner of the form:
...
pets: [ID] /* (ID in Pet) owner's pets */
...