Category Archives: CS-343

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.

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.

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.

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.

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.

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.

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.

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this: