Christian Shadis

As I transition into the final semester of my undergraduate degree, I plan to learn Javascript. In my Software Construction, Design, and Architecture class, we briefly explored and edited some frontend code in Node.js and Vue.js. Using my prior knowledge in Java, I was able to understand how most of the code was functioning. As Javascript continues to rise in popularity, it would be a valuable language to add to my skillset. One of the fundamental aspects of learning Javascript, or so it seems, is to understand the Document Object Model (DOM). Having used his book HTML & CSS: Design and Build Web Sites to supplement my knowledge in web design, I decided to consult the fifth chapter of Jon Duckett’s Javascript and JQuery: Interactive Front-End Web Development to learn more about the DOM.

Duckett first specifies the DOM as a set of rules, separate from the HTML and CSS of the website, which “specifies how browsers should create a model of an HTML page and how JavaScript can access and update the contents of a web page while it is in the browser window” (Duckett 184). In other words, the DOM acts analogously to an API in that it facilitates or enables real-time communication between JavaScript code and the HTML page. Duckett proceeds to describe the DOM tree, the benefits of caching DOM queries, and how to traverse the DOM tree. He also described how to access, update, add, and delete HTML content from the page using the DOM. The chapter included a bit of bonus information such as cross-site scripting attack prevention and how to view the DOM in each of the major web browsers.

Reading this chapter was useful in contextualizing how the different parts of a webpage interact with each other. In addition to learning the fundamentals of the DOM, I also gained experience reading JavaScript code, which is a great way to learn how a language works. What stood out to me most about the material was the parallels between the DOM nodes and the LinkedList data structure. Having coded an implementation of the data structure in a previous course, it was intuitive to see how traversal of the DOM tree worked.

I plan to continue to learn JavaScript, and plan to read the remainder of the book. Web design is becoming more ubiquitous by the day, and thus a more valuable tool for developers to have. I would highly recommend this book and others by Jon Duckett to developers – the design is pleasing, he provides sample code, and offers excellent simplistic explanations.

Duckett, J. (2014). Document Object Model. In JavaScript & JQuery: Interactive Front-end web development (pp. 183–242). essay, John Wiley & Sons.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Christian Shadis

Over the past month, my Software Construction, Architecture, and Design course has shifted gears into a sort of crash-course for full-stack web development, as I mentioned in the last blog post. We have focused primarily on the backend, creating RESTapi endpoints in the api.yaml file, along with implementing those endpoints in Javascript. In the final two weeks of class, we are transitioning into implementing a front end using Vue.js. In the process of switching contexts, my understanding of the difference between a frontend and backend became a bit obfuscated.

In Frontend vs Backend, Maximilian Schwarzmüller first declares that the common refrain that each web app is built from a frontend and a backend. He then begins to describe the differences between them. In short, the difference between the frontend and backend of a web app is that the frontend refers to the content displayed in the browser, while the backend refers to the portion of the program which runs on a server. He gives the helpful example of Amazon – it consists of a frontend (the catalog, shopping cart, and other visual elements of the webpage) and a backend (all data/database management). He is careful to specify that the difference does not lie only in where data is stored, because there are non-database aspects of a backend as well, such as file system interaction or input validation. He also lists several skills and programming languages that a programmer may need in order to build the frontend (HTML, CSS,  Javascript, Vue.js / React.js / Angular) and the backend (Node.js, PHP, Python).

One area of confusion for me was understanding exactly how the frontend and backend communicated with each other – via HTTP requests. We had discussed and implemented HTTP requests in class, but I thought the communication occurring was between the backend and the database. In fact, the user performs some action on the frontend, resulting in an HTTP request being sent to the backend (and by extension, the database).

Knowing how to code both the frontend and backend of a web app is vital to become a web developer, but it is also important to be able to differentiate between them, and to understand why they are considered separate components of an app. I plan to work on developing the full stack of a web application from scratch, and the information from this article will enable me to begin development with a stronger understanding of how to build the frontend and backend properly to communicate with each other.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Christian Shadis

Over the past month, my Software Construction, Architecture, and Design course has shifted gears into a sort of crash-course for full-stack web development. Our initial focus was on the backend of web apps and specifically on APIs. In class I learned how to edit API endpoints for different HTTP methods such as GET, POST, and PUT. I understood how to code the API and I understood the difference between the different HTTP methods, but I still did not understand the very basics of what an API was beyond its acronym. For this blog post, I set out to learn the fundamental nature of APIs to supplement my technical understanding. While it is helpful to know how to code an API, the knowledge would likely be useless without an understanding of what an API is or when to use one.

An API (Application Programming Interface) is a technology developed as a solution for multiple applications needing to communicate despite their incompatibility. For example, a person running Google Chrome trying to view the available items on a store website requires their web browser and the store’s server to be able to communicate. This is unlikely to be possible without an API. The API allows Chrome to send a request for information to the server, and then allows the server to return the requested data (or an error message) in a particular format such as JSON. The API facilitated the exchange of information between a client application and an unrelated server. This example illustrates the necessity of APIs. Without them, communication among devices built differently would be impossible. Web browsing as we know it would not exist, nor would web-based phone applications.

In What is An API and How Does It Work?, Thomas Davis first describes the omnipresence of APIs in everyday life even for non-programmers, and contrasts that ubiquity with the fact that few people understand how an API works, let alone what it does. He describes the API as an intermediary between two parties that do not speak each other’s language, and provides everyday examples of situations in which one would desire two computers to communicate. Once he explained the base concept of an API, he described different types of APIs such as the REST API, the SOAP API, and the XML-RPC API, comparing and contrasting each.

Knowing how to code APIs is an important aspect of backend development, but I feel much more confident in my ability to code an API now that I more fully understand the concept. I expect to build backends for web applications in the future, so this knowledge should be helpful in my development career.

References:

https://towardsdatascience.com/what-is-an-api-and-how-does-it-work-1dccd7a8219e

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Christian Shadis

Docker, a main focus in my Software Construction, Architecture, and Design course, is an essential tool for the modern developer to be able to completely separate the application being built from the developer’s local machine. Essentially, this allows for all the application’s dependencies and configurations to be packaged with the application and independent of the machine the application is being run on. A Docker container is built from an image, which is basically the ‘blueprint’ of a Docker container. Images are easily-reusable, and many images can be found for use on the Docker Hub. Images can be created from scratch using Dockerfiles, which I previously did not understand. In order to improve my Docker skills and gain the ability to create my own Docker images, I chose to research and write about the structure and use of Dockerfiles.

There are situations in which a developer would want to create their own Docker image – maybe they need a specific version of the Ubuntu operating system, or there are specific modifications that need to be made to that operating system before the application can run. Maybe for an application to be run, many slightly modified versions of the same container must be deployed. The developer can address these scenarios by creating a Dockerfile, which contains all software to be included in the image. Any time the image needs to be used, a container can be created with that image in a single command, preventing the necessity of importing dependencies or changing the machine’s configuration repeatedly.

 In Docker Basics: How to Use Dockerfiles, Jack Wallen first describes the necessity and use cases of Dockerfiles. He then supplies a list of keywords that can be used in a DockerFile, such as CMD, which executes a docker command inside the container, ENV, which is used to set environment variables, and EXPOSE, which is used to publish networking ports in the Docker image. From there, Wallen proceeds to demonstrate the process to create a Dockerfile from scratch in a text editor. Finally, Wallen outlines the process for building the usable image from the Dockerfile. The article concludes with a short section including a second worked example, this time building a Dockerfile for a different operating system.

 Knowing how to create containers using pre-built images from DockerHub is an important first step for a developer to get started with Docker, but the true power of Docker images is realized when the developer has the capability to create a new image with the exact configurations needed. Creating custom images is a skill I expect to use often in my development career, since a large portion of applications in development today use Docker containers.

Reference:

https://thenewstack.io/docker-basics-how-to-use-dockerfiles/

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Christian Shadis

For the past couple weeks, my Software Construction, Architecture, and Design course has been focusing on the anatomy of simple REST APIs. While we were learning about how to create endpoints to retrieve data from the backend, it was as simple as just extracting the data from the database on the backend. This seemed too basic to me. Though I was sure there was still plenty of unexplored detail in the backend regarding security protocols, I was curious to see how security measures can be implemented in a REST API like the ones we have been working with.

Chris Wood discussed Security Scheme Objects and their role in the REST API, listing supported security mechanisms (Basic Authentication, API Key, JWT Bearer, and OAuth2.0), in his 2019 article REST API Security Design. He began by defining what a REST API Security Scheme Object is: a Component object (like Schemas or Responses) which “[describes] the security requirements for a given operation.” There is not a specific object for each of the mechanisms listed above, but rather a single Security Scheme Object that can represent any of the four mechanisms. The Object is defined in the top-level index.yaml file under the Components section, the desired mechanism is applied, and any additional arguments specific to the mechanism are passed. Once it is defined, the Security Scheme Object can be applied to individual endpoints or operations. For example, for some path /users/, we define an operation get, and underneath the parameters and responses section, a security section can be added containing an array of Security Scheme Objects to be applied. If we define a BasicAuth object and assign it to the get /users/ endpoint, other developers know that the operation should have basic authentication.

My main takeaway from the article was that my perception of API security was flawed. Whereas I had considered the idea of implementing security measures directly into the API itself, the article outlines instead that security measures in an API consist primarily as a guide or a definition of security requirements for other developers to uphold. For example, authentication itself is not performed inside our REST API by implementing one of these Security Scheme Objects. Rather, the API designer can specify that some specified authentication should be included in certain operations by defining them in the API.

While security measures in API design may not be as essential as I believed, the article asserts that it is a vital factor of API design. As I continue my career as a developer, I plan to develop all my applications in the most secure way possible. Since API design is such a fundamental aspect of web application development, I am glad to have gained some exposure to how security measures are implemented.

Reference: https://blog.stoplight.io/rest-api-security

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Christian Shadis               

Docker has been the focus of my Software Construction, Design, & Architecture class for the past couple weeks. In a software development environment, it is paramount that applications can run on different operating systems and in different runtime environments. When applications rely on several dependencies, it becomes cumbersome to install all needed libraries on every machine the application runs on. This is where Docker comes in handy, allowing the programmer to create a self-sufficient container holding all parts of the application, along with all of its dependencies. Anybody can now run an application using its container without having to install any dependencies on their local computer.

Applications, however, are often designed as microservices, each microservice in its own container. A software company may have tens, hundreds, or thousands of different containers that need to be deployed and monitored at once. It is plain to see how this becomes a scaling issue. Container orchestration emerged to address the scalability of containerizing applications. Container orchestrators, like Kubernetes or Docker Swarm, allow the automation of repetitive work related to the deployment and maintenance of containers, such as configuration, scheduling, provisioning, deployment, resource allocation, scale of containers, load balancing, monitoring, and facilitating secure interactions between containers. This is why I chose to read about container orchestration from the article “What is Container Orchestration” from Red Hat.

The article goes into detail on what container orchestration is used for and why it is necessary, along with listing its major functions. It also describes how container orchestration programs like Kubernetes are configured, along with a basic overview of the anatomy and behavior of a Kubernetes cluster.

Using Docker to containerize applications is a pivotal skill for developers to have. In a world where so much computing is moving toward cloud technology, however, it is also important to be able to use Docker Swarm or Kubernetes because a large portion of applications a developer will work on will be deployed on the cloud in some way. In those situations, traditional Docker knowledge will be of little use. Instead, the developer should be able to leverage a Kubernetes cluster or a Docker Swarm to work with large containerized cloud-based applications.

Before reading this article and writing this entry, I had no exposure to container orchestration, though I had wondered about the scalability of the small docker containers we have been working with in class. I learned the basics of the subject, and accrued a list of further references to read more about applying container orchestration in an enterprise setting.

https://www.redhat.com/en/topics/containers/what-is-container-orchestration

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.