Ruby is a dynamically typed, object-oriented, interpreted scripting language written in C. It was created by Yukihiro ‘Matz’ Matsumoto in Japan in 1993 and was released publicly in 1995. Its intuitive design and structure have led it to become one of the most popular programming languages. It’s basic functionality can be greatly enhanced through the use of libraries that are downloaded as ‘gems’. Since Ruby is an interpolated language it runs equally well across all platforms without the need to compile for a specific processor or operating system.

Rails is a server-side framework for Ruby that uses the MVC architecture with default structures for web services, web pages, and databases. It was created in Ruby in 2003. It is seen as one of the first major frameworks for creating dynamic web apps with frameworks with other frameworks like Django for Python, Catalyst in Perl, and Sails.js for JavaScript borrowing heavily from the ideas laid out in Rails. It uses many web standards like HTML, CSS, JavaScript, and JSON to help build reactive web apps. Rails also emphasizes the importance of DRY (Don’t Repeat Yourself), or the idea that modularity should allow for extensive reuse of code that needs to be used in multiple places. Similarly Rails uses ‘Fat models, skinny controllers’, meaning that the majority of the logic and processing is handled by the models as apposed to the controllers. It also uses the idea of Convention over Configuration, or the idea that the structure of the app should follow the established patterns set out in the Rails framework, and that developers shouldn’t deviate from this just for convenience.

In Rails the ‘model’ is in the form of an Active Record data type. This data type stores values and methods for accessing those values directly on the object itself. This allows the model to act as an ORM. Active Record are able to represent data, represent relationships with the data, represent inheritance between models, validate data models before database entry, and interact with the db in an Object-oriented way. The action view is the view component of the MVC, each component has a corresponding view in the app/views directory. The templates for the views use a mix of embedded ruby and html in .erb files and xml in .builder extension files. Erb files that have html will often be designated by <filename>.html.erb. Partials can also be used to build small reusable components that you can use throughout different parts of your code. The controller part of the MVC layout is the action controller. It handles requests once they have been appropriately routed. They handle the processing of the requests and responses. The controller ends up acting as a middleware between the models and the views.

Overall, Ruby on Rails is a powerful, but easy to understand framework built off a programming language that is also intuitive and direct. The emphasis on DRY and CoC keeps the code clean and modular and allows for creative reuse of components. The built in ORM and router help keep data organized and the templating system allows for easy rendering of views.

Django is a python framework that follows the Model-View-Template design pattern. It was created in 2003 and then publicly released under the BSD license in 2005. It was designed to allow fast production. Built with many tools including tools for authentication, site maps, and RSS feeds. It was created with scalability in mind so it can be used by companies like the MacArthur Foundation, Pintrest, Instagram, National Geographic, and Mozilla. It follows the MVC architecture where the model is an ORM that handles python classes and a relational database. The view is comprised of a web templating system that handles http requests. The Controller handles a url dispatcher that uses regexs and acts as a router. Django’s built in tools include a development and testing server, a form validation and serialization tool that can handle html and format it for databases, and an internal dispatcher so that different components can talk to each other. It has become so popular its templating system has been ported to other languages including liquid for Ruby, Template::Swig for Perl, Twig for JavaScript and PHP, and ErlyDTL for Erlang.

Django really embraces modularity. Each piece of a server can be built easily in Python with packages that handle specific tasks. Django lets you snap the pieces of a website together like a model train set. You have your main pieces of track that are the core and tools from Django, that you can mix with special sections of track, that are the packages and extensions you can bring in to the project all working together to allow for scalability and rapid development.

Built using Python, one of the most used programming languages, Django is easy to learn, readable, and versatile. Django works great for building content management systems, booking engines, and client relationship management. It can also be used for verification, machine learning, email solutions, and data analysis. Since it has been around since 2003 it has a rich development history and very mature and well perfected core.

Since it was designed to be a solution out of the box it does have a few problems, including how hard it is to change certain components like the ORM without having to do a lot of extra work. Django is also suited more for large-scale web applications, for smaller projects frameworks like Flask would work better. Django also doesn’t have out of the box support for Websockets, making it difficult to make real-time web apps without other frameworks.

While far from a perfect solution for small scale applications and websites, Django works great for large scale problems that require scalability and rapid development. Since its built with Python it’s easy for people familiar with Python to jump right into building web apps. Its support for external platforms and libraries allows you to truly customize your app in almost any way.

JSON Web Tokens or JWT is an access token method that allows the server to allow access to a certain user by generating a token for that user and the specific level of access. It is structured with three parts, the header, the payload, and the signature. The header contains information on the algorithm used to sign the token. The payload has the information about the token which is one of the seven Registered Claim Names. The registered claims are “iss”, “sub”, “aud”, “exp”, “nbf”, “iat”, and “jti”. “iss” is for the issuer of the token. “sub” is the subject of the token. “aud” is the audience of the token. “exp” Is the expiration date of the token, it must be some time in the future. “nbf” is the time before the token is actually good and usable. “iat” is the time that the JWT was issued. Lastly “jti” is the unique identifier for the JWT so that it can be a one time use token. The signature itself is the encoded data, this securely validates the token.

The server generates and signs the JWT and then sends that to the client. The token is then saved in the local storage or on a cookie and then can be sent back to the server to authenticate access to certain routes. The token is sent in the authorization header and is structured as a key value pair with authorization as the key and then Bearer and the token as the value. This allows access on the server side without authenticating the user every time and is more efficient than making a database call every time a user attempts to access a protected route.

JSON web tokens are especially useful for authorization and information exchange. For Authorization JWT is helpful so that once a user is Authenticated and signed in they have access without constantly re-authenticating. Once a user has logged in they are given an access token and the token is just checked at protected routes that are specifically allowed on the token. JWTs are also good for exchanging information because they are signed and can be secured using public/private key pairs, so you can be sure that the sender is who they say they are. Since the payload is also included in the JWT you can ensure that none of the data has been tampered with also.

While there are some common drawbacks to JWT they can be avoided for the most part by following 3 simple steps. The first drawback is that JWTs can be sent using no algorithm for encryption so it is always important to maintain a specific standard for what algorithm and other headers you are using and if the incoming JWT has the wrong algorithm discard it immediately. Since all JWTs are signed, it is important to know the algorithm that and what security they provide. Make sure you know the authenticity, confidentiality, and integrity of the algorithm you are using. Finally, its important that you use an appropriate key size. That means don’t use HMAC keys shorter than 256 bits, AES keys shorter than 128 bits, and RSA keys shorter than 2048 bits, or 1024 for legacy. By following these three steps you can avoid the pitfalls of human error that can leave a well secured system, JWT, vulnerable to exploit.

Referneces:

https://en.wikipedia.org/wiki/JSON_Web_Token

https://scotch.io/tutorials/the-anatomy-of-a-json-web-token

https://jwt.io/introduction/

https://hackernoon.com/json-web-tokens-jwt-demystified-f7e202249640

https://flaviocopes.com/jwt/

https://connect2id.com/products/nimbus-jose-jwt/vulnerabilities

Redis, or Remote Dictionary Server is a key-value database that stores data as data-structures in memory. It has support for strings, lists, maps, sets, sorted sets, HyperLogLogs, bitmaps, streams, and spatial indexes. Redis stores all its data in memory and then uses a process called snapshotting a process that allows for data to be asynchronously transferred to the disk. Redis writes to the file-system once every 2 seconds.

The biggest benefits to using an in memory database is performance. Since the data is not retrieved from the disk, lookups and writes are much faster than normal databases. These performance advantages allow Redis to be used for session caching, page caching, message applications, and counting. GitHub, Weibo, Pinterest, Snapchat, Craigslist, Digg, StackOverflow, and Flickr all use Redis because of its speed and reliability. It is supported by almost all major programming languages, notably JavaScript, Java, Go, C, C++, C#, Python, Objective-C, and PHP.

Redis also allows for sub/pub interactions and messaging. Basically, a client sends a “SUBSCRIBE <whatever>” command and then connected to that Redis can “PUBLISH <whatever>” and the subscriber is updated with that information.

Users can also unsubscribe using the “UNSUBSCRIBE” keyword. Redis tracks clients and using a pubsub_channels variable that links subscriptions with specific connections to clients.

Since Redis is stored in memory, you cannot have data larger than the memory available. This can be a problem for large files or very complex data-structures. If Redis runs out of memory, it can cause Redis to crash or slow down substantially while it tries to juggle resources. Another issue is that Redis is single threaded and does not allow multiple interactions at the same time, however they are working on making it multi-threaded, and right now you can use multiple instances of Redis at the same time to effectively act like it’s multithreaded.

Redis is different from other Databases in that it stores its data in memory, acting as sort of a database and sort of a cache. The data is also stored on disk in a format that is not very conducive to random access, but allows for the cache to be rebuilt after system restarts or power interruptions. The access of data is also different from other databases in that the data is not accessed via query to the database engine, but instead is a specific set of instructions that are performed on abstract data types. It also makes use of Forks to serve data to people and copy data to its persistent memory. Redis allows for storage of keys and values as large as 512MB meaning that you can have a key/value pair that is as large as 1GB

Resources:

https://codeburst.io/redis-what-and-why-d52b6829813

https://en.wikipedia.org/wiki/Redis

https://dzone.com/articles/10-traits-of-redis

https://making.pusher.com/redis-pubsub-under-the-hood/

Developed by facebook in 2012, graphQL is a language used to query data from apis. It was used exclusively in house by facebook until it was made public in 2015. in 2018 it was spun off into a foundation under the control of the linux foundation. It was designed for more flexibility and efficiency than RESTful APIs.

GraphQL is an alternative architecture for APIs to serve data. instead of the traditional REST architecture where GET and POST requests are made to endpoints, GraphQL allows for querying data directly from one endpoint. The client decides the structure of the data they want to receive, which cuts down significantly on unnecessary transfer of large quantities of useless data. Instead of sending the request to a specific endpoint and getting back all the data from that endpoint, GraphQL allows you to send a GET request with a specific query and receive just the wanted data back in the format specified.

A big difference between GraphQL and REST is that on a REST API you have to know the specific endpoints for where the data you want is kept. This can be inefficient if you need data from different endpoints. It can also be confusing if an API is not well documented. With GraphQL you just need to send a query to the GraphQL server and then the data is returned to you in the format you requested. This also prevents under and over fetching.

For example say you wanted to get a list of user names, posts, and friends from a server. With REST you would send a GET request to the ‘/users’ endpoint, you get back an JSON object with an array of client objects. Each of these objects contain a user name, a birthday, and an address. The only data you wanted was the name of the user, so you now have all this data that you have to parse, just to get to the information you wanted in the first place. Also if their is a giant user list you would be using unnecessary resources every time you wanted to get a new user’s name. Another equally frustrating problem with REST is under-fetching data. So now that we have a list of the users that we needed, we also want to get a list of posts that each client is working on. So now for each client we have to make another GET request to ‘/users/<user_id>/posts’ followed by a separate GET request to ‘users/<user_id>/friends’. We then have to parse the data we get back from the friends endpoint just to get the names of the friends. If we have a large user list, this is a large amount of requests, just to get the name of a user, their posts, and their friends names.

GraphQL uses a strong type system that allows for the user to know exactly what they are getting from the server. The schema for the server defines all the types that the API allows access to. This allows the client to know exactly how to access the specific data that they want as apposed to just getting back a collection of possibly useless data from an endpoint.

While more familiar and popular, RESTful APIs are not without their faults. For smaller projects with few endpoints and specific data, they are just fine. However when you have huge sets of data, GraphQL can be much more efficient and precise. GraphQL allows the user to truly control how and what data they get back from an API.

Asynchronous code is code that lets many things happen at the same time. a process starts, the code continues to run in the background, and then the first process finishes and then the program uses the result. Since javascript is not a multi-threaded programming language we have to use asynchronous code to perform actions that take a while. For example when a program makes an http request to a server the request is made, the rest of the code following the request is then run and then when the http request is finished we can then handle the data we received. This can cause problems for programs since javascript will just keep running without waiting for that response from the http request.

Callbacks can help solve this problem. Callbacks are functions passed into other functions as an argument. When passed into an asynchronous function they are able to handle data that we have to wait to receive. For example when we make an http request with a callback we make the request with an async function, pass in our callback and inside the callback we have our code to handle the request when it comes back. The callback function just sits there waiting until the async code is finished before it is even executed, allowing us to ensure that the data we are getting is handled correctly.

Callbacks, while useful have their drawbacks. The biggest drawback is readability. It can be difficult to see what is going on in a long string of callbacks, otherwise known as callback hell.

Promises are objects that are created using the Promise constructor. Promises have a promise function that has two callbacks, resolve and reject. promises have different stats, fulfilled — the function of the promise succeeded, rejected — The function of the promise failed, pending — we’re still waiting for the function to finish, and settled — it’s with been fulfilled or rejected. Once the promise is settled, the data is sent to the resolve callback and is returned. if it failed the error is sent to the reject callback.

Promises allow for easy chaining and easy error handling. When a promises is returned the .then method on the Promise can be called and used to access the data from the promise-returning function. These then calls can be chained together and each subsequent return from a .then statement is passed along to the next .then statement. Errors are thrown to a .catch method that allows you to handle the error and keep the code working.

What is the DOM — The DOM, which stands for Document Object Model, is a tree-like structure used to represent the structure of a websites HTML, XHTML, and XML document. Each node on the DOM tree is an object that represents a part of the website. For example the <body> tag at the top of a website’s content would be like the root, the other tags that are contained within the body. Those individual tags could contain more tags and so on. The DOM can be changed an manipulated and then will re-render the content of a website. This can be very time consuming considering how large websites can be these days.

What is the virtual DOM — The virtual DOM attempts to help rectify this problem. Many javascript frameworks will inefficiently handle DOM manipulation. React has tried to fix this by implementing the virtual DOM. Every DOM object has an associated virtual DOM object that mirrors the actual DOM object. React re-renders the virtual DOM whenever a .jsx object is rendered. Even though re-rendering the entire real DOM is costly because it has to redraw the entire actual website, re-rendering the virtual DOM just changes the virtual DOM structure. React then compares the new virtual DOM with the virtual DOM before the changes were made. It finds the objects that have changed and then re-renders those elements to the actual DOM, saving time by only redrawing those DOM objects. This is called ‘diffing’, it checks to see which objects need to be discarded and which ones need to be updated and it makes those necessary changes.

The virtual DOM is necessary to speed up the process of handling dynamic properties and events inside an HTML document. Since JS can manipulate the DOM directly it is important for DOM re-renders to be as efficient as possible. Using the virtual DOM allows these actions to be preformed quickly and with the least steps possible.

The basic idea behind same origin policy is that websites are allowed to access data from another web page, but they must have the same origin. This only applies to scripts and prevents malicious scripts from running from one page accessing data on another. Since javascript can manipulate the DOM it has access to all the HTML elements.

function createCORSRequest(method, url) {

var xhr = new XMLHttpRequest();

if ("withCredentials" in xhr) {

// XHR has 'withCredentials' property only if it supports CORS

xhr.open(method, url, true);

} else if (typeof XDomainRequest != "undefined") { // if IE use XDR

xhr = new XDomainRequest();

xhr.open(method, url);

} else {

xhr = null;

}

return xhr;

}

If you were logged into a website with sensitive data and you forgot to log out, without CORS you would be vulnerable to another website that you visit accessing your data from the site you forgot to log out of. You would never know that your data had been accessed or that a malicious script was even run.

How can we deal with this problem? Same origin policy works by looking at the website a script is coming from and checks to make sure it has the same. It checks to make sure it has the same protocol like http:// or https://, it checks to make sure the subdomain is the same like www. or video. or drive.. then it checks if the domain name is the same. finally it makes sure that the port is the same. If all these are the same than the same-origin policy allows the site to run a script on another site.

While this is great at preventing cross site scripting, same-origin policy is a problem for websites that span multiple subdomains or domains. This can also be a problem when we send AJAX requests to servers.

Enter CORS. With CORS, or Cross Origin Resource Sharing the site sending a script sends a special ‘origin’ header that has the origin of the script. The server then sends the header ‘Access-Control-Allow-Origin’ allowing the site attempting to pass the script to run that script on another domain. The major problem with CORS is that it is difficult for developers to know exactly what domains they want to give access to the ‘Access-Control-Allow-Origin’ header, so they often just use a * wildcard. This basically undoes any of the protections that CORS provides.

Security is important to web developers. Policies like the same-origin policy help to mitigate these threats while still providing functionality. Using tools like CORS can further provide functionality and usability for developers so that we can provide services across domains and subdomains.

Resources:

Info

http://www.aosabook.org/en/500L/the-same-origin-policy.html

https://en.wikipedia.org/wiki/Same-origin_policy

http://www.ajax-cross-origin.com/how.html

https://zinoui.com/blog/cross-domain-ajax-request

Graphics

https://en.wikipedia.org/wiki/Same-origin_policy

https://doepud.co.uk/blog/anatomy-of-a-url

https://zinoui.com/blog/cross-domain-ajax-request

What is a tree? The basic structure of a tree is simple. A tree is a data structure. we call it a tree because its structure resembles an upside down tree. the top node of the tree is called the root, the child nodes of the root are called branches, and nodes without children are called leaf nodes. Values are stored on each node and nodes are accessible via their parent nodes.

So what is a B-Tree? The basic structure of a B-Tree is slightly different from a traditional tree. It still has root, branch and leaf nodes, but unlike a traditional tree structure, all the leaf nodes must be at the same depth as each other. this means that the leaf nodes will all be n branch nodes from the root. This is achieved by the b-tree’s unique features.

What makes a B-Tree unique? Each node of a B-Tree contains keys. The minimum amount of keys on the root is 1. If k is the number of keys on a node that node will have k+1 child nodes. This is because of how data is stored on a B-Tree. If we look at the constructor function below for a B-Tree node, you’ll notice that this._children is the size this._children plus one.

const NKEYS = 4;

function BTreeNode() {

this._keys = arrayOfSize(NKEYS);

this._children = arrayOfSize(NKEYS + 1);}

If the node contains one key, the children to the left of the node will contain lesser values, and the node to the right will contain larger values. If there are two keys, k1 and k2 , the left child contains values less than k1, the middle child will contain values between k1 and k2, and the right child will contain values greater than k2. As nodes fill up with values, they split. The tree then balances by passing the values. If a node on the left right of the tree fills, it passes its value up and a new tier or leaf nodes is created.

What are the benefits of B-Trees? The time complexities for search, insert, and delete is O(log n). B-Trees are still a self balancing tree like a binary tree, except it can contain more than two child nodes per node. They are great for storing large amounts of data. Since large amounts of data need to be stored on disk drives and not in memory, speed of read time is important. With the help of an auxiliary index can help speed searches, having only 1% of the entries of the B-Tree, it can tell you on which blocks to start your search, cutting your time down immensely.

B-Trees are a self-balancing data structure. They are ideally suited for working on large databases of information. Their unique structure allows them to store multiple values on each node and always have one more child node than number of the values stored. All leaf nodes are at the same depth, which helps to balance the tree and keep the time complexity for search, insert and delete to O(log n).

Resources:

Info:

https://www.cpp.edu/~ftang/courses/CS241/notes/b-tree.htm

https://www.geeksforgeeks.org/b-tree-set-1-introduction-2/

https://medium.com/basecs/busying-oneself-with-b-trees-78bbf10522e7

https://www.bluerwhite.org/btree/

https://www.chiark.greenend.org.uk/~sgtatham/algorithms/cbtree.html

Graphics:

https://www.cpp.edu/~ftang/courses/CS241/notes/b-tree.htm

https://en.wikipedia.org/wiki/Tree_(data_structure)

https://pixabay.com/vectors/tree-autumn-winter-forest-1994653/

https://en.wikipedia.org/wiki/B-tree