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.

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.

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.

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.

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.

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.

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.