With CS 343’s final project beginning, I have looked into some ways of displaying data. For this week, I will focus on Angular’s CDK. In Netanel Basal’s article “Creating Powerful Components with Angular CDK,” Basal describes the process of making an overlay in angular. He starts with creating a Popover service, Popover being a component from the CDK. This component is used for creating popup overlays, such as info that pops up while the mouse is hovering over something. Basal then creates the PopoverRef and its Injector. The PopoverRef is then injected into a ComponentPortal which is then attached the origin page. Portals dynamically render UI to the page. For the portal, the author creates a custom component to receive the contents to be displayed and how to render them. The article then covers three types of content the PopoverComponent can receive: text, template, and component. With that, the article’s example is completed. Now let us get a little more in-depth.

Let’s start with the Popover service. This service creates an open() method that creates the overlay, its contents, and its injector. This service is injected into the Popover component, where the open() method is utilized in a show() method in the app component that is called on when a button is clicked in the root component HTML. From what I understand, this service handles the creation of all the parts needed to make the popover with an open() method.

Next up is the PopoverRef, a class that receives a overlayRef, content, and data, and creates a close() method to dispose of the overlay. It seems that this class is used for the storage of the parent overlay, the content, and the data, and the close() method that removes the popover.

Since Basal wanted to use a custom component, he needed to create an Injector for it. The injector is created in the Popover service in a createInjector() method, which converts the custom injector to a PortalInjector.

The author then attaches the soon-to-be-created Popover component to the overlayRef in the popover service. This is done by overlayRef’s attach() method, where a new ComponentPortal containing the PopoverComponent is attached to the overlayRef.

The Popover component’s job is simple, just to inject the popoverRef and render its contents. This article’s example provides multiple rendering methods depending on content type. The three content types being template, component, and text.

For all three types, a show() method is added to app component that injects PopoverComponent and creates a Popover from popover service. The only difference between the content type’s show() is what the content in Popover is set to. This method is called on in the app component’s HTML where it is attached to a button.

Reading through this article and examining its code has helped me towards learning how to create popup overlays. I feel I have a more solid grasp of how angular components interact with each other. I will undoubtedly use knowledge I gained from the article, “Creating Powerful Components with Angular CDK” by Netanel Basal, in my final project.

Article Referenced:
https://netbasal.com/creating-powerful-components-with-angular-cdk-2cef53d81cea

For this week’s post I read through Michael Karén’s article, “Game Development: Tetris in Angular.” As the name suggests, this article demonstrates how to make a Tetris game in Angular. This is a great example project that shows many of Angular’s functionalities without being too complex. It covers topics introduced in CS 343: components and templates, and other topics like styles and event listeners. The author’s project code can be viewed on GitHub for further examination.

The project contains three components (with @Component decorator): app, board, and piece. The app component is the main component that uses the board component as a template. The board component handles the board UI and injects the game logic from GameService. And lastly, the piece component handles the UI and properties of the Tetris pieces.

Templates are used in two ways in Karén’s game. The app-root which uses another component as its template by using the custom tag <game-board></game-board>. The game-board uses a URL as a template, which is defined in the board component’s HTML file. This HTML file defines how both game-board and, by extension, app-root are rendered on the page.

The injectable class (with @Injectable decorator) game.service contains much of the game logic. As an injectable, game.service’s methods are accessible to board.component when game.service is injected in board.component, located at the example code’s line 72 with “constructor(private service: GameService) {}.” This is useful as it is cleaner to separate the responsibility of the game logic and the UI logic from each other.

The styles are defined in a Cascading Style Sheet or CSS file. The CSS file is used to define how some of the HTML elements are designed. CSS makes HTML design simpler with its more intuitive interface.

I learned a new decorator from this article, @HostListener. This decorator can be used to define the program’s response to user interaction. In this article’s project uses @HostListener to define how the game board responds to the specified keystrokes.

The JSON methods stringify and parse were also new to me. JSON.stringify will convert an object into a string. JSON.parse on the other hand, converts a string into a JSON object.

Reading through this article and examining the project’s code has helped my understanding of Angular and HTML tremendously. I recommend Michael Karén’s article, “Game Development: Tetris in Angular,” to those who are looking for a fun example of an Angular program.  Being able to see all the parts of the program and how they work together has made Angular more accessible for me and has provided an excellent resource for possible projects in the future.

Article referenced:
https://blog.angularindepth.com/game-development-tetris-in-angular-64ef96ce56f7

The topic for my post this week is Angular. CS 343, Software construction, design, and architecture, introduced REST API frontend last week. I did not have a good grasp of what Angular is, so I read the article “Angular Tutorial: Getting Started With Angular 4”, by Shubham Sinha. The article breaks down Angular into easy to understand parts which are then explained thoroughly.

The article begins with describing the general history of Angular and why it was designed. Originally AngularJS, Angular was designed for the use in designing SPAs (Single-Page Application). SPAs are useful as they do not require an entire page to be refreshed. Instead SPAs only refresh necessary components. This allows for SPAs to act similarly to desktop applications.

The article then begins its tutorial, though I would describe it as an overview of the details of Angular projects. The author goes into the different parts of Angular and describing them each in detail.

• Modules:                           
  Chunks of code with a specific task, such as classes.
• Components:                   
  Code that use API to control sections of the screen. Contains instructions for client-side GUI.
• Templates:                        
  HTML tags that describe how to render components.
• Metadata:                          
  The code that informs Angular on how to process a class.
• Data binding:                   
  The connection used to tie parts of a template to parts of a component. An easy connection for data state and data events.
• Directives:                         
  Logic code for manipulating data: adding, removing, changing.
• Services:                             
  A wide category for encompassing anything an application my need.
• Dependency Injection: 
  Allows Angular to create new instances of a class with all its dependencies that can be “injected” into another class.

From what I understand, the page code will be divided into modules. The page view will be divided into components that use templates and metadata to determine how to display the component. Directives are logic code that manipulate data. Data binding allows for easy access to a data’s state and events. Dependency injection inserts an instantiation of a class with all its dependencies. Finally, services are simply anything an application may need: value, function, feature.

I found that after reading this article I have a better understanding of Angular. Angular can be used for client-side rendering of data. By separating the page into several different components, Angular can create SPAs that are dynamic and responsive. This article is informative and accessible, I highly recommend this article to anybody who is getting acquainted to Angular.

Referenced Article:
https://www.edureka.co/blog/angular-tutorial/

This week I have chosen to deepen my understanding of REST API. The article, “RESTful API Design Tips from Experience” by Peter Boyer, goes over good RESTful design practices. The article covers many topics, including some I do not have experience with but are still useful for a greater understanding overall.

The article proposes that the API should state its version in the URLs. The author suggests adding a prefix to all URLs to specify API version. This makes the eventuality of version updates easier to handle.

A simple tip mentioned in the article is the use of plurals. When designing endpoints, plurals should be used instead of the singular form. This is to avoid possible misunderstandings of what the endpoint is used for.

Example:             /orders/customers          VS           /order/customer

Another tip in the article is to use nesting for relationship filtering. From what I understand, it is better to have multiple path variables for filtering than the use of query strings. The example in the article is very clear on the tip. Following this advice will make your endpoints easier to read.

The author advises to keep your API as flat as possible. He suggests that creating and fetching data should have a longer resource path than updating and deleting data. I do not really understand why this is the case. My best guess is the shorter path reduces unnecessary processes.

The next tip I found interesting was the important, if not obvious, idea for pagination of results. When working with larger databases, requests can have thousands of results. Since it would be impossible to display all the data, it makes sense to partition the results into pages and return one page at a time. Pagination can also significantly reduce the expense of a request.

The last tip I will mention from the article is the usage of status codes.  HTTP status codes should be used consistently and properly. This means the status should use the proper code and provide additional details when necessary: an error code with a message of why the error occurred.

Overall, I found Boyer’s article to be very informative. I only mentioned a few of the topics raised in his article but all the topics are interesting and useful. Reading through this article gave me a better understanding of the nuances of RESTful API design and has helped me comprehend my current coursework (CS343) better. I suggest to anybody that is new to REST to read this article.

Article Referenced:
https://medium.com/studioarmix/learn-restful-api-design-ideals-c5ec915a430f

For this week’s blog, I have decided to go over the SOLID set of design principles. The blog article “SOLID design principles: Building stable and flexible systems” by Anna Monus describes SOLID and gives solid examples of each design principle with code and UML diagrams.

Single responsibility

Each class should only have a single responsibility, such as handling data or executing logic. While this increases the number of classes in a program, this will allow easier modification of the code and code clarity.

Open/Closed

Classes should be open to extension and closed to modification. This means that new features should be introduced through extension and not through modifying existing code. The open/closed principle allows programs to expand with new features without breaking the old.

Liskov substitution

Named for its creator Barbara Liskov, the Liskov substitution principle states that a subclass should be able to replace its superclass without breaking the properties of the program. This means that a subclass shouldn’t change its superclass’ characteristics, such as return types. Following this principle will allow anything that depends on the parent class to use the subclass as well.

Interface segregation

Interface segregation states that classes should not have to implement unused methods from an interface. The solution is to divide the interface so that classes can implement only the desired methods. I found this principle to be easier understood from a visual example and I found the article’s UML diagram for interface segregation useful for this.

Dependency inversion

High and low-level modules should depend on abstractions. It is common to think that high-level classes should depend on low-level classes, but this makes expanding the code difficult so it’s best to have a level of abstraction between the two levels. The article’s UML example for this principle shows how the abstraction level allows for easy expansion.

The SOLID principles are important for code architecture as it makes code expansion simple and easy to understand. I have found myself applying SOLID principles to a project I have been playing with, a simple GUI animation. Originally, I had drawn objects handling their own draw and movement methods, but by using the single responsibility principle I separated the movement-based code to its own class and used composition between classes. This allowed for me to be able to use the movement code (contains position, velocity, and acceleration values and methods) for all the different objects that I make. I also made use of the O, L, and D of SOLID to handle the drawn object hierarchy allowing my frame class to depend on an abstraction of all my drawn objects. I use a loop to cycle through all drawn objects in a linked list that’s type is an abstraction of all drawn objects. I can tell that the structure of the code has made adding new functionality easy and intuitive.

Article Link:         https://raygun.com/blog/solid-design-principles/

The article, “REST vs. RESTful: The Difference and Why the Difference Doesn’t Matter,” examines the Representational State Transfer pattern, or REST, and its implementations, RESTful services. The author, Eric Goebelbecker, mentions REST pattern’s creator Roy Fielding, and provides a link to Fielding’s dissertation.

 The article then defines REST’s architectural constraints. Client-server architectural style, separating responsibilities between client-side and server-side. Client-side will handle user interaction while server-side will handle data and state. This allows for the two sides to evolve independently of each other. Stateless, the server is not responsible for a client’s session state and instead, the client keeps the session state. Cacheable, the server must classify their responses as cacheable or not. This improves performance by allowing the client to store cacheable responses for later, equal requests. Uniform Interface, possibly the most important constraint, requires the use of a uniform interface for components. This simplifies the architecture by taking advantage of the software principle of generality. The final constraint mentioned in the article is a layered system. A layered system is a hierarchical system that encapsulates components to layers that can be independent of each other. This can be used for security and performance such as load-balancing. These five architecture constraints are what defines the REST pattern.

The article then gives an example between remote procedures calls (RPC) and REST. The difference being that RPC manipulate data by remote calling the server functions and REST, instead, shares the data between client-server. Put simply, in REST the URIs work with data and not remote methods.

The article then mentions the Richardson Maturity Model. Richardson’s model classifies RESTful services into four levels of compliance. Level 0, the use of RPCs. Level 1, sharing resources between server and client. Level 2, the proper use of HTTP verbs. And level 3, exporting hypertext with objects to aid with API discoverability. The author of the article brings up that Fielding would only consider level 3 to be true REST.

Before I read through this article, I had only a rudimentary understanding of the REST pattern (I had missed the class that introduced it). I now understand REST and RESTful, the architectural pattern and its implementations. REST focuses on data sharing and a uniform interface to make its data the emphasis of the pattern and not its specific implementations. This allows for easier understanding with generality and assists with scalability.

 I read some of Fielding’s dissertation and highly recommend it to anybody who is learning REST. The descriptions of the architectural constraints are clear and provide simple examples.

LINKS:
Article: https://blog.ndepend.com/rest-vs-restful/
Fielding’s Dissertation: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm