Category Archives: CS-343

Backend Architecture

Back-end architecture serves as the backbone of modern web applications, enabling ideal and flawless user interactions and efficient data management. The Codecademy article “Back-End Architecture” provides an insightful overview of the fundamental components and design principles that make up the back end of web systems. It summarizes the key takeaways from the article, reflects on its relevance to software development practices, and outlines its implications for aspiring software engineers.

The article begins by explaining the primary purpose of back-end architecture to manage the behind-the-scenes functionality of web applications that the user can’t see. It underlines the importance of servers, databases, and APIs in creating a solid infrastructure. This is what the article key topics covered:

  • Servers: These handle requests from the front end and deliver the necessary responses. The article discusses server setups like dedicated, shared, and cloud servers.
  • Databases: Central to storing and retrieving data, the article explores relational databases (SQL) and non-relational databases (NoSQL), emphasizing their use cases and advantages.
  • APIs: Acting as the glue between the front end and back end, APIs enable seamless communication between various components of an application.
  • Scalability and Security: The article addresses the importance of designing scalable systems and implementing robust security measures to safeguard user data and maintain application performance.

One reason I chose this article is that we are currently learning about REST APIs in class. I wanted to deepen my understanding of how APIs are used in developing web applications and their role in back-end systems. As a Computer Science student, I aspire to build more complex projects in the future where I can apply this knowledge. The article’s clarity and engaging presentation made it both interesting and easy to understand, which further motivated me to select it as a resource.

Reading this article deepened my understanding of how back-end systems operate and how they connect with front-end components. One key takeaway was the example it provided about how a client makes a request to the server. The article gave a detailed yet digestible explanation of this process, which was different from the visual and interactive activities we did in class. For instance, the explanation of what happens during a client’s GET request clarified the flow of communication between the client and the server, making the concept more relatable and easier to grasp.

What I learned from this article will help me approach back-end development with confidence. For my upcoming project, I plan to focus on designing a system that effectively integrates APIs and databases. Ensuring scalability and security will be a priority to make the application robust and user-friendly. These insights will serve as a foundation for building more complex projects in the future.

Source:
https://www.codecademy.com/article/back-end-architecture

Citation:
Codecademy. (n.d.). Back-end web architecture. https://www.codecademy.com/article/back-end-architecture 

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.

Enhancing Development with Software Design Patterns

“Design patterns represent common software design problems and well-tested solutions to those problems.” This is a line from my class’s first exercise introducing us to design patterns. In it we learned that in order to have scalable code, certain types of solutions, design patterns, are used. They are the culmination of previous developers’ struggle adding functionality to already existing code.

When we learned about design patterns in class and the homework, we handled singleton, strategy, simple factory design patterns. This GeeksforGeeks article adds onto the classwork by first separating their list into Creational, Structural, and Behavioral types. Creational patterns address when objects are made by separating how the object is formed from how it is implemented. Included in this type are the Factory and Singleton patterns we had already seen as well as new patterns called the Prototype, Builder, and Abstract Factory patterns. Under the Structural category are methods that handle class/object composition, so they utilize inheritance and help to structure efficient interfaces or implementations. Here they included the Adapter, Bridge, Composite, Decorator, Facade, Proxy, and Flyweight patterns all brand new to me. Finally came the Behavioral patterns that at first brush sounded like it was primarily focused on solely on the responsibility of objects and classes but actual include how these objects and classes communicate with each other. In this section returned the strategy design pattern along with Observer, State, Command, Chain of Responsibility, Template, Interpreter, Visitor, Mediator, and Memento patterns. At the end of this article is an FAQ section where they explain things such as how you can compare algorithmic solutions to design patterns in terms of computational solutions and structural solutions.

I chose this article because it showed me an entire new category of design patterns that tackle interface creation, something that I personally find to be a weak point in my understanding of OOP design. I actually clicked into the Bridge design pattern because it allows for abstraction and implementation to be developed separately. So when you have multiple subclasses of subclasses, their example used ProduceBus and AssemblyBus under the Bus class under the Vehicle class, you have an issue any time you wish to modify the middle level (Bus) class. The Bridge pattern says to separate the Produce and Assembly bus implementations into their own subclass of an interpreter called Workshop that works on objects of the Vehicle class. This way changing the Bus class doesn’t directly change how the Produce and Assembly portions work, which thus saves time.

I have thus bookmarked this page so that until I can pull these patterns from memory I can make use of these numerous proven solutions. It is an amazing resource since it has links to more in depth explanations of each design pattern so that readers can truly grasp just how these tricks work in practice.

Link:
https://www.geeksforgeeks.org/software-design-patterns/

From the blog CS@Worcester – Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.

Code Smells

In software development, creating high-quality apps requires keeping code neat and effective. The blog “What is Code Smell & How to Avoid It” provides a thorough review of code smells, which are signs of more serious problems in a codebase that may hinder readability, performance, and maintainability despite the fact they are not errors. The blog carefully explains the definition of code smells, their most prevalent kinds, and practical solutions. It is a great resource for learning how to maintain high-quality code because of its structured approach.

Code smells are indicators of design flaws in a program, which might result in technical debt and vulnerabilities down the road. Tight timelines, inadequate evaluations, or insufficient experience are frequently the causes of them. Typical examples include excessive parameter lists, overly long functions, incorrect naming standards, and duplicate code, all of which make the codebase challenging to maintain. Along with highlighting smells like middle-man classes, data clumps, and primitive obsession, the site provides practical guidance on how to spot and address each. In order to prevent code smells, the blog highlights techniques such as using automated code review tools, implementing continuous integration/deployment (CI/CD) workflows, and regularly refactoring.

I chose this blog because it breaks down the concept of code smells into digestible pieces, discussing each type in depth while linking them to actual solutions. Additionally, the topic strongly reflects our course, Software Construction, Design, and Architecture, which stresses developing maintainable, scalable systems. This objective is directly supported by knowing code smells, which also serve to reinforce the fundamental ideas covered in the syllabus.

As I thought back on the blog and what we’ve learned in class, I realized how crucial it is to proactively find and fix code smells throughout the development process. The emphasis on techniques like refactoring caught my attention since it can be easy to overlook their wider importance beyond tackling immediate issues. Recognizing certain scents like “feature envy” and “primitive obsession,” brought to light how small problems may turn into big ones, affecting collaboration and a project’s ability to grow. For instance, I intend to use the strategy of condensing lengthy parameter lists into objects by grouping related data together. This will make the code in my upcoming projects cleaner, easier to maintain, and easier to read.

This blog improved my knowledge of software architecture and design by relating theory to real-world development issues and helped cement the content we went over in class. By putting the knowledge I’ve received to use, I hope to create software that is more reliable and maintainable, laying a solid basis for my future work in software engineering.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

API Documentation

This week, I decided to discuss Application programming interface (API) documentation. API documentation is essential for developers to understand how to use the API, integrate it into their applications, and fix any issues that arise. The article “How to Write API Documentation: Best Practices and Examples” highlights the importance of API documentation and discusses practical insights into creating a better developer experience.

The article starts with an informative video discussing the API economy, what API documentation is, and how to write it. It also shows some examples. The article moves on to the common issues developers have with APIs, like being too long, too much technical jargon, un-updated, or inaccessible without registration. The author discusses several ways to remedy these issues by emphasizing that good API documentation needs to be user-friendly, clearly explained, and given examples with FAQs or tutorials. One of the strategies presented to accomplish this is called spec-driven development(SDD), where you generate the documentation while developing the API. We are also given several tools to help create and maintain API documentation, like Swagger and Postman.

I chose this article because APIs are discussed and used thoroughly in our course. The appropriate next step was understanding how developers make software accessible to users and, in doing so, become more accustomed to APIs.

Reading this article gave me several strategies to think over and included great explanations for why they are used. I was unaware of strategies like SDD and writing for entry-level users, but they made a lot of sense after reading the article. Creating the documentation after developing API can lead to errors and inconsistent documentation, frustrating developers. Having the documentation evolve with the creation of the API makes more sense. The explanation for writing with entry-level users in mind was great, too. You might think that all software developers understand API documentation, but each developer has their own experiences, specialty, and knowledge. Tailoring the documentation to everyone is impossible, so aiming for clarity at the entry-level will make it understandable for most developers. It is one thing to hear how to improve your documentation, but seeing data on the main features developers want and issues they get frustrated with makes me feel like the strategies will have a greater impact on the users.

In future projects, I plan to use spec-driven development to ensure my API documentation grows with my project, allowing developers to follow along without confusion. I will also aim my documentation at entry-level users so the resource is accessible to most developers.

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

Discovering Design patterns

Hello Debug Ducker here again and have you ever thought about how your code is structured? I mean you probably have been doing simple code etiquette, but have you ever thought about how you could make it less say more manageable and neater to save yourself the trouble

Here is an example of a code design on UML from a programming assignment

The basic gist of this is that we are making ducks and applying qualities to them. As you can see there are different types of duck especially my favorite the rubber duck. But I am sure you can see a problem with this. Despite them being all ducks, not all the attributes of a duck can apply to certain ones as shown with decoy duck and rubber duck. Their quack and fly methods would be different, So we have to override them to do something else. This can get tedious especially if we were to add more ducks. Also makes the abstract class feel pointless because of this. So this is where Design Patterns are implemented

Instead of overriding the fly and quack methods in the different types of ducks, we add functions that can apply the behaviors themselves without needing to modify methods within ducks. The Relevant design pattern here is known as Strategy Pattern, and that’s when we get into the real meat of things. 

Design Patterns as the name suggests are designs that programmers can utilize to fix certain problems in their code, whether it’s readability, managing the code, or streamlining a process. Strategy Pattern is the design pattern that splits the specifics of a class into other methods, such as the example of the fly and quack behaviors which were originally a part of several other ducks with different qualities. This helps us whenever we want to add a duck with a different behavior, one of the behavior methods could be applied. There are several other design patterns out there such as factory design which creates objects through what called a factory method, for example, if the rubber duck method is made then an object with rubber duck qualities will be made

Here is code of an example of what a factory method would look like

There are a lot more patterns to choose from that can help you with all your coding problems. Geeksforgeeks has a great article explaining them and even more of the patterns to show

https://www.geeksforgeeks.org/software-design-patterns/

Design patterns can be useful for many coding problems, whether It’s to restructure your code to make working on it easier or refactor it to make the functionality better. I can see myself using theses whenever I would encounter a problem.

“Software Design Patterns Tutorial.” GeeksforGeeks, GeeksforGeeks, 15 Oct. 2024, http://www.geeksforgeeks.org/software-design-patterns/.

Guru, Refactoring. “Strategy.” Refactoring.Guru, refactoring.guru/design-patterns/strategy.

From the blog CS@Worcester – Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.

Semantic Versioning

One of the earlier topics we went over in this course was Semantic Versioning and how many companies or groups will use it to keep track of their development. Sometimes shortened to “SemVer,” Semantic Versioning describes a versioning structure that will better communicate “implications of new versions, such as breaking changes, new features, or bug fixes” (Victor Pierre). It allows developers to have some comfort in knowing what changes will be made or have been made and whether there is some level of risk in moving to a new version. This risk lies mostly in software that have some sort of dependency, such as libraries or frameworks as updates to those can lead to dependent softwares having to update some part or most of their work, and the software not working otherwise. 

Semantic Versioning employs a three-part version number in the format, MAJOR.MINOR.PATCH, with each part signifying a different impact of the release.

  • MAJOR: Incremented when making incompatible changes or introducing breaking API changes.
  • MINOR: Incremented when adding new features or functionality in a backward-compatible manner.
  • PATCH: Incremented for backward-compatible bug fixes or patches.

This is the basic structure for Semantic Versioning but there are many more rules to follow and other cases that will slightly change how the format will look (Victor Pierre). More details can be found on the official Semantic Versioning site (https://semver.org). 

When this topic was first introduced, I recognized it and was quite excited because it’s something I’ve seen quite often in the games I play or in other things related to games. The very first thing that came to mind was modding, especially in Bethesda Games. The Elder Scrolls Series and the Fallout Series are some of the most modded games ever, one of the reasons for this is the fact that Bethesda, some time after the release of a game, will implement modding support and tools. I connected Semantic Versioning to how Bethesda will rarely release a major update to Skyrim or Fallout 4, two of the most modded games ever despite how old they are now. These rare updates will cause the modding community to blow up as nearly every modder will have to update their mods in order to be compatible with the new version. After 10 or so years of these rare but destructive updates, many modders have simply stopped updating their mods, moving on to better things or just not caring enough to do so. It’s come to the point in which people have come together to make “downgraders” to play on an older version of the game to have access to a wider variety of working mods. 

That was a bit of a long story but overall, I think Semantic Versioning is simple but intriguing and most of all, extremely useful. I look forward to seeing changes, patches, updates for games and other software that I use and having access to an easy-to-follow log of just further cements my liking for Semantic Versioning. I’m not so familiar with other ways to keep track of development but this seems like a staple for developers and companies, and one that won’t be replaced so easily.

https://victorpierre.dev/blog/beginners-guide-semantic-versioning/

From the blog CS@Worcester – Kyler's Blog by kylerlai and used with permission of the author. All other rights reserved by the author.

DevOps vs. Software Engineering

As I wrap up my last blog for the semester, I find myself still contemplating the career path I’ll take after completing my computer science degree. With so many options available in tech, one question that often occupies my thoughts is whether to pursue a role in DevOps or traditional software engineering.

Both fields are integral to the software development lifecycle, yet they have distinct focuses. Software engineering is primarily about designing, building, and maintaining software systems, while DevOps combines development and operations, emphasizing automation, collaboration, and the seamless delivery of software.

To better understand these roles, I explored the article Developer vs. DevOps engineer similarities and differences from TechTarget. This resource provides a clear breakdown of the responsibilities, skills, and career trajectories associated with both paths.

 Why I Chose This Resource

I selected this article because it connects concepts from CS 343; Software Design Principles . It also highlights the distinct mindsets and tools used in these roles, making it easier to relate the information to my interests and career goals.

What I Learned

1. Core Responsibilities: Software engineers focus on writing, testing, and debugging code, while DevOps engineers prioritize streamlining the software delivery process through automation and operational stability.

2. Skill Overlap: Both roles require proficiency in programming languages and version control systems, but DevOps engineers also need expertise in infrastructure-as-code (IaC) tools like Ansible and Terraform.

3. Collaboration: DevOps engineers work closely with both development and operations teams, emphasizing teamwork, whereas software engineers may work more independently or in smaller coding teams.

One point that resonated with me was how DevOps integrates continuous feedback loops into the development process, improving software quality and delivery speed.

Personal Reflection

Reading this article clarified the complementary nature of these fields. I’ve always enjoyed problem-solving and creating efficient solutions, which aligns with the goals of both software engineering and DevOps. However, DevOps’s focus on automation and system-level thinking piqued my curiosity, especially since I’ve been exploring tools like GitHub Actions in my personal projects.

This resource also reinforced the idea that adaptability is crucial in tech. Whether I choose software engineering or DevOps, learning skills from both domains will make me a more versatile professional. For example, I plan to experiment with IaC tools and practice creating CI/CD pipelines in my future projects.

Final Thoughts

Choosing between DevOps and software engineering is not just about job titles it’s about aligning your strengths and interests with industry needs. This exploration has helped me better understand what excites me about each field, and I feel more confident about preparing for either path.

For anyone considering a similar career decision, I highly recommend the TechTarget article. It’s a great resource for breaking down complex topics and understanding how different roles fit into the broader tech ecosystem.

Resouces:

https://www.gsdcouncil.org/blogs/devops-engineer-vs-software-engineer

https://www.techtarget.com/searchsoftwarequality/tip/Developer-vs-DevOps-engineer-similarities-and-differences

From the blog CS@Worcester – function & form by Nathan Bui and used with permission of the author. All other rights reserved by the author.

How the Frontend and Backend Connect in an API: A CS Student’s Guide

Since we’re diving deeper into web development, understanding how the frontend and backend work together is a must. It might sound like a techy tug-of-war, but it’s actually a smooth partnership—thanks to APIs (Application Programming Interfaces). Here’s how the magic happens, dumbing down.

The Frontend: The Face of Your App

The frontend is what users see and interact with. It’s all about the visuals and user experience. Imagine buttons, forms, and animations—that’s the frontend at work. Developers usually use HTML, CSS, and JavaScript frameworks like React or Angular to build this.

But here’s the kicker: the frontend is mostly clueless. It can show pretty pages, but it needs help to fetch or save data. That’s where the backend steps in.

The Backend: The Brain of Your App

The backend is like the brain. It’s where the logic, data processing, and database interaction happen. Built with tools like Node.js, Python, or Java, the backend handles all the “boring” stuff the user doesn’t see, like authenticating a login or storing a comment.

The frontend and backend don’t just shout at each other directly—they use an API to chat.

The API: Their Translator

The API is the middleman that helps the frontend and backend understand each other. Think of it as a menu at a restaurant(you would know if you read my previous entries). The frontend (the customer) picks something from the menu and places an order. The backend (the kitchen) cooks it up and sends it back. The API defines the rules of this exchange, so everyone’s on the same page.

Here’s how this plays out in real life:

  1. Frontend Sends a Request: The user clicks a button to log in. The frontend sends an HTTP request (usually via POST) with the user’s credentials to the backend API at something like /api/login.
  2. Backend Does Its Thing: The backend gets the request, checks if the credentials are valid, and prepares a response—like a token if the login is successful.
  3. Backend Responds: The backend sends the token (or an error message) back to the frontend in JSON format.
  4. Frontend Updates the UI: If the login worked, the frontend can now display the user’s dashboard. If not, it’ll show an error message like, “Try again, champ.”

Why This Connection Matters

APIs keep the frontend and backend loosely connected, so they can evolve separately. For example, you can upgrade your UI (frontend) without messing with your database logic (backend). Plus, APIs make your app’s backend reusable, other apps can connect to it too.

TL;DR

The frontend is the face, the backend is the brain, and the API is their translator. Together, they create the seamless apps we use daily. So next time you log in, search, or post, know that there’s a whole tech orchestra working behind the scenes. And now, you kind of know how it plays its tune!

References
https://www.geeksforgeeks.org/frontend-vs-backend/
https://medium.com/@adityagaba1322/streamlining-backend-frontend-integration-a-quick-guide-145eca3cca05

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

Frontend or Backend Development?

When I started studying computer science, I was unsure of what I wanted to do. As I learned, software development felt right for me, but that also asks another question, front end or back end? Initially, the front end seemed right for me, not for any particular reason other than working on the website felt better. However, after learning about both the back end and the front end, I am unsure now. 

In this blog post, Lane Wagner talks about their experience with front end development. They say that growing up, they wanted to be good at drawing, so that carried over into their computer science career. When they were working with front end things, they noticed that they focused their time on tweaking CSS, code for formatting the website, and it would always look bad anyways. They then decided that they wanted to become a back end developer instead, and talked about some other factors that affected their decision. These factors ranged from a number of things, such as pay and language preference, but the one that stuck out to me the most was feedback. They say that as a back end developer, you build code that is used by everyone, code like REST APIs, CLIs, and databases. This allows you to get feedback back from them in a way that is more constructive than if it was front end code, like UI. This lets you learn and improve.

After reading Wagner’s post, and reflecting on what I learned in class, I would also probably swing towards back end development too. The reason why I thought front end development would be better for me was because I am more artistic in a way. I also have a communication minor, so it would be a good way to combine the two. However, after learning both back end and front end, back end seems better to work with. The front end felt very convoluted to me, while the back end felt more seamless and streamlined. Maybe that was due to the fact that we spent more time learning the back end and playing around with it than the front end. Regardless, I would still love to learn more about both. I am still young, so learning both and maybe even working with both would help me choose which would be a better fit for me. But for now, back end development may be the better fit.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

A Simple API

RESTful APIs are a common and standard structure used to develop software applications. Lately in class we have been delving into how these APIs work using Thea’s Pantry as an example. I found this blog that gives a concise and easy to understand explanation of REST works. He gives a brief overview of what REST stands for and then explains its purpose. It used to make data transfer between client and server easier and more encapsulated. One of the points that was interesting to me and made a connection to what we learned in class about coding principles. The principle of encapsulation and keeping things as independent as possible. Trying to keep the server and client as independent as possible to make scalability and maintenance more efficient. The REST API serves as an interface between client servers that serves to communicate for them so they don’t have to.

It then goes into more detail about resources and URLs and return formats. It was also interesting to me that return formats could be more than JSON, the example they used was XML. You just have to specify, but I don’t know a reason why you wouldn’t use JSON. The Reason I chose this blog is because it is a simple explanation of what REST API is. For me personally, APIs can be kind of hard to understand, but this blog explains in a way that makes it easy to understand. The picture was a big help. Other than that I don’t really have anything to say. 

https://medium.com/@MakeComputerScienceGreatAgain/understanding-rest-api-a-comprehensive-guide-52fc10f6c9ed

View at Medium.com
View at Medium.com
View at Medium.com

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.