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.

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.

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.

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.

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.

               Within the modern world of computing, the creation of intuitive front-end systems is essential in the pursuit of user friendliness. Front Ends are what make a program, or website accessible to most people. Databases use front-ends to allow users to search or browse their contents in a format that is easily accessible and usually provides tools related to searching said database. Complex programs can utilize front ends to abstract the complex inner workings of said program and boil them down to a simple screen that guides the user and tells them what to do.

               With this in mind, it is important to consider that a front end must also be clear in its design. A well thought out front end will make it even easier for a user to understand what the front is created to accomplish. Oftentimes these types of jobs are handled by dedicated designers, especially since languages such as CSS, HTML and Javascript, while in a basic sense are similar to writing code in C++, or Java, however they usually have much less depth to them as these front end languages usually serve only to request data from the backend and return a response.

               What we have here then is a classic situation of design philosophies vs engineering philosophies. One seeking to appeal to as many people as possible and the other focusing on functionality first and foremost. Often design and practicality can be at odds with each other as some designs might be impractical or vice versa with some engineering decisions being unappealing. This is where one who works in front-end development can bridge the gap between the two philosophies.

To that end we can look at a website such as Thea Food Pantry which was shown in recent activities pertaining to front end design and implementation. It is a simple program but does its job well while offering a fairly user friendly experience. A list of items and a button with a prompt next to it to allow a user to add items. The page is easy to read but is functionally sound.

               When designing software, there are two goals in mind when a user visits your site. It must be appealing and easy to navigate as well as quick to guide potential customers to a desired product. To be an effective front end designer, it is imperative to understand how to structure the website to be both practical for seamless backend integration and visually appealing to the user in a way that emphasizes what is most important to them. The breadth of knowledge afforded by understanding front end design and implementation gives an important viewpoint for software development and how the average user might view your web application.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Resource Link: https://www.digitalocean.com/community/conceptual_articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design#single-responsibility-principle

For this blog post, I wanted to delve into what the SOLID principles are and how they apply to object oriented programming. SOLID is an acronym for the 5 object oriented design principles. They are the single-responsibility principle, the open-closed principle, the Liskov substitution principle, the interface segregation principle, and the dependency inversion principle. The reason these principles are important, and why they’re important to use is that they help to maintain good coding practices and help to avoid code smells. This is essential in large projects, as code smells and bad design could increase development time, make refactoring harder, and make development harder for teams if other team members couldn’t understand the code.

The first principle of SOLID is the Single-Responsibility Principle. It states that a class should have only one reason to change, and that it should have only one job. This means that a class should only have code related to its function, and not extraneous code that should be elsewhere that’s unrelated to the class’s intended purpose. This helps to keep classes simple and easy to understand. If a class contained logic unrelated to its purpose, then it would make the intended purpose of the class confusing.

The second principle of SOLID is the Open-Closed Principle. It states that a class should be open for extension but closed for modification. This means that a class should be designed in such a way that if a modification to that class is needed, it can instead be extended by a different class, and then that class could be modified while maintain the functionality of the original class. The also helps the make each class have its own specific purpose. If instead of creating a new class, a single class was modified every time a modification was needed, then the class would get messy very fast, making it hard to read and hard to understand its functionality.

Next, the Liskov Substitution principle states that every subclass that extends another class should be substitutable for the parent class. This means that for example, if there was a shape class, and then a square class extended the shape class, then the square class should be able to be used in place of the shape class.

Then, the Interface Segregation Principle states that classes shouldn’t be forced to use an interface which has functionality that it has no use for. This means that if an interface has some functionality that doesn’t apply to everything, then a class shouldn’t use that interface if it won’t be using that functionality. Instead, interfaces should be very broad, making them applicable for many different purposes.

Finally, the Dependency Inversion Principle states that functionality should depend upon abstractions, not concrete methods. This means that if you have a class that must perform some functionality, and it shouldn’t depend on an exact implementation, then the class must be design in such a way that it applies to all implementations, based off abstractions.

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

For this week’s blog post I have found an article on REST API Design. REST or RESTful API design (Representational State Transfer) is designed to use and take advantage of existing protocols. Even though REST API can be used for almost any protocol, normally you will see this design in HTTP web APIs. This design was defined by Dr. Roy Fielding and became notable due to its layer of flexibility. REST can use and execute multiple types of calls, due to the data not being tied to any methods or resources. For your API to be considered “RESTful”, it will need to follow each of the six key constraints. The first thing that it will need is a Client-Server. This is the idea of separating the client and the server from each other and makes it so work can be done independently from each other. For example, I should be able to work on my server without it effecting the mobile client. Secondly your API will need to be stateless. MuleSoft, the company where the article is from, says on stateless API, “REST APIs are stateless, meaning that calls can be made independently of one another, and each call contains all of the data necessary to complete itself successfully. A REST API should not rely on data being stored on the server or sessions to determine what to do with a call, but rather solely rely on the data that is provided in that call itself.” (MuleSoft). For example, I should be able to grab and orders information from an order database by calling its order ID rather than all the information itself due to the APIs design. The third thing that it will need is cache. Cache in computing, is a piece of hardware or software that will store data for future use. For example, an autofill password you would use on Google Chrome. For your API to be truly RESTful it will need to have a way to store cacheable data. This will strongly help your API due to less interaction with it and you will be able to retrieve data quickly for your clients. The fourth thing you will need a Uniform interface. This means having an interface that is not coupled with the API layer. This allows the client to easily navigate the API without knowing the backend. The fifth concept for RESTful API is a layered system. According to MuleSoft, they say on Layered System, “As the name implies, a layered system is a system comprised of layers, with each layer having a specific functionality and responsibility” (MuleSoft). Lastly you will need to be able to code on demand. The concept for this idea is that Code on Demand will allow code or applets to be transmitted via the API. This concept is not widely used due to API being coded in multiple different languages and has been raising security questions.

https://www.mulesoft.com/resources/api/what-is-rest-api-design

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.