Category Archives: CS-343

Designing Front End

The article I chose shows how strongly front-end design is linked to the structural principles I learn in Software Construction, Design, and Architecture. This is important to know because front-end design is often seen as the “visual” or “creative” side of development. I wanted to look into how these ideas apply to the front-end world because our class focuses on making systems that are scalable and easy to manage through patterns, abstractions, and good architectural choices. To show that UI design and software architecture are more connected than many developers think, this piece built a strong link between the two.

The article says that front-end architecture is a planned way to arrange code, components, styles, and interactions so that the app stays the same and can grow over time. The book talks about practices like using clear naming standards, modular components, reusable patterns, and separating concerns. These are all very similar to ideas covered in the course, such as the Stratified Architecture Model, the SOLID principles, and design patterns like Strategy, Factory, and MVC.

The idea that front-end design isn’t just about how things look but also how they are put together is one of the most important things I learned from the resource. In the same way that writers plan backend classes, the author says that UI components should be planned with clarity, purpose, and future change in mind. This made it easy for me to see how front-end design and software systems are connected. The same goals we have when using architectural principles to build software are met by a well-structured front end: fewer bugs, better teamwork, and easy addition of new features.

When I thought about this, I noticed how often developers rush through UI design without thinking about how to keep it up to date over time. I changed how I build interfaces because of the text. I used to only care about “making it look right,” but now I know how important it is to make parts that can be used again, are predictable, and fit in with the general architecture of the system. This fits with what I’ve learned in class about cutting down on duplicate code, making things more cohesive, and keeping the lines between layers clear.

In the future, I’m going to use what I’ve learned by making a library of components early on in a project, writing down UI rules, and making sure that the front end and back end can talk to each other clearly through well-structured APIs. In addition to making development go more smoothly, this method will also make the product easier to expand as more features are added. In general, this resource helped me learn more about how software building principles affect more than just backend logic and have a big effect on the quality of front-end systems as well. It also told me that software architecture and user experience are linked—a well-designed system helps a well-designed interface work.

From the blog Site Title by Roland Nimako and used with permission of the author. All other rights reserved by the author.

CS343: What is OpenAPI?

This week I read a blog post from Postman titled “OpenAPI vs. Swagger”. You can find that here.

What is OpenAPI?

OpenAPI 3 is an API specification within YAML which outlines a RESTful API, similar to Swagger. We’ve used both Swagger and OA3 in class, and we’ve seen that they are so similar that files made using either can be displayed using the Swagger Viewer. One further note: OA3 is considered a “newer” version of Swagger 2. Being newer, it is substantially different from its predecessor.

What are the key similarities between OpenAPI 3.0 and Swagger 2?

  • Both can display JSON and YAML data.
  • Both utilize the JSON schema (though different kinds of the schema)
  • Info block in both specifications display the same information about the API.
  • Both organize their paths and HTTP methods the same way.
    • OpenAPI 3.0 additionally supports describing all data with the JSON Schema

What are the key differences between OpenAPI 3.0 and Swagger 2?

  • Reusable components
    • Swagger 2.0: reusable components must be defined under specific fields: ‘definitions’, ‘parameters’, ‘responses’, ‘securityDefinitions’
    • OpenAPI 3.0: reusable components are now in the ‘components’ block to avoid ambiguity with actual security elements
      • Also new types of reusable components, such as ‘examples’ and ‘headers’.
  • Data models per media types
    • Swagger only allows one schema for the request and response bodies. However, in OpenAPI 3.0, you can define one schema for each (as we saw in class while working on the pantry).
  • Callbacks and webhooks
    • OpenAPI 3.0 supports asynchronous communication, such as the ‘awaits’ keyword, so the API does not have to provide data tied to such a keyword itself.
  • Improved security
    • OpenAPI 3.0 adds a new universal ‘security’ field and ‘securitySchemes’ to define security procedures and security modes.
    • OpenAPI 3.0. removed Basic Auth and fixed OAuth2.0 support missing from Swagger 2.0.
  • More summaries
    • OpenAPI 3.0 adds a new ‘summary’ and ‘description’ field to describe paths.* level, whereas Swagger 2.0. only had a short ‘description’ field at the info level.
      • The summary allows for a short description of the API, whereas the description field allows more detailed explanations of individual elements of the API.

Why did I choose this blog?

During this semester, I was given an introduction into many of the tools that front-end/back-end developers will be using when working on product, such as JSON, REST, OpenAPI, and YAML. As we approach the capstone next semester, I figure we’ll be using these frameworks even more, so it would be to my benefit to get more acclimated to them now.

That’s all for this week.

Kevin N.

From the blog CS@Worcester – Kevin D. Nguyen by Kevin Nguyen and used with permission of the author. All other rights reserved by the author.

Cohesion and Coupling

In this blog post, we will highlights some important details between Cohesion and Coupling. The definition of the two concepts can be difficult to understand at first, but then it is helpful to imagine a picture of how elements are interconnected, leading to further understanding as Cohesion and Coupling are correlate to each other.

In the blog summary, first of all is how they clarify the complicated definition of these two concepts. Cohesion is about how elements belong together, but it does not depend on the number of connections between elements, which is what coupling is all about. The blog post also shows the pictures that helps us imagine of how loose and tight the elements are, which can be ideal when figuring out the correct way to organize module. In other words, it should leads to high cohesion and low coupling. And finally is how to sum up to the point that why high cohesion does not only make the system easy to understand and change, it also reduces the level of coupling.

I personally choose this post because it is helpful to understand how to apply these two concepts carefully. In object-oriented programming, for example when making a class in Java, we should know when we declare too many properties that could make the class ultimately “do everything”. For example, declaring a bookstore class that do the following properties: add, remove, sale, and receipt. As we create multiple properties like this, we notice that there are properties shouldn’t be necessary, such as sale and receipt, and instead should break down into each individual class. That’s what affect the cohesion, where breaking each properties into each individual class will promote higher cohesion and lower coupling. Therefore, we call each classes a cohesive class.

This concept of Cohesion and Coupling also makes me imagine of how to organize properties in one class that looks easier to maintain. In my experience, not always when declaring a class is a cohesive class, as I can’t determine if some related properties in that class should breaks down into new classes. Therefore, it’s difficult to maintain for larger projects, making it look complicated at a glance. What I learned about these concepts is helpful to me so I can visualize how I should organize classes and properties, by applying the definition of cohesion and coupling, as high and low for each can affects future maintenance and for the overall functionalities of the project.

Source: https://blog.ttulka.com/how-cohesion-and-coupling-correlate/

From the blog CS@Worcester – Hello from Kiet by Kiet Vuong and used with permission of the author. All other rights reserved by the author.

CS343: YAML vs JSON

This week I read a blog post from Postman titled “What is YAML?” You can find that here.

What is YAML?

YAML stands for “Yet Another Markup Language.” YAML is actually a superset of JSON, which I didn’t know and didn’t intuit from the name; the blog goes into depth about the differences between JSON and YAML, in addition to other things.

What are some of the key ways in which YAML differs from JSON?

  • Syntax
    • YAML: indentation (or spaces) infer nesting; colons for KVPs and dashes for listing items
    • JSON: syntax is explicit, f.e. curly braces to define objects and square brackets to define arrays
  • Readability
    • YAML is considered more readable due to its less-astringent syntax rules, while JSON is considered less readable due to its highly structured syntax.
  • Data types
    • YAML supports more data types (such as dates and binary data) than JSON, which supports only primitives and some other data types.
  • Usage
    • YAML is the language of choice for config files and other areas where readability is key.
    • JSON is natively supported by many programming languages, meaning that it fits well into microservices and for data interchange between APIs and web services.

What is YAML used for?

  • Writing config files
  • Data interchange for API/web services
  • Storing metadata
  • Data serialization (and even converting from JSON or to/from YAML)

What is essential to know when working in YAML?

  • YAML has no hard requirements for syntax, but developing an internal style guide to ensure that files written across the organization are equally readable is an ideal best practice.
  • YAML files, especially large ones, can be broken up into individual modules in order to improve maintainability/readability.
  • YAML may present a potential security risk when configuration or other files are autogenerated and expose system/data information that otherwise should not be shown. Be careful about what data is stored in such files.

Why did I choose this blog?

During this semester, I was given an introduction into many of the tools that front-end/back-end developers will be using when working on product, such as JSON, REST, OpenAPI, and YAML. As we approach the capstone next semester, I figure we’ll be using these frameworks even more, so it would be to my benefit to get more acclimated to them now.

That’s all for this week.

Kevin N.

From the blog CS@Worcester – Kevin D. Nguyen by Kevin Nguyen and used with permission of the author. All other rights reserved by the author.

CS343-01: Fourth Quarter

Interface, Not Implementation Programming

According to what I recently learned, programming to an interface and not an implementation is one of modern software development’s “most powerful design principles.” And this is a key to building some flexible, maintainable, and professional software systems. In this blog, I’ll go over the key characteristics of this idea.

To understand this idea, the source says that programming to an interface and not an implementation is about separating what the program does and how it accomplishes the tasks it’s performing, or will be performing. The primary characteristics include abstraction over specificity, decoupling components, enhanced flexibility and extensibility, ease of maintenance and testing, and finally, polymorphism and reusability.

Abstraction over specificity means that when programming to abstractions (like interfaces), the behaviors should be without detailing the exact implementations taking place. “This approach allows for multiple implementations that fulfill the same purpose but differ in internal workings.” 

For a note: coupling in software design is where it measures the interdependence between modules or components which indicates how much they rely on each other. Low coupling is desirable. The second characteristic is Decoupling components. This means that those components become less dependent on specific implementations that cause loose coupling. “When components are decoupled, they can be easily replaced or modified without impacting other parts of the system.”

Enhanced flexibility and extensibility is where the developers introduce the new functionalities significantly changing the code and they can also swap out different implementations that “adhere to the same interface.”

Ease of maintenance and testing is the fourth principle or characteristic of “Programming to an interface, not an implementation.” This is where the testing can become simpler since the interfaces now allow for creations of mock or stub implementations. “This isolation helps developers verify each component’s behavior independently, supporting faster maintenance cycles.”

And finally, the last characteristic is Polymorphism and reusability. This is where the objects are more interchangeable, which in turn, enhances the polymorphism when focusing on interfaces. It leads to reusable code which helps a lot when the same interface can also support different implementations for various scenarios it could encounter.

This is important to know since these principles are applied to different programming paradigms. Programming paradigms are fundamental styles or approaches that are used for structuring and writing computer programs. They’re like blueprints when building a building except with problem-solving. And “programming to an interface and not an implementation” is often associated with Object-Oriented Programming, OOP, one of the different types of programming paradigms. Some of the other paradigms that this principle can be applied to are functional programming or FP and procedural programming.

Source: https://medium.com/@Masoncoding/programming-to-an-interface-not-an-implementation-024d01815070 

, ,

From the blog CS@Worcester – The Progress of Allana R by Allana Richardson and used with permission of the author. All other rights reserved by the author.

Learning Front End in a Microservices World

This week we learned a lot about front-end development. Working through the microservices front-end activities (MS07–MS09) really helped me understand what the front end is all about. As a CS student who loves full-stack development, the activities offered a structured approach to seeing how a front end fits into a bigger system rather than just … Read more

From the blog CS@Worcester – BforBuild by Johnson K and used with permission of the author. All other rights reserved by the author.

7 Essential Design Patterns

Design patterns are important for developers to use in their code. They make your programs easy to read and implement and they are able to be adapted to many situations. There are 3 kinds of design patterns: creational, structural, and behavioral. 

Creational patterns are used for creating objects. They give flexibility to change the creation process and allow for many types of objects to be created using the same method. The singleton pattern is used when there should only be one instance of an object. Instead of creating a new object every time you need to call it, you call a method that will call an instance of the object. The builder pattern is used when an object has a lot of optional parameters that make it difficult to know what is being applied when it is created. Using a builder pattern creates an empty or default object and then calls set methods to add each parameter you want to use. The factory pattern is for when there are a lot of objects of a certain type, but with different forms. Instead of creating many new objects, you call a factory to create the objects with the specifications hidden in the factory code. 

Structural patterns are used for how objects relate to each other. These patterns allow for high level code to be readable and simple, while keeping the intricacies hidden below the surface. The facade pattern is used when there are many operations and calculations behind the scenes of a process and those are all hidden with encapsulation. On a high level, one method will, for example, purchase a product, but deeper, there is a payment being processed, shipping calculations, inventory checks, etc. The adapter pattern is for when a program needs to be adapted to fit your code. It can be used for implementing public libraries where their units do not match what your program expects, and each time you use the public library, it calls the adapter to modify the output. 

Behavioral patterns are used for how objects interact with each other. The strategy pattern is used when you have multiple ways of doing a process. Instead of using a lot of if else statements, you can define several strategies and set each object to have a strategy. The observer pattern is used for objects that watch for something. It works by “subscribing” to receive a notification of an event. If a program is watching for errors, it would be automatically notified of any errors so it can add it to a log. 

In class, we went over the strategy, factory, and singleton patterns for the Duck example. These 7 patterns are common practice in the software development field and it’s important to know how to implement them. I watched a video explaining these patterns and now I have a deeper understanding of the three we learned and the four that were new to me. I feel confident I can expand on these in a professional setting.

From the blog ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.

API Security Practices

As we continue to study API implementation in my CS343 class, I find it important to continue to learn more about the subject. I came across this article that discusses 11 security practices for API implementation. A statistic I found interesting that is brought up at the beginning of the article is that APIs now account for more than 80% of internet traffic. The first practice listed is continuous API discovery. This means automating processes that catalog APIs across your infrastructure in real time. Doing this helps prevent the deployment of shadow APIs. The next practice is encrypting traffic in every direction. This one seems fairly obvious, but it is something that cannot be forgotten. The article also lists some key encryption requirements. Authentication and authorization are very important practices for API implementation as well. This allows for control over the usage of the APIs in the system, and it protects the user by keeping their primary credentials hidden to prevent theft and misuse. Using the Principle of Least Privilege is another good practice. Granting users the least amount of privilege necessary to use the system prevents damage from a malicious user. Documentation is also very important to help other developers maintain the system in a safe way. You must also validate your data to help protect against injection attacks. Make sure to limit data exposure as well. Data breaches are an issue that no one wants to deal with. The article lists a few more practices that are important for security in systems that use APIs.

This particular article stuck out to me because, as I said in the beginning, we are learning about API implementation in my CS343 class. Knowing the typical security practices for implementing APIs is imperative for creating a good system. It’s something that many may overlook, but cannot be omitted. I myself had failed to consider the potential security risks of implementing APIs. This article gave good insights on the security risks and how to prevent them. This was definitely worth the time it took to read and understand. It is always important that the data going through your system is protected to ensure that the users have a problem free experience. The problems that could possibly arise from a lack of security could result in huge losses for a company deploying these systems. As someone who has not had to deal with that kind of risk yet, I believe it is important I learn about these potential issues before it becomes too late.

https://www.wiz.io/academy/api-security-best-practices

From the blog CS@Worcester – Auger CS by Joseph Auger and used with permission of the author. All other rights reserved by the author.

REST API Design

For this blog, I chose the blog “REST API Design Best Practices Guide” from PostPilot. I chose this resource because our course directly works with REST API, focused on backend development, and how different software components communicate through REST API. Since REST APIs are one of the most common ways to build websites, I felt it was important to reinforce what I learned in class about how to work with REST API.

The blog explains the core principles behind REST, including having a stateless server, a client server relationship, caching, and interfaces. It then goes into the basics for building APIs that are easy to understand. One of the first practices it suggests introduces designing resource based URLs using nouns instead of verbs and making them simple and plural such as users or orders. It also emphasizes the importance of properly using HTTP methods, like GET for retrieving information, POST for creating data, PUT or PATCH for updates, and DELETE for removal. The guide goes deeper by discussing when to use path parameters versus query parameters, especially for filtering data and explains why good responses help developers with context and confusion.

Something I found especially insightful was the explanation on versioning and error handling. The blog explains why APIs should include versioning so that future updates don’t break existing clients. It also explains why providing consistent and descriptive error responses are important so that developers can debug what went wrong rather than guessing. It also talks about security requirements such as using HTTPS and authentication tokens, as well as using tools like Swagger to make the API easier for other developers to use.

This blog improved my understanding after reading it, I’ve noticed that good planning and design are crucial, especially when multiple people use the same system. I noticed that the HTTP method already conveys the idea, so keeping endpoints focused on resources makes everything cleaner.

Hopefully, I can apply what I learned in future API work, particularly when working with backend development. This blog’s information will definitely be helpful when designing good and useful APIs rather than messy and unreadable designs. This blog has made me more aware and informed of how important API design is, not just for functionality but for maintainability and ease of use. Reading this guide along with that I’ve picked up in class gives me a strong foundation to understanding REST APIs, if not at least be a little more informed on the topic..

https://www.postpilot.dev/blog/rest-api-design-best-practice-cheat-sheet

From the blog CS@Worcester – Coding with Tai by Tai Nguyen and used with permission of the author. All other rights reserved by the author.

Quarter-4 Blog Post

For my last quarter blog post, I decided to explore the topic of documentation. Even though we didn’t talk about it directly in class, we were actually working with it during many of our activities, like working with REST, learning how the frontend and backend communicate, and practicing the commands needed to run both sides of a project. Most times the owners of a product aren’t technical, and because of that, engineers end up having to create their own documentation so everyone can understand how things work. All of our in class activities became much easier when we had clear and easy-to-follow documentation in front of us. The blog I chose for this post, written by Mark Dappollone, goes deeper into the topic by giving tips that help both the person building the product and anyone trying to understand how the software works.

Mark’s blog explains three main ideas about documentation that people should understand. The first is that the only way to create good documentation is to just get started and write something. He points out that when there is no documentation, people are forced to rely only on the code and if the code is wrong or changes, no one would know because there’s nothing written down to compare it to. So even if your documentation isn’t perfect, it’s still better than nothing. Without it, clarity disappears and developers end up guessing what’s going on.

The second idea is the importance of using visual aids. One of my favorite examples in the post was when he included a screenshot and labeled each field with the API calls and the data fields they come from. This instantly shows how everything connects to backend data through REST, which is exactly what we practiced in class. With visuals like that, developers can read and understand the logic behind GET or POST requests without having to guess.

The third and final idea is keeping documentation updated. In class, we noticed that even small changes to the code, like changing where data/input is coming from for, can make things confusing very quickly. Without good documentation, things get messy for anyone working on the product. Keeping documentation in sync with changes to both the backend and frontend helps avoid those misunderstandings.

In the future, I can definitely see myself working with API calls or making frontend fixes, and using documentation will help me understand the whole picture. It also ensures that anyone reading the documentation can see how everything ties together. I would especially like to use visual aids because I’m a visual learner, and I think many people are too. Using visuals can help clear up confusion and make the whole development process smoother.

Source: https://mdapp.medium.com/how-to-document-front-end-software-products-e1f5785279bb

From the blog Mike's Byte-sized by mclark141cbd9e67b5 and used with permission of the author. All other rights reserved by the author.