Forem: Cielo Raymundo

Message Queues

Cielo Raymundo — Mon, 20 Jul 2020 03:58:03 +0000

In this blog we will be going over what is synchronous, asynchronous, what's the difference between the two, and finally an overview of message queues.

Synchronous v Asynchronous Processing:

Synchronous processing is when a caller sends a request for a task and waits for the response before continuing its work. A caller can be a function calling another function, an application or system sending requests to a server. In general, for all of these situations the caller has to wait for the response before continuing.

Meanwhile with asynchronous processing, a caller does not have to wait for a response to come back in order to continue its work.

Lets take for example: the process of making breakfast, we need to make our coffee, eggs and toast. If we were to do this synchronously we would put our coffee to make first and wait until it is done. Once our coffee is ready then we can start on our toast, after we finish making our toast we can now start on making the eggs.

On the other hand if we were to do this process asynchronously, we would put our coffee to make, then we would put our to make, and start on our eggs.

The main difference between these two approaches is that, working asynchronously does not leave you motionless. You don't have to wait for one task to be finished in order for you to continue another.

Message Queues:

Now what is a message queue? Well, in short it is a component that buffers and distributes asynchronous requests. Main responsibility is to be available at all times for message producers and accept their messages. Also focuses on buffering messages and allowing consumers to consume relevant messages. By using message queues we can achieve asynchronous processing when synchronous processing is the default.

Messages:

A message is assumed to be a “one-way” request, a piece of data needed to perform a request. They are created by message producers and buffered by a message queue. After all of this they are sent to message consumers that perform the asynchronous action for the producer.

Message Producer:

Part of the client code that initiates asynchronous processing. Their job consists of creating a valid message and sending it to the message queue. The application developer decides where producers execute and when they should publish messages.

Message Consumer:

Main responsibility is to receive and process messages from the message queue. Are implemented by the application developer, a consumer is a component that does the actual asynchronous request processing. In an application the consumer would pick up the messages from the queue and send them to servers. All consumers do is read messages from the queue and process them.

Producer and consumers usually run as a separate process or execution thread in scalable systems and are usually hosted on different servers . For more flexibility they are often implemented in different technologies. They both work independently and are only coupled by the message format and the message queue location. By having them be separated we get the benefit of nonblocking communication between the two and they can be scaled separately.

The core part of the message queue is the queue itself, it's where the messages are sent and buffered for consumers. A message queue is a component that can have way more responsibilities like: permission control, routing, failure recovery, and is often implemented as an independent application. When having all of these responsibilities it is usually referred to as a message broker or message-oriented middleware. Brokers are just more sophisticated message queues, they are optimized for high concurrency and high throughput. Implementing brokers increases the infrastructure complexity.

____ Thank you for reading!!!

HTTP Caching Tech

Cielo Raymundo — Mon, 13 Jul 2020 21:31:11 +0000

In this blog we will be going through what is caching, what is http caching and an overview of some http caching technologies out there for us to use.

What is Caching?

Caching reduces time and resources needed to generate a result. Caching doesn't fetch data from the source instead it builds the result once and stores it in cache, where subsequent requests can be satisfied by returning cached results. Caching objects are stored in the cache until they expire or are explicitly deleted.

HTTP Caching:

Now since we know what is caching, what exactly is “HTTP Caching” ? As you may know HTTP is a protocol used throughout the internet. Since it has been around for a while now, some extensions have been added to its specifications that allows the web infrastructure to cache HTTP responses.

All caching technologies working in the HTTP layer work as read-through caches. Read-through caches are caching components that can return cached resources or fetch the data for the client. If the request cant be satisfied from the cache the client connects to the read-through cache rather than to the origin server that generates the actual response. This is transparent to the client, since the client cant distinguish if they received a cached object or not.

When a client sends a request, it is sending that request with headers that include different methods. In these headers we are able to control caching of our web pages. Cache-Control is a header that allows you to decide how you are going to be storing the responses to your clients.

The HTTP protocol gives you a lot of flexibility on how you want to deploy caching between client and server.

HTTP Technologies:

HTTP-based caching is easy to plug into existing applications, the four main types of HTTP-caches. They include: browser cache, caching proxies, reverse proxies and CDNs.

Browser Cache:

It is one of the most common types of cache which is built into all modern web browsers. These built in caching capabilities reduces the number of requests being sent out. Before a request is sent the browser first checks the cache for a valid response, if there is a valid and fresh response then the browser will use that instead of sending the request.

Caching Proxies:

It is usually installed in a local corporate network or by an Internet Service Provider (ISP). This is a read-through cache that is used to reduce the traffic caused by users by reusing responses between those users. The larger the network is, the more they are able to save which is why it was common for ISPs to install caching proxies and route all of its traffic through them in order to cache as many requests as possible.

Reverse Proxy:

Works the same way as a regular caching proxy, but by placing a reverse proxy in your data center it reduces the load put on your web servers. By using reverse proxies you can get more flexibility since you can override HTTP headers and better control which requests are being cached and for how long.

Content Delivery Network (CDN):

A CDN is a distributed network of cache servers that work similarly to cache proxies. They depend on the same headers but are controlled by the CDN provider. By using a CDN you reduce your server's load put, save on network bandwidth, and improve the UX by pushing content closer to the user. CDNs usually have many data centers around the world which allows them to serve cached results from the closest cached server. You can implement this by creating a “static” subdomain and generating URLs for all your static files using this domain. Configure the CDN provider to accept these requests and point these URLs to the CDN provider. If a CDN fails to serve a response then it forwards the request to the original server and cache that response. You can also configure CDN providers to serve sciatica and dynamic content so that clients never connect to your data center directly.

Thank you for reading!!! :)

Intro to Replication

Cielo Raymundo — Fri, 10 Jul 2020 12:40:46 +0000

In this blog we will go over the basics of replication in MySQL, and why it's useful.

What is Replication?

Replication is the ability to have multiple copies of the same data stored on different machines.

Replication in MySQL:

Allows the synchronization of two servers state, one server is referred to as the “master” and the other “slave”. But for now we will be referring to them as “parent” and “child”. When using replication your app can connect to a child in order to read its data, but can only modify this data on the parent server. Here’s a little overview of how statement replication works:

The client will first connect to the parent server and will execute the modifying statement. After it’s executed it will be written to a binlog file, the parent server then sends a response to the client and continues with other transactions.

Parent:

The parent records all modifying statements (creating, deleting, updating statements) to what is called a binlog. Every statement is saved with a timestamp, sequence number. Once the statement is in the binlog it can then be sent to the child.

Child:

When the child server is connected to the parent, it can ask for the updated binlog file. During this process the child sends the last sequence number it saw, the parent sends its binlog from that number. The child then saves these statements into its own copy called relay log, once it's written onto it, it is executed on its data set and the last seen sequence number is updated.

Because replication is asynchronous, this means that the parent server doesn’t wait for the child server to get the statements copied. The parent will continue to write statements to its binlog even if the child server is not connected. Asynchronous replication also allows for decoupling meaning that a parent can connect or disconnect a child anytime without affecting the parent. The child makes sure to keep track of the last statement sequence number so it can retrieve the correct statements. Once a child is disconnected from the parent, the parent will forget all about that child. Since MySQL replication is asynchronous, it allows decoupling which means the master can connect and disconnect slaves anytime without it affecting the master, and the master does not need to keep track of its slaves, which allows for interesting topologies. Some of these topologies are:

Having Many Children:

Instead of having only one child server you can create many child replicas and distribute read queries around them. By having multiple children the children don't interact with each other, and can be disconnected or connected at any time without affecting other servers. By having multiple children, you can:

Distribute read only statements among more servers. This is scaling by adding clones applied to database engines. You can use different children for different queries, for example one would be for regular application queries while another one is for long-running reports. By having a separate server you can insulate your app from input/output intensive queries.
Use MySQL replication to perform 0 downtime backups. All you need to do to backup a child machine is shut down the MySQL process, copy files to your archive location, and then start MySQL again. As soon as it connects back it will catch up with missed statements.
If one of the child servers stops working, you can stop sending requests to that server which will put it out of rotation until it is rebuilt. Losing a slave server doesn’t affect other servers since all the information saved by them is available to the master or other servers. When a server fails it has to be detected on the client side, so you can implement it with your own app logic or use a smart proxy/load balancer to detect it.

Master-Master:

In this scenario you have two servers in which they both accept writes, there is a parent A and a parent B. Parent A replicates from parent B and vice versa. Here we have all writes being sent to parent A, where they are being recorded to its binlog. Parent B replicates the same writes to its relay log and executes them to its own copy of data. Parent B then writes these statements to its own binlog in case other children want to replicate them. The same way parent B did this, parent A will also replicate parent B’s statements from its binlog by adding them to its own relay log, executing them and then logging them to its binlog.

This topology can be used for faster master failover and more transparent maintenance. If parent A fails at any point, your app can be configured to to direct all writes to parent B.
Switch between groups with minimal downtime. You can create two identical server groups by having parent A and parent B having the same amount of children. This allows your app to run with equal capacity using either groups. If parent A fails you can switch to parent B's group. This also helps with updating software or hardware on your parent databases. You can start upgrading parent B first and its children, once it is done stop the writes going to parent A which starts the downtime. Wait for all writes in parent A replicate to parent B. Once that is done you can direct all writes to parent B while you upgrade parent A and its children

Thank you for reading!!!
I hope this small overview of replication helps you :)

Function Centric Services

Cielo Raymundo — Mon, 06 Jul 2020 20:39:04 +0000

Function Centric Service is one of the main styles of web services, the other is Resource Centric Service. But what exactly are web services?

Web Services:

Services available through the web that create connections between entities (ex. client and server) to make sure they can communicate with each other, by handling the logic on how to interact/communicate.

Function Centric Services:

The basic concept is that by using function centric services you are able to call functions or objects methods on remote machines without needing to know information on them.

Actually trying to implement this in the real world was hard, even though it seems so simple. Since it had to be implemented across programming languages, everyone had to agree on a strict and precise way of passing arguments, converting values, and handling errors. In order to solve these problems function-centric technologies started to rise.

SOAP:

With time SOAP became the most popular one. SOAP stands for Simple Object Access Protocol. The most common way to implement it is by using XML to describe and encode messages. The http protocol transports requests and responses between clients and servers. SOAP allowed web services to be discovered and allowed integration code to be generated based on contract descriptors.

In an integration of SOAP, the web service provider exposes a set of XML resources, like Web Service Definition Language files that describe methods, endpoints and definition of data structures being exchanged with the XML Schema Definition (XSD). All these resources put together become the contract of the web service.

As SOAP progressed there were new higher level features being added, these unfortunately came with a price. Integrating different stacks became difficult since different providers had different levels of support for web services specifications.

JSON:

SOAP was too complicated and expensive to implement there was a need for an alternative. JavaScript Object Notation (JSON) based Representational State Transfer (REST) services started to gain popularity.

It is easier to understand and for machines to parse and generate. JSON will allow developers to implement communication how they want without its standards stopping them.

HTTP Sessions + Cookies

Cielo Raymundo — Thu, 02 Jul 2020 13:38:33 +0000

Before we get into what are HTTP sessions and cookies we must understand what “stateful” and “stateless” mean in an application.

Stateful:

For an application to be stateful it means that it has “knowledge” of past actions, as if it is keeping records. In statefulness this knowledge is being stored between requests of clients and servers. But because of this stateful apps have to stay in a selected instance since the information will not be available elsewhere.

Stateless:

While in a stateless application there isn’t a designated place in which this knowledge will be stored. Although there isn’t a place for the app to store its data of user server interaction, the user is able to use any instances of the app without seeing any difference as if it was stateful.

What are HTTP Sessions?

HTTP stands for HyperText Transfer Protocol, which is used all throughout the web. This protocol is stateless, so it doesn’t store any data. This itself is a problem that software engineers had to get around since they need certain data from the user in order for their web applications to work correctly. In order to do this the concept of “sessions” on top of HTTP came, these sessions are used to store information so that servers could recognize multiple requests from the same user.

Http sessions are now used throughout the internet as a standard feature that allows web servers to store data (requests/response interactions) between the users and the servers. They store information based on that specific session like: session identifier, creation time, last time accessed etc. they also store information about the user like: user login state, and other data the application may need from the user.

What are cookies?

A cookie is a small piece of data that a server sends to the user's web browser. The browser is able to store it and send it back with requests being made to the same server. Cookies are mainly used to check if the requests come from the same web browser. This helps see if a certain user is logged in in any application.

How do they work together?

Sessions can be implemented using cookies. When a new user sends a request to a web server, they are sending it without a session cookie. Because of this the server will start a new session for that user by sending a new session cookie header. This happens when the server sends a response, the server will serialize and encrypt the session data then it will include it in the response header. By having the sessions use cookies the server will be able to recognize the requests that are part of the same sequence of events. This allows servers to recognize which user all requests belong to no matter if other browsers are connected to the same server with the same ip address. The only problem with using cookies for your http session is that you can only save a small bit of data. Since a cookie is sent by the browser with every single request, no matter if the data is needed or not the storing of data can become expensive. Because of this, trying to save large bits of data onto a cookie will cause the requests much slower.

Brief Overview:

Http is stateless so it can’t keep any data of interactions that have happened. In order to solve this problem “sessions” were created on top of http. Sessions essentially allow you to keep data from the session itself and information about the user in the current session. Sessions can be applied using cookies, which keep in minimal information but are enough to see who all the requests being made belong to.

Scalability 101

Cielo Raymundo — Mon, 29 Jun 2020 14:00:06 +0000

What is scalability?

When people think about scalability they think about an app that can process requests quickly no matter how many requests are being sent. But this isn’t scalability, this is performance. It’s not uncommon for people to get these mixed up, many people tend to confuse performance with scalability. Performance measures how long a request takes to process or how long it takes to perform a certain task. Scalability on the other hand is how much an app can shrink or grow.

How is it different from performance?

For example, let's say you have an app that has 200 regular users. Each user sends a request over a 10 second period, that means on average there are about 20 requests being sent per second. Performance will measure how long each request will take to process, by focusing on performance you will try to find a way to decrease the time intervals of processing requests. By focusing on scalability, you aren’t focused on how fast each request is being processed but the ability to handle all of these requests during a time interval. While scalability will decide how many more requests and users can be handled at a time without affecting the user experience negatively.

What does it mean for an app to be scalable?

Scalability is the ability to change the capacity of the system in order to fulfill the new demands. Usually it means to “scale up”, which is basically being able to handle more users, data, requests etc. but it also means being able to scale down quickly and cheaply. Although scaling up is more important than scaling down, you should still be able to get rid of waste and inefficiencies. Scalability issues are usually concerned with:

Handling more data: as business grows and you have more clients/users your app should be able to handle more data.
Handling higher concurrency levels: servers have limited CPU and execution threads, so they can only handle a set amount of requests at a time. With higher concurrency levels you are able to get more active threads and more requests.
Handling higher interaction rates: this is the relationship between your system and with your clients/users, the rates measure how often they exchange information. As the interaction between the two grows, your system must be able to respond just as quickly.

Because scalability also has to do with how much data you are able to store, you need to ask yourself some questions like: What data are you going to be storing and how is it going to be stored now and in the future? Will I need to upgrade my hardware? By doing this you will be able to direct your app in the right direction, whether you need to increase how much data is being stored, or you want to get rid of unnecessary data no longer needed.

Why should we care that it is scalable?

When businesses are starting up, they should be able to be as flexible and as resourceful as they can be. They should be able to adapt to changing conditions quickly, in order for them to stay relevant and up to speed with their competitors. If your app is scalable it will enhance your growth, it will offer great user experience and will attract a greater audience. Scalability will allow you to better manage your app, and adapt to the new demands. If you are planning to grow your business, then building a scalable app should be the first thing you plan for. Being prepared in the beginning will save a lot of headaches in the future.

Variable Hoisting and Scoping

Cielo Raymundo — Wed, 18 Dec 2019 16:41:18 +0000

What is Hoisting in JavaScript?

Hoisting happens during the compile phase of a program execution. During this phase, the program is scanned and for variable and function declarations. They are all then added to a data structure called the Lexical Environment, where all of these declarations are stored in memory. Although it stores the declarations it doesn’t necessarily set the variable's value. Their values aren’t set until the engine reaches its actual initialization. You can read more about hoisting here.

                     LexicalEnvironment = {
                        variableName:  <value>,
                        functionName:  <function object>
                     }

What is Scoping?

Scoping in JavaScript defines where variables can be accessible and visible from, it allows another part of the program to access them depending on where it is. There are three different types of scoping 1) Global 2) Block and 3) Function. You can learn more about scoping in this article.

Hoisting and Scoping with ES6 JavaScript:

With the newest version of JavaScript, ES6, two new keywords were introduced to declare variables. We already had ‘var’ and now we have ‘let’ and ‘const’.

                           var varName = 0;
                           let letName = 0;
                           const constName = 0;

‘var’ variable declarations:

When hoisting with a var variable, as explained above the program engine runs a scan for variable declarations. When it runs into a variable declaration with the keyword ‘var’ it will add it to the lexical environment and initialize it with a value of undefined. Later while the program is being executed it will reassign the variable to its actual value.

              LexicalEnvironment = {
                         variableName:  <undefined>
                      }

Because var variables are being hoisted like this, you can access the variable before it has even been declared as long as it is being accessed from within its scope.
Variables declared with var can only have a function scope or global scope. A function scope means that the variable can’t be accessed from outside the function it is declared in. If it is not declared inside a function then it has a global scope, which means it can be accessed from anywhere in the program.

                             //Global Scope:    

                             var newNum=0;               
                             function double(num){             
                                newNum = num * 2;                 
                                return newNum;               
                             }                           

                             console.log(newNum);            
                             //will console log 0                    
                             //assignment is being done          
                             //inside the function the 
                             //original Variable is 0

                            //Function Scope:

                            function double(num){
                              var newNum = num * 2;
                              return newNum;
                            }
                            console.log(newNum);
                            //will throw an error you
                            //can’t access the variable 
                            //outside the function

‘let’ and ‘const’ variable declarations:

When hoisting a variable with the keyword of ‘let’ or ‘const’ while the engine is scanning for variable declarations it saves them in the lexical environment but doesn’t initialize them at all. So if you are trying to access this variable even before it is declared, the program will throw a reference error.

While ‘var’ variables have global and function scopes ‘let’ and ‘const’ variables only have block scopes, but can also have a global scope. Block scopes means that they are only accessible from within the block (curly brackets) where they are declared. If the variable isn’t declared within any pair of curly brackets, then it has a global scope and can be accessed from anywhere in the program.

                           //Block (Global) Scope:

//With "let" keyword
                           let newNum = 3;              
                           if (true){               
                             newNum *= 2;               
                             console.log(newNum);          
                           }                    

                          //will console log 6,                
                          //since newNum has a global       
                          //scope it can be accessed        
                          //from within the function        

//With "const" keyword
                          const newName = 3;
                          function double(num){
                             return num * 2;    
                             console.log(newNum);
                          }
                         //will log 3, since it
                         //has a global scope
                         //it can be accessed 
                         //from within the function

                                //Block Scope:

                         if (true){             
                           let newNum = 3;             
                           newNum *= 2;               
                         }                  
                         console.log(newNum);

                        //will throw a reference        
                        //error since newNum isn’t        
                        //accessible from outside       
                        //the block (if statement)      

                        if (true){
                          let newNum = 3;
                          newNum *= 2;  
                          console.log(newNum);
                        }

                        //will log 6  
                        //since newNum is 
                        //accessible from outside
                        //the pair of curly brackets