Category Archives: CS@Worcester

API and Modern Day Development

This article, “Understanding the Role of
APIs in Modern Backend Development” starts with what API is and how it is now
backbone of modern-day development. APi is a set of rules and protocols that
allow software components to interact and expose backend functionality or data
to other services, clients, or platforms. The article shows and explain different
types of APIs used in backend development, REST APIs, GraphQL APIs, WebSocket
APIs. Rest Apis are most used architecture, based on HTTP methods, makint it easy
to scale, maintain, and secure. GraphQL APIs are improved alternative of Rest
Api, which allows clients to request exactly the data they need in a single
query, reducing the number of requests sent to the backend. WebSocket APIs on
the other hand, enables bi-directional real-time communication between the
client and server making it useful in applications like chat, live updates or
gaming. After that the article explains best practices for using API in backend
development and they reasons why we need them; Use Clear and Consistent Naming
Conventions, Document Your API, Implement Security
This article ends with to popular backend frameworks for building API and why
they are used. Examples include Node.js (Express.js), Django (Python), Ruby on
Rails (Ruby) Spring Boot for Java,
Laravel for PHP, and FastAPI for Python.

I
recognize that one of the areas I’ve struggled with is using and designing APIs
effectively. Therefore, I chose this article, because it tackles that with
further knowledge that I currently have. I found out in the world there are
more to the Apis than just the Rest Apis and this article well explains other alternatives
to Rest Apis and what they do and its examples. Not only that, but the article also
explains important things to do while using Apis and popular framework that I can
later learn to improve my skills as full stack engineer.

From this article I learned not just new
apis and where to use them but also the framework section gave me context about
which tools I might adopt based on my need and language, and their benefits. It
also expands on what I need to do further implements the practice so I might not
be confused in the future while building apis and that they are they are
contracts between system. In the future, I will try to better document
everything while checking out the version control more carefully than before.
Not only that, but I might also try out different Apis to make Backends the other
APIs like GraphQL APIs, WebSocket APIs seems useful in parts for future
practices.

https://medium.com/@danieltaylor2120/understanding-the-role-of-apis-in-modern-backend-development-36059945db1d

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

API and Modern Day Development

https://medium.com/@danieltaylor2120/understanding-the-role-of-apis-in-modern-backend-development-36059945db1d

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

Version Control: Why It Matters in Software Development

Version control is something I’ve used before in classes, but I never fully understood its importance until I read the Atlassian article, “What is Version Control?” (https://www.atlassian.com/git/tutorials/what-is-version-control). I selected this resource because Atlassian explains technical concepts in a way that feels practical and industry-focused, which fits perfectly with what we are learning in CS-348. Since this course emphasizes collaboration, documentation, project organization, and professional tools, I wanted to learn more about how version control actually supports real-world software development.

The article defines version control as the practice of tracking and managing changes to code. What stood out to me is that version control isn’t just for “saving work”, it’s a full system that captures every change, who made it, when it was made, and why. Atlassian highlights how this creates a long-term project history that developers can search through, compare, or revert. This directly connects to our CS-348 topics like software maintenance, project management, documentation standards, and team collaboration, because version control supports all of these practices behind the scenes.

The resource also explains how version control allows teams to work on separate branches, make experimental changes, fix bugs, or build features without interfering with one another. This connected with my experience in this course because when we work on group projects or assignments, version control prevents us from overwriting each other’s work. The article also discusses merge conflicts, and reading about it made me feel better about the moments when I’ve run into conflicts myself. Instead of seeing them as mistakes, the article made me realize they are a normal part of teamwork and software development.

One major takeaway for me was the idea of traceability. Every commit tells a story, not just about the code, but about decisions, goals, and teamwork. This encouraged me to treat commit messages more seriously so that my future teammates (or even future me) can understand the purpose behind changes. The article made me realize that version control isn’t just a technical tool; it is a communication tool. This is something I didn’t appreciate before reading it.

This resource affected how I view my future practice because version control is required in almost every professional software environment. Reading about how teams rely on it to avoid lost work, manage parallel development, and maintain high-quality software helped me understand why CS-348 emphasizes collaboration tools, project organization, and documentation. Going forward, I plan to use branching more intentionally, commit more frequently, and write clearer commit messages. I also want to apply what I learned outside of class by using version control for my personal and club-related tech projects.

Overall, this article helped me connect the technical skills we practice in CS-348 to how real development teams work. It showed me that version control supports not just code, but communication, teamwork, and professionalism — all skills I want to continue developing.

Source

Atlassian. What is version control. Retrieved from https://www.atlassian.com/git/tutorials/what-is-version-control

From the blog CS@Worcester – Circuit Star | Tech & Business Insights by Queenstar Kyere Gyamfi and used with permission of the author. All other rights reserved by the author.

Trending code practices

Article: https://github.blog/news-insights/octoverse/what-986-million-code-pushes-say-about-the-developer-workflow-in-2025/?utm_source=octoverse-cli-announcement&utm_medium=octoverse&utm_campaign=universe25post

GitHub, in this blog post goes over the various trends and changes within pushes and changes made to very high profile repos. These conclusions were made from from 986 million pushes made within the platform which gives a very large sample size which in my opinion would extremely accurately present the current recent trends within the tech industry and open source software. One of the conclusions that GitHub brings up is that it is extremely fast to make changes and build software now than ever before and because of this many developers aren’t just pushing when things are totally done, rather they are leaving somethings within their pushes unready but functional to be iterated and done later rather than having everything within the push completely ready. They equate this trend to the saying “done-ness is temporary”, furthermore pull requests are more concise and simple, and feature flags are often used more and more even if they might be “maybe” feature since developers tend to just shut that feature off and push their changes again without it. The last major point that the author brings forward is that communication has to change to reflect the faster nature of development meaning more communication, faster stand-ups and hiring those who ship faster.

I chose this article due to the fact that the idea that the industry trend of how changes are made fundamentally shifting from large updates to shorter more small and experimental changes is extremely interesting since I’ve noticed this at my work where this is reflected. Often times changes are small and incremental and made to be built off of while maintaining functionality. Even more so my employers policy for pull requests has changed as well which is more simplistic and straight to the point rather than having such detail. But this isn’t without problem in my eyes as like the article states in order to gain missing information from the request communication is key and becomes even more important, especially in cases where there are present issues that require immediate action.

From this I plan to incorporate more things like being easier to reach for communication and communicating faster to better reflect the changes in trends of pushes, so that incase that I adopt the industry trends of smaller pushes to be iterated on with smaller and simpler pull requests, my workflows remain functional and optimized for the most quality while accounting for the changes in trends.

From the blog CS@Worcester – Aidan's Cybersection by Aidan Novia and used with permission of the author. All other rights reserved by the author.

Web System Development process

This blog post I’ll talk about some benefits that Web Development offers, comparing to the software that’s originally installed in a client machine. There are a vast amount of services and applications, such as social media applications or email services, mostly accessible through an application that has to be downloaded in a client device. However, this creates the following compatibility issue: What if you don’t own a compatible device that you need to download a specific software? For example, there are software such that it’s only available on PC. Again, “available on PC” means for PC users only, other client users like Mac or Linux won’t be usable.

For the summary, this blog post points out the convenience of web system development in terms of customization, easy integration, accessibility, and maintenance, as well as several major advantages on web system compared to having software installed on the computer. I select this particular resource to emphasize that you’re able to access resources directly on the website, rather than having it installed on your local machine. This eliminates the compatibility issues such as between Operating Sytems or CPU Architectures, such as applications that can only work on x86_64, amd64, but unable to work with arm64. Hence this shrinks the boundary of working on multiple devices.

One helpful thing the post also pointed out is ease of maintenance. In my experience, maintaining an application requires rebuilding software resources, bug fixing, recompiling, etc.. which takes a large amount of time and requiring end user to update the app. That is also to mention about old hardware, since constant updating on an application will slows the device down over time, and the app will requires more powerful hardware. However, there are also some amounts of people can’t afford for new hardware. Think of it as you own the best hardware and you wanted to use it for more than ten years, and only buy a new one when the old one is broken. Therefore, it would be best to consider building software on a web system, since once an upgrade is available, it may be applied through the host server rather than having to upgrade each computer. This facilitates the installation of new software and upgrades and maintenance from a single location.

In conclusions, many services and applications we’re using today considered web system as an option, providing seamless experience with all you need is a web browser. In the near future, web system development can be a perfect option to centralize all the latest features, keeping user friendliness and fully accessible anywhere.

Source: https://riseuplabs.com/web-system-development-process/

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.

Code Can be Dirty?

Unfortunately, yes

The above code is positively awful to look at, read, try to understand, and generally poor practice. Recently, in this semesters Software Development class, we have moved away from project structures, and into clean code. What makes it clean, why is it important, and related topics.

Why clean?

Clean code provides an easy reading experience for anyone looking at it. This include people later working on something released years ago, as well as the person writing completely new code for the first time. Every example of code can benefit from being clean. Coding cleanly enables readers to understand what the code is doing, and makes it easy to follow mentally. As well as this, clean code can make better code, as spotting mistakes is made easier when you know where everything should be.

What makes code clean?

Clean code is code that is easy to read, understand, and modify because it expresses its intent clearly and avoids unnecessary complexity. It uses meaningful names, small and focused functions, and consistent structure so that another developer can quickly grasp what it does without confusion. Clean code avoids duplication, hides internal details, and keeps responsibilities separated so each block does one thing well. It favors simplicity over cleverness, documents why decisions were made, and is organized in a way that makes future changes safe, predictable, and maintainable.

In the wild

This video is a perfect example of how clean code, and specifically refraining from nesting your code too much, is a good habit to form. The video explains that multiple layers of if statements, loops, and conditional branches make code harder to read, maintain, test, and debug. The creator argues that nesting increases cognitive load because developers must track several scopes at once, and it often signals that a function is trying to do too many things. The video recommends techniques such as using early returns, inverting conditions, and extracting complex inner blocks into smaller, well-named functions so the main “happy path” remains flat and easy to follow. Overall, reducing nesting leads to cleaner, more understandable, and more maintainable code.

I chose this resource as it was a fun video that I found ‘in the wild’ while simply scrolling, and felt that it closely aligned with principles we have been learning in class.

In conjunction with in class learning, I have been swayed to become a ‘never-nester’. I would like to put into practice this behavior, and am excited to maintain clean, readable code in future projects.

This concludes my mandatory blog post of Quarter 3 for the semester.

— Will Crosby

From the blog CS@Worcester – ELITE Computer Science by William Crosby and used with permission of the author. All other rights reserved by the author.

Beginning the Journey with Rest API

For this quarter’s blog post, I decided to dig deeper into Application Programming Interfaces (APIs). An API is a software translator that allows two applications to communicate with each other. It lets a client (i.e., web browser) request information that is held in a database, and get a structured and (hopefully) desired response back.

I chose this resource, API Architecture Patterns and Best Practices, as it describes API, its layers, the components within API, types of API architecture, and best practices when using API. As this resource states, APIs have a few conceptual layers that allow for communication to happen, including: Interaction, Application, Integration, and Data Layers.

There are a few resources I have compiled to further understand API, and this first resource was a great foundation for understanding the topics listed above and to prompt further exploration into a specific type of API Architecture: Rest API. This design has different names it goes by, but I wanted to further explore this as it is the design my course, Software Construction, Design, and Architecture, is heavily focused on. We are currently understanding API via an incredible resource at Worcester State University, called Thea’s Pantry.

A resource by IBM, “What Is Rest API?,” gave a very helpful walkthrough of what REST API is and how it operates. Rest API uses a representational state transfer (REST) design, using HTTP method calls including: Put, Post, Get, and Delete. These HTTP method calls provide a straightforward request and response communication style between the user’s client and server.

Understanding this topic was surprisingly exciting for me. Not only because this is a skill I need to have as a prospective software engineer, but because the more I practice and understand the purpose and components of API’s, the less overwhelming it actually feels. While exploring this topic in class, all of the necessary files, components, and everything that comes to be “API” were very overwhelming to learn within 75 minutes; and even more so to try and piece together on my own time.

There are a lot of pieces to the puzzle, but once I become more adept at putting them together, I know and can see that the outcome of such hard work will amaze me. It already amazes me! It also helped gain insight into how webpages operate, and sparked a growing interest in understanding the skeleton of webpages. I now can somewhat understand the F12 button, and not freak out when accidentally pressing it!

I plan to continue practicing and developing API on my own time. There are a variety of tools to begin practicing, following along with a guide, or trying to create on my own; and I thankfully have resources from my class to help with this as well. I want to develop my skill to not only write code, but also to clearly explain how all the pieces communicate with each other, the computer, the client, and the user. It is a fascinating system that will help me reach my goal of soon developing my own platforms. But, one step at a time!

Main Resources:
API Architecture Patterns and Best Practice – https://www.catchpoint.com/api-monitoring-tools/api-architecture

Thea’s Pantry – https://www.worcester.edu/campus-life/theas-pantry/

What is REST API? – https://www.ibm.com/think/topics/rest-apis

Additional Resources:
Back End for Beginners: Connect Your Front End to your own API – https://www.youtube.com/watch?v=8PMLZ3hkKXM

Caching – System Design Concept – https://www.geeksforgeeks.org/system-design/caching-system-design-concept-for-beginners/

HTTP messages – https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Messages

RESTful APIs in 100 Seconds // Build an API from Scratch with Node.js Express – https://www.youtube.com/watch?v=-MTSQjw5DrM

What is Scalability and How to achieve it? – https://www.geeksforgeeks.org/system-design/what-is-scalability/

From the blog CS@Worcester – Vision Create Innovate by Elizabeth Baker and used with permission of the author. All other rights reserved by the author.

More about SOLID design principles

For this quarters blog post, I wanted to write about SOLID design principles and chose SOLID design principles explained written by Phillip Johnson to better my understanding. During class activities we learned about design principles, specially object oriented programming which goes in hand with SOLID. Johnson’s blog explains these ideas in a clear and real-world way, using examples from different programming languages that we don’t use in class like Ruby and C#.

In Johnson’s post, he begins by sharing his personal experience when he first encountered SOLID through Sandi Metz’s book and how it helped him write better code across different languages. SOLID originates from an essay written by Robert Martin, also known as Uncle Bob in which he emphasizes that “successful applications will change and, without good design, can become rigid, fragile, immobile and viscous. These are some terms we learned in class. SOLID stands for five key ideas: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion.

Single Responsibility: we should avoid making multiple tasks in one class. Johnson’s example refactors database and file operations into separate classes. Open/Closed: extend behaviors without altering existing code, essentially if we wanted to add/change functions in an existing class then we should be able to do so by extending the class instead of modifying it. Johnson also uses the duck example that we worked on. Liskov Substitution: sub classes should work just like their parent classes. We shouldn’t be making overrides that change expected behaviors. Interface Segregation: Use small, specific interfaces instead of big ones. Johnson’s example uses ducks and fish, and how we should separate each behavior just like we did in our Design Patterns homework. Dependency Inversion: rely on abstractions and not specific details. Basically, High-level code shouldn’t depend on low-level details.

From Johnson’s blog, I was able to learn more in depth about what SOLID is, how each of the principles connect, and how to find code smells. I think his post helped me understand our previous Design Patterns homework even more than I did while completing it. What stood out to me most was that the blog didn’t just explain what SOLID is. It showed me why these principles matter in real code. I realized that creating good code isn’t just about make it work once, but rather about making it easy to maintain, refactor, and improve over time. Because of this, I want to prioritize using SOLID a lot more in my future coding projects so that my code remains clean, adaptable, and easy to extend.

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

UML Class Diagrams

Link: https://www.jointjs.com/blog/uml-class-diagrams

In this blog post, I decided to look at Martin Kaněra’s blog post titled “UML Class Diagrams: All you need to know.” This blog post gives a comprehensive overview of UML class diagrams, covering what they are, why they matter in object-oriented development, and how they can compare to other UML diagrams. This post explains that UML class diagrams model the static structure of systems by showing classes, attributes, and methods. They also show the relationships between them, such as association, inheritance, and aggregation. Kaněra says that each class rectangle is divided into three parts, which are name, attributes, and methods. There are visibility symbols such as “+” for public, “#” for protected, and “-” for private. I liked how Kaněra discussed abstract classes and interfaces, as we see those concepts show up often and they can sometimes be a little bit confusing unless you see them drawn out. The blog also mentions how class diagrams should be used for structure, sequence diagrams should be used for object interactions over time, and that activity diagrams should be used for flows of control.

I chose this blog post because we went over the UML class diagrams earlier this semester, so I thought it would be nice to get a quick refresher and also do a deeper dive into the topic. We’ve done assignments involving UML diagrams, but there were always a few small things I would get confused about so it was nice to get clarification. I also think that it is very important to know this stuff, as this is a part of how real teams design and discuss systems. This blog post does a very good job of showing how class diagrams play a role in real life software projects as well.

Reading this blog post made me realize how important UML class diagrams are. Kaněra does a good job placing emphasis on identifying design problems early, such as classes that have too many dependencies. This just further shows how useful these diagrams are for projects. In the future, I can apply this by sketching a quick class diagram before I start coding a feature, and then I could revisit it while I am working on the project. I can also do this for group projects, as using a shared diagram could help keep everyone on the same page for terminology and boundaries between components.

Overall, this blog post helped refresh my memory on UML class diagrams, and also gave me some further clarification on certain principles. After reading this blog, I feel much more confident in implementing UML class diagrams into future projects.

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

API

The software landscape is dynamic and constantly changing. Application Programming Interfaces(API’s) have evolved from what was once an optional tool, to a vital epic of software architecture. These APIs are the joining forces between different systems allowing mobile devices, third party services, backend microservices, and front end interfaces to interact in an efficient structured manner.

Simply put, API defines rules and protocols for software components to interact. When focusing on backend development, API’s are used to show system functionality. Whether its authenticating users or retrieving data APIs can expose flaws or confirm functionality. This rewards systems that have flexibility in their development because the internal implementation can be abstracted from the external interface.

There are several types of APIs that have specific implementations for system architecture.

REST API’s: REST or (Representational State Transfer) is the most prevalent for web based services. These use the standard HTTP(GET, POST, PUT, and DELETE), and client stateless architecture. Client stateless architecture is a system where the server stores one of the client information, rather it treats each request as a self contained independent transaction.
GraphQL APIs: These enable clients to request specific needed data from a single endpoint. This can cut back on network overhead simplifying client code. This is useful for client-driven backends.
Websocket API’s: these are useful for real-time, two directional communication. This includes chats, gaming, updates, ect. This allows persistent connection between the client and server. Using Websocket entails event-driven design

APIs are essential for maintainable back-end architecture. Alongside these APIs, there are best practices to follow to get the most out of API’s. Clear naming conventions should be used to ensure consumers understand. Using intuitive consistent resource names allows for a clearer overall architecture. The next best practice is Versioning. As systems change, versionaling ensures that people running older clients can still run them. This backwards compatibility is essential. Keeping good documentation is also very necessary. This helps developers understand how to use the API and how it interacts with the larger system. Security is needed to safeguard data and API endpoints. And finally error handling with meaningful messages helps keep everything clear while testing for development and dealing with bugs.

Choosing the correct backend framework can influence how you create your API. Express.js on Node.js, is lightweight and suited for RESTful services. Django REST Framework is built on python and uses rapid API development containing built in features. Spring boot is Java based and is good for microservices architecture. This isn’t just picking a syntax, this shapes how you test, modularize, secure and scale this architecture.

My personal experience has now shown how useful API design is. When building a simple REST API for guest data, I defined clear endpoints, selected correct HTTP verbs, and used tools like swagger and spectral to validate my work. This showed me how important consistent status codes are. Even small mistakes like forgetting a field or misnaming a route broke client calls. Working through this has shown me how good design can save time by reducing confusion, bugs, and reworks.

APIs are not just endpoints, they are crucial pieces to backend software architecture. They encapsulate complexities, and allow for scalable maintainable systems. This API layer is not just a bridge, but a foundational piece of architecture.

View at Medium.com

From the blog CS@Worcester – Aaron Nanos Software Blog by Aaron Nano and used with permission of the author. All other rights reserved by the author.

Share this:

Share this:

Source

Share this:

Share this:

Share this:

Unfortunately, yes

Why clean?

What makes code clean?

In the wild

Share this:

Share this:

Share this:

Share this:

Share this: