Category Archives: CS-343

The Difference Between Frontend and Backend

Christian Shadis

Over the past month, my Software Construction, Architecture, and Design course has shifted gears into a sort of crash-course for full-stack web development, as I mentioned in the last blog post. We have focused primarily on the backend, creating RESTapi endpoints in the api.yaml file, along with implementing those endpoints in Javascript. In the final two weeks of class, we are transitioning into implementing a front end using Vue.js. In the process of switching contexts, my understanding of the difference between a frontend and backend became a bit obfuscated.

In Frontend vs Backend, Maximilian Schwarzmüller first declares that the common refrain that each web app is built from a frontend and a backend. He then begins to describe the differences between them. In short, the difference between the frontend and backend of a web app is that the frontend refers to the content displayed in the browser, while the backend refers to the portion of the program which runs on a server. He gives the helpful example of Amazon – it consists of a frontend (the catalog, shopping cart, and other visual elements of the webpage) and a backend (all data/database management). He is careful to specify that the difference does not lie only in where data is stored, because there are non-database aspects of a backend as well, such as file system interaction or input validation. He also lists several skills and programming languages that a programmer may need in order to build the frontend (HTML, CSS,  Javascript, Vue.js / React.js / Angular) and the backend (Node.js, PHP, Python).

One area of confusion for me was understanding exactly how the frontend and backend communicated with each other – via HTTP requests. We had discussed and implemented HTTP requests in class, but I thought the communication occurring was between the backend and the database. In fact, the user performs some action on the frontend, resulting in an HTTP request being sent to the backend (and by extension, the database).

Knowing how to code both the frontend and backend of a web app is vital to become a web developer, but it is also important to be able to differentiate between them, and to understand why they are considered separate components of an app. I plan to work on developing the full stack of a web application from scratch, and the information from this article will enable me to begin development with a stronger understanding of how to build the frontend and backend properly to communicate with each other.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Exploring NoSQL

Throughout the last couple of weeks, we have been working with MongoDB in our exploration of web application development. After hours of scrolling through MongoDB documentation to figure out how to do assignments and learning about how to use this particular service, I thought it would be important to learn a little bit more about NoSQL databases and why they are being used more and more frequently in software development circles. To this end, I found an article by MongoDB about NoSQL databases and thought it would be the perfect introduction to the topic.

The article starts with a basic explanation of the differences between relational databases and NoSQL, that it stores information in a non-relational format, thus providing more flexibility with schemas, faster query times, ease of use, and horizontal scaling that is not present in traditional database design. It then goes into the different types of NoSQL databases, those being document, key-value, wide column, and graph databases, giving brief explanations of those. MongoDB is a document database, holding all information in a JSON format. The article goes deeper into the differences between NoSQL and relational databases, showing an example of the two. In general, the main reason to use NoSQL databases, in my opinion, is the flexibility they have. There is no need to split up data that has no reason to be split up. All data for a single object can be stored within that object, without having to relate it to a completely different table. It takes out a lot of unnecessary complexity within the schema and to that end can speed up the time it takes to access data. The article then clears up misconceptions about NoSQL databases and provides a tutorial example on how they can be used.

After reading about the differences, and having worked with both SQL databases and MongoDB, I much prefer the flexibility of NoSQL database design over that of SQL, and the performance increase is an added bonus as well. I don’t know why anyone would stick with a slower, more rigid database structure unless their application absolutely needed it. Not to mention the fact that SQL has always had issues, and is far more vulnerable to security risks (thinking about SQL injection, which doesn’t seem like it would be as much of a problem here). This gave me a lot more appreciation for the usefulness of a NoSQL database design as a whole and aided in my understanding of what they are. In the future, unless I have to, I would much prefer to work with a NoSQL database over a relational one, and given the trends of web app development, I think a lot of others are thinking the same thing.

Source: https://www.mongodb.com/nosql-explained

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.

SPA treatment. How’s the Vue over there?

With front-end development being one of the last topics we cover for this semester, I decided to take a deeper look into things that can be built using the frameworks we’ve utilized. Vue.js for example is a framework that can be used to develop a front-end application. One type of front-end application that many of us are very familiar with is a Single Page Application(SPA). An SPA is an application that displays all of its information, well, on a single page. It sounds like a lot but only the requested and necessary information is usually displayed on the page at one time. 

For example, most email service providers have been developed using SPA styled programming. If you’re like me, you have a ton of unread emails that you are just too lazy to go through and delete. All of these messages can span over the course of a few “pages”. As you click through the pages, you can see how quickly the response is while sifting through them. Although this design gives you the impression that you are navigating through many different pages, the browser is just updating the very same page that you navigated to.

While some of this implementation is back-end stuff, Vue can help make this possible with the use of components, that’s all it really is. Instead of having to use hundreds of unmaintainable lines of javascript to add functionality to an application, Vue makes it really simple and easy to maintain your code with Don’t Repeat Yourself (DRY) standards. It starts with a root component to get the Vue framework into your code. From there everything else is just a series of components to get everything working. 

Components come in two different flavors. Global components, as the name might suggest, are registered and usable everywhere within the application. Local components are only usable wherever they are registered. To register a component as global you would need to use the Vue.component method. Registering a component locally would require that you make it a part of the “props” of an element. Figuring out when to use a component globally or locally calls for careful consideration when making your application. 

There are other great front-end developing frameworks like React.js and Angular.js. Along with Vue, these three are very popular in terms of leading frameworks that developers like to use in the present day.

My sources I used for this post:

https://vuejs.org/v2/guide/components.html

Understand VueJS in 5 minutes

Global & Local Components

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

JavaScript Quirks

As time goes on and I have learned more about JavaScript and its use in the back-end and front-end. I have found many surprises about JavaScript compared to other programming languages. The more I interact with it, the deeper I get to know the language and the framework inside. This article is to point out some of the odds about JavaScript.
Semicolon (;)
Java requires a semicolon at the end of every single statement, in case we don’t put a semicolon at the end the compiler would give us errors. Unlike Java, JavaScript does not have a compiler hence if we, unfortunately, missed out on semicolon, there’s not going to be any warning, but it might result in breaking our code or it would simply refuse to work. That is because of JavaScript’s automatic semicolon insertion rule. The rule states that a valid program ends with a (;) if it does not end with a (;) then JavaScript will automatically insert a (;). Therefore, it will not ask us to insert a semicolon.
Strict Equality (===)
Java has two types of Equality; one is single equality (=) means it’s used for numbers and the other is double equality (==) which is used for String. Move on to JavaScript, it has 3 types of equality. Two are similar to Java but there is also another one, it’s called Strict Equality (===). The Strict Equality checks if the data types are the same and if it is not, it returns false. Complicated, isn’t it?
Let and Const
It would be best not to use “var” to declare variable because it is not block-scoped and allows for mutation. Being block-scoped means a variable does not pass its boundaries, unlike var that does not respect borders. Professional users advise newbies to use “let” or “const” to declare the variable. Usually, developers would use “let” unless they don’t want that variable to change then they would use “const”. On the other hand, Java gives users a variety of variable declarations such as int (Integer), String, double (2.9), or boolean (true or false). So, simple but not simple at all.
Fixing Errors
About fixing errors, since JavaScript does not have a compiler, therefore, it’s harder to fix errors unless we type something that is absolutely not making any sense. The only way to fix the error is to run the code on localhost and figure it out from there. However there’s a fix for that, it’s ESLint. This extension uses command lines to tell us where the problem lies but also could fix the errors if we run.
Now we have learned some JavaScript quirks and there are many more that we should spend more time to look. But JavaScript still dominates the market despite all things above and is one of the most popular languages in 2021 and undoubtedly 2022. So, deal with it.

https://rofiatolusanya.medium.com/javascript-quirks-84d2d8ac4f41

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

UML Diagrams – PlantUML

We learned PlantUML at beginning of the semester and even did an entire homework creating UML diagrams of a project. But the reason I am writing about UML diagrams right now is because as I was going through previous activities I realized, not only can UML diagrams be used for code built on OOP but also to create a simple and easy to read diagram of an microservices architecture.

As we all know we are going to be using microservices architecture to build Libre Food Pantry so I decided to look for a resource that can make using PlantUML simpler and easier to use and understand. I found a great blog by solutions architect Alex Sarafian. Below are the few features that I found very useful:

  • We can color code arrows for multiple flows flow of the diagram and add legend to specify what color represents which flow.

Format example:        A -> B #Blue : text

legend

    | Color | Flow |

    |<#Red>|  Flow 1 |

    |<#Blue>|  Flow 2 |

endlegend

We can color code arrows inside PlaceOrderService and ApproveOrderService for easier understanding of the services.

  • Autonumber feature will automatically add a number alongside the text of every event. Autonumber gives a linear sequence of events that are going to take place. For example, 1st UI placing the order to API, then 2nd from API to Database and so on.

Format example 1: numbers in front of event text

autonumber

Bob -> Alice : Authentication Request

Bob <- Alice : Authentication Response

Format example 2: Numbers are 2-digit padded and highlighted

autonumber “<B>[00]”

Bob -> Alice : Authentication Request

Bob <- Alice : Authentication Response

  • PlantUML limits the image width and height to 4096. Therefore, when image file is created over the limit of 4096, diagrams are cutoff completely taking away the advantage of efficient flow UML diagram. To fix this we can use command line parameters to increase the width and height limit of image. Another way is to use ‘skinparam dpi X’ parameter. However, the downside to using skinparam is that we must find the value for ‘X’ by experimenting to see when UML diagram fits the best.
  • We can display text relevant to an event below the arrow for a cleaner UML diagram. We a skin parameter to achieve this. For example:

skinparam responseMessageBelowArrow true

autonumber “<B>[00]”

Bob -> Alice : Authentication Request

Bob <- Alice : Authentication Response

  • PlantUML supports a lot of different colors. A neat trick is to use the ‘colors’ command to render a picture with all colors.

Sources: https://www.codit.eu/blog/plantuml-tips-and-tricks/?country_sel=be

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

REST API

We have been using REST API for most of the semester now but did not really read or have knowledge about it. We have been reading a lot of documentation of MongoDB – its operators, commands, methods, or collections. but nothing about REST even though we will be using REST API again in future semester i.e., for capstone when we are working on Libre food pantry. Therefore, I wanted to research REST and found a very interesting blog by Adam Duvander.

REST stands for REpresentational State Transfer. REST API’s are a form of web services used to run websites (like we have built Libre food pantry example), mobile applications and most enterprise integrations.

Important thing to know about REST is that it is not a standard, it is built over HTTP standard. The information can be in several formats: JSON, HTML, XLT, Python, PHP, or even plain text. JSON is the one we have been using and probably will be using because it is easy to read by both people and machines.

Developers used HTTP methods or HTTP verbs to define the requests being made. GET, PUT, POST, and DELETE are ones we have used so far. PATCH is another commonly used HTTP method to update a subset of existing data.

REST resource is data that is modified or accessed using HTTP methods. For example, when we worked on backend, we defined a path to access or modify data by using GET, PUT or POST methods. An example of a request would be:

POST /order/{id}/items

{id} would be an identifier to find order with that specific id value. Identifiers can be integers or hashes.

REST architecture is made of this resources and requests and requests are made using HTTP methods. REST architecture also states that information should not be stored after any request is executed, meaning every request is independent of the other. However, resources should be accessible and modifiable by the user. Therefore, interface between components is needed so that resources requested are identifiable and separate from representations sent to the user. The representation has information which can be then used by user to access and modify resources. REST architecture also needs cache for interactions between user and server and a system to handle different servers used to process requested information into hierarchies.

Built on these principles, REST is very versatile, able to work in a large variety of environments, with multiple data types making REST API’s faster and lightweight.

Sources: https://blog.stoplight.io/rest-api-standards-do-they-even-exist

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Getting Started with Axios

View at Medium.com

https://www.sitepoint.com/axios-beginner-guide/

This week I decided to write about Axios for JavaScript. We are using Axios on our front end. So I thought it could be helpful to read an article about Axios, and learn more about what Axios does and how it works.

Axios can be used on backend node.js applications. And used in JavaScript files/ frameworks like Vue, React, and Angular. One of the most common uses of Axios is making HTTP requests to send, receive, or save data. Data passed in post operations is conveniently sent in JSON format. Below is an example of an axios HTTP request method.

axios({
  method: 'post',
  url: '/login',
  data: {
    user: 'brunos',
    lastName: 'ilovenodejs'
  }
});

Axios also has a convenient way to receive responses. Axios returns a promise that is either a response or an error method. A response object is returned with a successful call, and the .then() function is called. The response object has data, which is the payload in JSON. The status in the form of an HTTP code. The status text, which is an HTTP message. Headers, returned by the server. The original request information. And the HTTP request in the XMLHTTPRequest object format.

If an Axios request returns an error, the promise will be rejected and an error object is returned. An error object includes: an error message, a response object, a request, and the original request. 

axios.get('/product/9')
  .then(response => console.log(response))
  .catch(error => console.log(error));

To better understand Axios, it is worth explaining what a JavaScript promise is, and why programmers use them. Promises are used to handle asynchronous functions in JavaScript. Promises may return a value or payload, or an error message. Each promise has a state. A promise can take three different states. fufilled, rejected, and pending. In the code below process will not execute until fetch executes. And handleErrors will not execute until save has executed. .catch will handle erros within process() and save().

fetch(url)
.then(process)
.then(save)
.catch(handleErrors)
;

Axios, and promises in general are important pieces of software development today. When using the microservice architecture. Sending and receiving data is an essential function of each service. And Axios and promsies help developers do just that. Axios and promises work asynchronously meaning that they can run different parts of the program simultaneously. This is another important concept because sometimes differrent parts of a web page load asynchronously. So an asynchronous method could render the first available piece of data.

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

Blog post 7 –DRY and YAGNI

DRY and YAGNI are two acronyms used to describe best practices when it comes to coding. DRY stands for “Don’t Repeat Yourself” while YAGNI stands for “You Ain’t Gonna Need It”. These two acronyms or best practices complement each other very well. They both aim to make code cleaner, simpler, and free of coding smells such as needless complexity and needless repetitions. These are coding smells that every developer should avoid. So, what do they actually mean?

DRY or “Don’t Repeat Yourself”, is a best practice revolving around repetition in code. When it comes to code, quality is always better than quantity. Why have hundreds of lines of code when you could have a dozen lines that do the same thing? Having duplicated code or duplicated logic is a waste. Not only will you waste time and effort, in the beginning, adding the unnecessary code, but you will also waste further time and effort maintaining and extending the code in the future. Repetition in code can be caused by a variety of reasons mostly from either poor programming habits, like copy and pasting code without really understanding how it works, or from a poor understanding of coding knowledge in general, but specifically, a poor understanding of encapsulation. Regardless of the cause, needless repetition should be avoided as much as possible and repetitive code should be eliminated by refactoring wherever possible.

YAGNI is an acronym that stands for “You Ain’t Gonna Need It”. YAGNI is a coding best practice that stems from the principles of Extreme Programming or XP. YAGNI revolves around the idea of avoiding the writing of unnecessary code that is based on foresight rather than need. Martin Fowler describes YAGNI as “a statement that some capability we presume our software needs in the future should not be built now because “you aren’t gonna need it”. In other words, software developers should always implement features when they need them and never when they just foresee the need for them. There are several reasons why YAGNI exists. One very good reason is that it maximizes the amount of unnecessary work that is left undone. This is excellent because it improves the productivity of software developers, and it maintains the simplicity of products. Simplicity is especially important because implementing new features is quite expensive. It takes a significant amount of time, money, and resources to add the features and to maintain them. Features that are not necessary can be very costly. To avoid wasting resources on unnecessary features, apply the YAGNI principle and don’t implement features unless you need them now.

https://deviq.com/principles/yagni

https://deviq.com/principles/dont-repeat-yourself

https://martinfowler.com/bliki/Yagni.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.

GRASP (General Responsibility Assignment Software Patterns)

GRASP (General Responsibility Assignment Software Patterns) is a design pattern in object-oriented software development used to assign tasks to different code modules.
GRASP provides a way to solve organizational problems and provides a common way to speak about abstract concepts. The design pattern sets responsibilities for objects and classes in object-oriented program design.
GRASP with an object-oriented design identifies its problems and solutions together as patterns.

Patterns of GRASP

Creator
• Who creates an Object? Or who should create a new instance of some class?
• Creator is a GRASP Pattern which helps to determine which class should be responsible for creating a new instance of a class

Information Expert
• Information Expert is a principle used to determine where to delegate responsibilities such as methods, computed fields, and so on.
• Expert principle says that assign those responsibilities to object for which object has the information to fulfill that responsibility.

Low Coupling
• Low coupling is an evaluation pattern that directs how to allocate responsibilities for the following benefits:

lower dependency between the classes,

change in one class having a lower impact on other classes,

Great ability to reuse.

Controller
• Deals with how to transfer request from the UI layer objects to domain layer objects.
• A controller object is a non-user interface object responsible for receiving or handling a system event.
• We can make an object as Controller, if

Object represents the overall system (facade controller)

Object represent a use case, handling a sequence of operations

High Cohesion
• High cohesion is an evaluation pattern that seeks to keep objects focused, manageable and understandable.
• High cohesion is generally used in support of low coupling.
• Benefits
– Easy to understand and maintain
– Code reuse
– Low coupling

Indirection
• Indirection pattern supports low coupling and reuses potential between two elements by assigning the mediation role between them to an intermediate object.
• Benefits: Low coupling, e.g. Facade, Adapter, Obserever.

Polymorphism
• According to the polymorphism principle, responsibility for defining the variation of behaviors according to the type is assigned to the type for which this variation happens.
• Benefits: Handling new variations will become easy.

Protected Variations
• Protected variations pattern protects elements against the diversity of other elements (objects, systems, sub-systems) by wrapping the focus of instability with an interface and using polymorphism to create a variety of implementations for this interface.
• Provides flexibility and protection from variations.

Pure Fabrication
• Pure fabrication is a class that does not represent concepts in the problem domain, specifically designed to achieve low coupling, high cohesion, and possible reuse arising (when the solution presented by the information expert pattern does not work).
• Benefits:
 High cohesion,
 low coupling
 And can reuse this class.

REFERENCE

  1. http://www.kamilgrzybek.com/design/grasp-explained/
  2. https://home.cs.colorado.edu/~kena/classes/5448/f12/presentation-materials/rao.pdf

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

Architectural patterns

Architectural Patterns.

These architecture patterns are a reusable solution to a commonly occurring problem within the field of software design. Software architecture patterns are a description or template for the structural organization or scheme for how to solve a problem that can be used in many different situations.

  1. Layered pattern

This pattern can be used to structure programs that can be divided into groups of subtasks, each of which is at a particular level of abstraction. Each layer provides services to the next higher layer.

Layers of a general information system:

  • Presentation layer 
  • Application layer 
  • Business logic layer
  • Data access layer 

Usage

  • General desktop applications.
  • E commerce web applications.

2. Client-server pattern

Consists of two parties; server and multiple clients. The server component will provide services to multiple client components. Clients request services from the server and the server provides relevant services to those clients.

Usage

  • Online applications such as email, document sharing and banking

4. Pipe-filter pattern

This can be used to structure systems which produce and process a stream of data. Each processing step is enclosed within a filter component. Data to be processed is passed through pipes.

Usage

  • Compilers. The consecutive filters perform lexical analysis, parsing, semantic analysis, and code generation.
  • Workflows in bioinformatics.

5. Broker pattern

It’s used to structure distributed systems with decoupled components. These components can interact with each other by remote service invocations.

Usage

6. Peer-to-peer pattern

In this pattern, individual components are known as peers. Peers may function both as a client, requesting services from other peers, and as a server, providing services to other peers.

Usage

7. Event-bus pattern

This pattern primarily deals with events and has 4 major components; event source, event listener, channel and event bus. Sources publish messages to particular channels on an event bus. Listeners subscribe to particular channels. Listeners are notified of messages that are published to a channel to which they have subscribed before.

Usage

  • Android development
  • Notification services

9. Blackboard pattern

This pattern is useful for problems for which no deterministic solution strategies are known. The blackboard pattern consists of 3 main components.

  • blackboard — a structured global memory containing objects from the solution space
  • knowledge source — specialized modules with their own representation
  • Control component — selects, configures and executes modules.

Usage

  • Speech recognition
  • Vehicle identification and tracking
  • Protein structure identification
  • Sonar signals interpretation.

10. Interpreter pattern

This pattern is used for designing a component that interprets programs written in a dedicated language. It mainly specifies how to evaluate lines of programs, known as sentences or expressions written in a particular language.

Usage

  • Database query languages such as SQL.
  • Languages used to describe communication protocols.

REFERENCE

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