Blog post 2 – Design Smells

In programming, we often make a lot of mistakes, some break the code, and some do not. The ones that do not tend to bring down the efficiency of our code and make it very difficult to work with. Some of these mistakes have to do with the way we write the code, and they tend to hint at a bigger problem in the code design. These mistakes are called design smells. I think Martin Fowler defines coding smells the best, he defines them as a “surface indication that usually corresponds to a deeper problem in the system.” Design smells come in all different ways, but they usually stem from developers not following best practices. The end result is that the code either becomes too bloated, too inefficient or breaks easily. Luckily, design smells are rather easy to spot once you know what they are. Some of the more common smells are:

Rigidity – Program breaks in many places when a single change is made to the code.

Immobility – The code contains parts that could be useful in other systems, but the effort and risk involved in separating those parts from the original system are too great.

Opacity – This smell occurs when the code is difficult to understand and follow.

Fragility – The code becomes pretty difficult to change. A simple change could cause a cascade of subsequent changes in dependent modules.

Viscosity –  When making changes to the code, it is easy to do the wrong thing, but hard to do the right thing.

Needless complexity –  There are elements in the code that are not useful. Having them in the code is simply not necessary and it makes the code more complex than it needs to be.

Needless repetitiveness –  There are too many repeating elements in the code that could be removed by using abstracted or refactoring the program.

These are things that we do not want in the code. In fact, they are considered technical debt. Technical debt is a term that describes the effects of mistakes or bad practices in code. As we program, we are going to make mistakes, errors, and sometimes not follow best practices. These shortcomings are things that we will have to revisit later today and spend time, resources, and effort spent on trying to fix and modify the code to make it work better. In this sense, it is similar to normal debt.  Once you know the smells, it’ll become a lot easier to find them in your code. If you do spot design smells, then it is best to try to remove and solve the underlying problem.

https://martinfowler.com/bliki/CodeSmell.html

https://martinfowler.com/bliki/TechnicalDebt.html

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

Exploring Microservices

[What are Microservices? | IBM]

To prepare for my capstone, I decided to read up on microservices. This article is mainly just describing what they are, but it also mentions some common pitfalls towards the end. I was also interested in exploring criticisms of microservice architecture, but I want to keep the scope of this post short. However, I think it’s a pretty straightforward trade-off, which I will mention in a moment.

Microservice architecture is an architectural approach in which one application is composed of smaller components called services. This is distinct from other forms of software encapsulation because services essentially function as distinct programs, potentially operating on different programming languages, frameworks, and with their own databases. Rather than messages within the same process, services communicate over a network with a shared API.

Services can be updated individually without knowledge of the overall application. Different programming languages can be used for different components to better suit the needs of those components. Individual services can be scaled when necessary, rather than the whole application. This method also demonstrates the quality of “loose coupling,” which is lowering the amount of of dependencies between components as much as possible. The risk of a change to one service introducing problems in other services is still present, but minimized.

In general, this kind of technique basically combats complexity by adding complexity. It isn’t applicable to every situation. It should not be chosen if the overhead of designing the system is significantly more than the overhead of not doing so, which will often be the case for small problems.

For the purpose of the LibreFoodPantry project, microservice architecture is useful. In another scenario, such as one where high performance is a major concern, it may be a problem. If different services are busy sending messages back and forth, it can waste a lot of processor cycles on providing flexibility that isn’t really necessary.

Microservice architecture introduces complexity in communicating between all the services. Different tech stacks being used between different services raises the amount of general knowledge a person needs to be able to understand the whole application.

All this being said, I’m actually looking forward to working on a project using this architecture. The only large project I’ve worked on before was the backend for a school website, which was using a more monolithic approach. We were locked in to one specific language, and what we were doing was often a little inscrutable (although this may be in part because I was a junior in high school). I think that microservice architecture allows for more flexibility in low-level decision making, which will make using it in practice more engaging.

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

Let’s Get RESTful

This week, as we have started covering REST APIs in class, I thought it would be good to learn a little more about them. While we haven’t finished going over it in class, there’s just something about REST that hasn’t clicked with me, so finding out a little more about what “REST” means, and how they are used would be useful to help me conceptualize the material. That being said, after looking through some blogs, I found a great post about REST APIs called “REST API: Key Concepts, Best Practices, and Benefits” off the AltexSoft blog.

This blog post establishes Representational State Transfer (REST) is an architectural style for APIs that standardizes interfaces between clients and servers in order to create, receive, update, or delete resources. These 4 actions are referred to by the acronym CRUD. The API acts as a handler for requests from client to server and replies from the server back to the client. These are the basic interactions that REST APIs are built to do. The article then talks about what makes an API “RESTful”, and how the principles of the REST architecture influence API design. These principles, called constraints within REST, are client and server autonomy, having a uniform interface and layered architecture, the use of caching, being stateless, and having the ability to run code on demand. Most importantly though, is flexibility by prioritizing business needs. This means that any of the other aspects of REST can be changed or ignored if they conflict with the needs of the API’s owner. The final part of the article covers some examples of REST API being used, with services such as Trello, and then compares REST to other API architecture like SOAP and GraphQL, which have some advantages over REST but are far more situation-dependant.

I think that most of the constraints that REST puts on API development seem extremely sensible. Especially the fact that they are there more as guidelines than as hard rules. Not every service is going to have the same needs, so the ability to use a framework that is flexible to those needs seems extremely useful. In the article, the author talks about how very few people actually apply all of these RESTful constraints, especially things like Code on Demand, as they have concerns about the security implications of doing things like this, which I also think is sensible. The uniform interface constraint seems extremely important to me as well, having an API that can run on any client platform or application, and will always have a standardized way of communicating with the server just seems like proper design. And the standardization seems to be one of the main selling points of REST. This definitely gave me a much better understanding of what REST APIs are, and why people would want to use them. It seems like an extremely flexible tool for API development and I will likely use it over other API architectures if I’m ever in that situation.


Source: https://www.altexsoft.com/blog/rest-api-design/

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

APIs and REST APIs

Hello everyone and welcome back to my blog. Last week we talked about APIs in Activity 12 and I want to go more in depth about APIs and what a REST API is since I don’t really know what they are. API stands for Application Programming Interface and it is a set of definitions that allows two applications to talk to each other. Almost every application uses an API to communicate data from your device to a server. The server has its own APIs to receive that data and interpret it, and then send it back to your device. Then the application translates that data into a readable format for you. You do not have to know how they are implemented into your application, which can simplify the application development and save a lot of time. 

APIs can also give security by only allowing certain data through and not all the data. For example, when you buy an item on an online store, you tell the store what items you want to buy and the store tells you what you need to pay. No other information from either your device or the website’s databases is transferred over. What I find interesting about APIs is how they work in video games. There can be multiple APIs in a game that each do something different, such as managing a game’s sound, rendering, and graphics, while others manage AI tasks such as path-finding. Pokemon is one of the most popular video game series out there and there is an API called “Poke API” that has every single Pokemon listing with moves, types, and weaknesses as well as every item in the games. A Pokemon website can use that API to easily get the latest updated information about Pokemon and the games.

REST API or RESTful API stands for Representational State Transfer API. It usually takes advantage of HTTP when used for Web APIs. This means that developers do not need to install libraries or additional software in order to take advantage of a REST API design. However, not all APIs can be REST APIs. In order for an API to be RESTful, it has to follow certain criteria. The client and the server should be separate from each other and allowed to evolve individually and independently, meaning making changes to the database won’t affect the clients. Stateless client-server communication, meaning no client information is stored between get requests and each request is separate and unconnected. Cacheable data that streamlines client-server interactions. A uniform interface which lets the client talk to the server in a single language, standardized means of communicating between the client and the server. A layered system that organizes each type of server. And lastly, Code-on-demand, which is the ability to send executable code from the server to the client when requested. All of these define what REST APIs do.

https://www.redhat.com/en/topics/api/what-is-a-rest-api

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

APIs and REST APIs

Hello everyone and welcome back to my blog. Last week we talked about APIs in Activity 12 and I want to go more in depth about APIs and what a REST API is since I don’t really know what they are. API stands for Application Programming Interface and it is a set of definitions that allows two applications to talk to each other. Almost every application uses an API to communicate data from your device to a server. The server has its own APIs to receive that data and interpret it, and then send it back to your device. Then the application translates that data into a readable format for you. You do not have to know how they are implemented into your application, which can simplify the application development and save a lot of time. 

APIs can also give security by only allowing certain data through and not all the data. For example, when you buy an item on an online store, you tell the store what items you want to buy and the store tells you what you need to pay. No other information from either your device or the website’s databases is transferred over. What I find interesting about APIs is how they work in video games. There can be multiple APIs in a game that each do something different, such as managing a game’s sound, rendering, and graphics, while others manage AI tasks such as path-finding. Pokemon is one of the most popular video game series out there and there is an API called “Poke API” that has every single Pokemon listing with moves, types, and weaknesses as well as every item in the games. A Pokemon website can use that API to easily get the latest updated information about Pokemon and the games.

REST API or RESTful API stands for Representational State Transfer API. It usually takes advantage of HTTP when used for Web APIs. This means that developers do not need to install libraries or additional software in order to take advantage of a REST API design. However, not all APIs can be REST APIs. In order for an API to be RESTful, it has to follow certain criteria. The client and the server should be separate from each other and allowed to evolve individually and independently, meaning making changes to the database won’t affect the clients. Stateless client-server communication, meaning no client information is stored between get requests and each request is separate and unconnected. Cacheable data that streamlines client-server interactions. A uniform interface which lets the client talk to the server in a single language, standardized means of communicating between the client and the server. A layered system that organizes each type of server. And lastly, Code-on-demand, which is the ability to send executable code from the server to the client when requested. All of these define what REST APIs do.

https://www.redhat.com/en/topics/api/what-is-a-rest-api

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

APIs and REST APIs

Hello everyone and welcome back to my blog. Last week we talked about APIs in Activity 12 and I want to go more in depth about APIs and what a REST API is since I don’t really know what they are. API stands for Application Programming Interface and it is a set of definitions that allows two applications to talk to each other. Almost every application uses an API to communicate data from your device to a server. The server has its own APIs to receive that data and interpret it, and then send it back to your device. Then the application translates that data into a readable format for you. You do not have to know how they are implemented into your application, which can simplify the application development and save a lot of time. 

APIs can also give security by only allowing certain data through and not all the data. For example, when you buy an item on an online store, you tell the store what items you want to buy and the store tells you what you need to pay. No other information from either your device or the website’s databases is transferred over. What I find interesting about APIs is how they work in video games. There can be multiple APIs in a game that each do something different, such as managing a game’s sound, rendering, and graphics, while others manage AI tasks such as path-finding. Pokemon is one of the most popular video game series out there and there is an API called “Poke API” that has every single Pokemon listing with moves, types, and weaknesses as well as every item in the games. A Pokemon website can use that API to easily get the latest updated information about Pokemon and the games.

REST API or RESTful API stands for Representational State Transfer API. It usually takes advantage of HTTP when used for Web APIs. This means that developers do not need to install libraries or additional software in order to take advantage of a REST API design. However, not all APIs can be REST APIs. In order for an API to be RESTful, it has to follow certain criteria. The client and the server should be separate from each other and allowed to evolve individually and independently, meaning making changes to the database won’t affect the clients. Stateless client-server communication, meaning no client information is stored between get requests and each request is separate and unconnected. Cacheable data that streamlines client-server interactions. A uniform interface which lets the client talk to the server in a single language, standardized means of communicating between the client and the server. A layered system that organizes each type of server. And lastly, Code-on-demand, which is the ability to send executable code from the server to the client when requested. All of these define what REST APIs do.

https://www.redhat.com/en/topics/api/what-is-a-rest-api

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

APIs and REST APIs

Hello everyone and welcome back to my blog. Last week we talked about APIs in Activity 12 and I want to go more in depth about APIs and what a REST API is since I don’t really know what they are. API stands for Application Programming Interface and it is a set of definitions that allows two applications to talk to each other. Almost every application uses an API to communicate data from your device to a server. The server has its own APIs to receive that data and interpret it, and then send it back to your device. Then the application translates that data into a readable format for you. You do not have to know how they are implemented into your application, which can simplify the application development and save a lot of time. 

APIs can also give security by only allowing certain data through and not all the data. For example, when you buy an item on an online store, you tell the store what items you want to buy and the store tells you what you need to pay. No other information from either your device or the website’s databases is transferred over. What I find interesting about APIs is how they work in video games. There can be multiple APIs in a game that each do something different, such as managing a game’s sound, rendering, and graphics, while others manage AI tasks such as path-finding. Pokemon is one of the most popular video game series out there and there is an API called “Poke API” that has every single Pokemon listing with moves, types, and weaknesses as well as every item in the games. A Pokemon website can use that API to easily get the latest updated information about Pokemon and the games.

REST API or RESTful API stands for Representational State Transfer API. It usually takes advantage of HTTP when used for Web APIs. This means that developers do not need to install libraries or additional software in order to take advantage of a REST API design. However, not all APIs can be REST APIs. In order for an API to be RESTful, it has to follow certain criteria. The client and the server should be separate from each other and allowed to evolve individually and independently, meaning making changes to the database won’t affect the clients. Stateless client-server communication, meaning no client information is stored between get requests and each request is separate and unconnected. Cacheable data that streamlines client-server interactions. A uniform interface which lets the client talk to the server in a single language, standardized means of communicating between the client and the server. A layered system that organizes each type of server. And lastly, Code-on-demand, which is the ability to send executable code from the server to the client when requested. All of these define what REST APIs do.

https://www.redhat.com/en/topics/api/what-is-a-rest-api

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

APIs and REST APIs

Hello everyone and welcome back to my blog. Last week we talked about APIs in Activity 12 and I want to go more in depth about APIs and what a REST API is since I don’t really know what they are. API stands for Application Programming Interface and it is a set of definitions that allows two applications to talk to each other. Almost every application uses an API to communicate data from your device to a server. The server has its own APIs to receive that data and interpret it, and then send it back to your device. Then the application translates that data into a readable format for you. You do not have to know how they are implemented into your application, which can simplify the application development and save a lot of time. 

APIs can also give security by only allowing certain data through and not all the data. For example, when you buy an item on an online store, you tell the store what items you want to buy and the store tells you what you need to pay. No other information from either your device or the website’s databases is transferred over. What I find interesting about APIs is how they work in video games. There can be multiple APIs in a game that each do something different, such as managing a game’s sound, rendering, and graphics, while others manage AI tasks such as path-finding. Pokemon is one of the most popular video game series out there and there is an API called “Poke API” that has every single Pokemon listing with moves, types, and weaknesses as well as every item in the games. A Pokemon website can use that API to easily get the latest updated information about Pokemon and the games.

REST API or RESTful API stands for Representational State Transfer API. It usually takes advantage of HTTP when used for Web APIs. This means that developers do not need to install libraries or additional software in order to take advantage of a REST API design. However, not all APIs can be REST APIs. In order for an API to be RESTful, it has to follow certain criteria. The client and the server should be separate from each other and allowed to evolve individually and independently, meaning making changes to the database won’t affect the clients. Stateless client-server communication, meaning no client information is stored between get requests and each request is separate and unconnected. Cacheable data that streamlines client-server interactions. A uniform interface which lets the client talk to the server in a single language, standardized means of communicating between the client and the server. A layered system that organizes each type of server. And lastly, Code-on-demand, which is the ability to send executable code from the server to the client when requested. All of these define what REST APIs do.

https://www.redhat.com/en/topics/api/what-is-a-rest-api

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

APIs and REST APIs

Hello everyone and welcome back to my blog. Last week we talked about APIs in Activity 12 and I want to go more in depth about APIs and what a REST API is since I don’t really know what they are. API stands for Application Programming Interface and it is a set of definitions that allows two applications to talk to each other. Almost every application uses an API to communicate data from your device to a server. The server has its own APIs to receive that data and interpret it, and then send it back to your device. Then the application translates that data into a readable format for you. You do not have to know how they are implemented into your application, which can simplify the application development and save a lot of time. 

APIs can also give security by only allowing certain data through and not all the data. For example, when you buy an item on an online store, you tell the store what items you want to buy and the store tells you what you need to pay. No other information from either your device or the website’s databases is transferred over. What I find interesting about APIs is how they work in video games. There can be multiple APIs in a game that each do something different, such as managing a game’s sound, rendering, and graphics, while others manage AI tasks such as path-finding. Pokemon is one of the most popular video game series out there and there is an API called “Poke API” that has every single Pokemon listing with moves, types, and weaknesses as well as every item in the games. A Pokemon website can use that API to easily get the latest updated information about Pokemon and the games.

REST API or RESTful API stands for Representational State Transfer API. It usually takes advantage of HTTP when used for Web APIs. This means that developers do not need to install libraries or additional software in order to take advantage of a REST API design. However, not all APIs can be REST APIs. In order for an API to be RESTful, it has to follow certain criteria. The client and the server should be separate from each other and allowed to evolve individually and independently, meaning making changes to the database won’t affect the clients. Stateless client-server communication, meaning no client information is stored between get requests and each request is separate and unconnected. Cacheable data that streamlines client-server interactions. A uniform interface which lets the client talk to the server in a single language, standardized means of communicating between the client and the server. A layered system that organizes each type of server. And lastly, Code-on-demand, which is the ability to send executable code from the server to the client when requested. All of these define what REST APIs do.

https://www.redhat.com/en/topics/api/what-is-a-rest-api

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

APIs and REST APIs

Hello everyone and welcome back to my blog. Last week we talked about APIs in Activity 12 and I want to go more in depth about APIs and what a REST API is since I don’t really know what they are. API stands for Application Programming Interface and it is a set of definitions that allows two applications to talk to each other. Almost every application uses an API to communicate data from your device to a server. The server has its own APIs to receive that data and interpret it, and then send it back to your device. Then the application translates that data into a readable format for you. You do not have to know how they are implemented into your application, which can simplify the application development and save a lot of time. 

APIs can also give security by only allowing certain data through and not all the data. For example, when you buy an item on an online store, you tell the store what items you want to buy and the store tells you what you need to pay. No other information from either your device or the website’s databases is transferred over. What I find interesting about APIs is how they work in video games. There can be multiple APIs in a game that each do something different, such as managing a game’s sound, rendering, and graphics, while others manage AI tasks such as path-finding. Pokemon is one of the most popular video game series out there and there is an API called “Poke API” that has every single Pokemon listing with moves, types, and weaknesses as well as every item in the games. A Pokemon website can use that API to easily get the latest updated information about Pokemon and the games.

REST API or RESTful API stands for Representational State Transfer API. It usually takes advantage of HTTP when used for Web APIs. This means that developers do not need to install libraries or additional software in order to take advantage of a REST API design. However, not all APIs can be REST APIs. In order for an API to be RESTful, it has to follow certain criteria. The client and the server should be separate from each other and allowed to evolve individually and independently, meaning making changes to the database won’t affect the clients. Stateless client-server communication, meaning no client information is stored between get requests and each request is separate and unconnected. Cacheable data that streamlines client-server interactions. A uniform interface which lets the client talk to the server in a single language, standardized means of communicating between the client and the server. A layered system that organizes each type of server. And lastly, Code-on-demand, which is the ability to send executable code from the server to the client when requested. All of these define what REST APIs do.

https://www.redhat.com/en/topics/api/what-is-a-rest-api

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.