Implementation of web systems

This week's blog features content from Geeksforgeeks, a site that features 20000+ Programming Questions, 40,000+ Articles, and interview experiences of top companies such as Google, Amazon, Microsoft, Samsung, Facebook, Adobe, Flipkart, etc
 
Web systems are systems that use internet technologies to deliver information and services. Deliveries might include textual data, multimedia or any other format. There are various ways web systems can be packaged and delivered to users, for instance through websites, web apps and can be embedded into hardware as in internet of things frameworks.
 
For most users, their interaction with web systems is through websites. They are web pages that get served over the internet. A website can either be static or dynamic. Static websites simply deliver data and information and do not perform requests to a backend service. What you see is what you get. On the other hand, dynamic websites will change state based on the user’s interaction with it. Requests are sent to a backend service that returns data and changes the state of the site whereby a user gets to see a different view based on their interaction.
 
Web development can start by building the application from scratch or using a framework that provides a boilerplate (sample code) to start from. There component of web development includes web design, web publishing, web programming, and database management. Frameworks include, AngularJS, ReactJS, VueJS, Laravel etc. There are two sides to bringing a web system to life, the front-end development, and the backend development. Front-end also known as the client side is that part that the user directly interacts with. It could be buttons, lists, cards, or multimedia component. Front-end technologies include HTML, CSS, JavaScript, Bootstrap, JQuery and many more. The challenge associated with front end development is that the tools and techniques used to create the front end of a website change constantly and so the developer needs to constantly be aware of how the field is developing.
 
Backend development is that part of the web system that users cannot see. It receives requests, computes the request, stores (in some cases) and return the result to the front-end to display to the user. It includes writing APIS, creating libraries, and working with system components. Database services and algorithms for instance live on the backend side of a website. Technologies used include NodeJS, PHP, Ruby, Java, Python etc.
 
We’ve used some of these technologies in class and seen their effectiveness and structure. In Thea Food Pantry web system for instance, VueJS is used as well as HML and CSS.
Sources:
1. https://www.geeksforgeeks.org/web-development/
2. https://frontendmasters.com/guides/front-end-handbook/2018/what-is-a-FD.html

REpresentational State Transfer - REST APIS

 For this blog I chose For this blog I chose https://restfulapi.net blog for its well descriptions of terms about Representational State Transfer and how it works. REST was coined by Roy Fielding in 2000. It is an architecture style for designing loosely coupled applications over the network, that is often used in the development of web services.

 

An API (Application Programming Interface) is a set of definitions and protocols for building and integrating application software. It’s the glue between an information provider and information user or a gateway between clients and resources on the web. Clients are users who want to access information from the web, while resources are information that different applications such as backend services provide to their clients. It could be presented in different format such as multimedia, images, videos, text, numbers or any other data type.

 

When a user makes a request via rest api, it transfers a representation of the state of the resource to the requester. The representation comes in several formats via HTTP: JSON (JavaScript Object Notation), HTML, XML, XLT, Python or plain text. JSON is the most common format used due to its well readability by humans.

 

¹Headers and parameters are also important in the HTTP methods of a Restful API HTTP request as they contain important identifier information to the request’s metadata, authorization, uniform resource identifier (URI), caching, cookies etc.

 

²A REST api requires requests to contain components such as Unique resource identifiers, methods, HTTP headers, data and parameters. Some methods include GET, POST, PUT, DELETE. 

GET is used by clients to access resources that are located at a specified URL (Uniform Resource Locator)

POST is used by clients to send data to the server.

PUT is used by clients to update existing resources on the server.

DELETE is used to request to remove resources from the server.

 

HTTP Headers display the http method request or response that passes additional context and metadata about the request or response.

 

Data

Information that is passed into POST, PUT and other HTTP methods

Parameters in a request include path to specify URL, details, information about the resource.

 

³Below are 6 architectural constraints which make any web service a truly restful api:

1.    Uniform interface : 

2.    Client-server : Client applications and server applications much st be able to evolve separately without any dependency on each other.

3.    Stateless : The server will not store anything about the latest HTTP request the client made.

4.    Cacheable : For performance improvement, data can be temporarily be stored on client side

5.    Layered system : Data can be stored on server A, authentication on server B and accessed via server A

6.    Code on demand : Data can be XML or JSON format or executable code to support part of the application

 

Sources

1.    https://aws.amazon.com/what-is/restful-api/ accessed on 12/2/2022

2.    https://aws.amazon.com/what-is/restful-api/ accessed on 12/2/2022

3.    https://restfulapi.net/rest-architectural-constraints/ accessed on 12/2/2022

 

YAGNI (You aren't gonna need it)

For this blog, I chose techtarget’s blog. The definitions are kept simple, concise and easy to understand. YAGNI ( You aren’t gonna need it or You ain’t gonna need it ) is a practice in extreme programming associated with software development which states that features should only be added when required. Most developers including myself have included code that is believed will be needed in the future to perform a specific cool task. It could be a feature collects the user's age so we can determine which age-group is mostly using a piece of software. However, YAGNI teaches against this, developers don’t have to waste time writing source code that is assumed will be needed in future. The extra wasted effort is unnecessary and can hinder or slow the development process.
 
Features are expensive, both to develop and maintain, and for users to learn and navigate around. This could result into delays that may give competitive advantage to rivals.  Features that aren't necessary at the time of production are a huge waste. YAGNI can be compared to the Just-In-Time manufacturing where rather than ordering a bunch of parts based on what you think you might need, you wait for actual customer orders and ensure your process is lean enough that you can pull orders through your supply chain quickly enough to satisfy the customer.
 
On the other side, it may be necessary to think about future features and fashion current features in a way that integration will be seamless. This does not mean shipping those features in the current release.
By avoiding adding features and complexity until it's needed, the overall design of the system can remain simpler and makes it easy for debugging as well. The feature you thought you would need usually turns out that you either didn't need it, or that when you do need it, your understanding of how best to design it will be different than earlier imagined in the project.
 
The YAGNI concept helps avoid spending time on features that won’t actually be used. For instance, in developing a calculator app, the system doesn’t need access to the user’s contacts, location data, or reading emails and showing adverts. These are unnecessary features that make the user interaction with the application undesirable. Most users will simply not use a calculator application that requests for their contacts, location, or bluetooth connection. This renders the application unusable and therefore dead.

Design Smells

I chose alpharithms blog to get definitions as they were well defined and short. After the English and alpharithms' definitions, I add a small example of how the concept are applied in software development. These are classifications of poorly written code making it hard to understand, maintain or modify. They include Rigidity, Fragility, Immobility, Viscosity, Needless complexity, Needless Repetition and Opacity.

Rigidity means to not easily bend. In software that means the code cannot adapt or be open for changes occurring around it. An example, we have an authentication module in our app. Later on we decide to determine the user's online status and display it to other users. This could be a challenge especially if we don't have parameters in the module that capture the exact time the user was authenticated and when they went offline.

Fragility means easily broken or damaged. In software this means a piece of code is delicate such that any slight modification to it could lead to breaking changes elsewhere including areas that have no direct relationship with the change. The programmer is locked between leaving it as it is which could potentially expose the system to vulnerabilities or remove it completely leaving other components broken because they depend on it.

Immobility means unable to move. In software, this means we cannot export this code to other parts of the system. There could be several reasons for that, including being platform specific or requiring a particular version of dependency to be met.

Viscosity, a term associated with flow of liquids. In software development it means the code cannot flow to other parts of the system and often it’s hard to do the right thing when faced with different situations.

Needless complexity. This is an easy trap to fall into especially when copy and pasting code that performs “cool” operation. Let’s say you’re developing a note taking app, you shouldn't need access to user’s GPS location, phone call records, and text messages.

Needless repetition. Instead of repeating source code, we could create shareable components and state management stores that hold data centrally such that it can be availed to other components without rewriting the source code. Repetition sometimes leads to inconsistencies in data especially if the components do not effectively communicate and update each other.

Opacity which means hard to see through. This means the code has arrived at a point where it's hard to understand what's going on due to several modifications. Let's say we build a calculate application that adds two numbers, next we add on computing the logarithms, then we add on computing the squares of multiple numbers. It just keeps on evoving until no one fully understands how to make modificaitons to the code.

Object Oriented Programming

For this week I chose 'The story of object-oriented programming", by medium.com. The blog dives right into the topic by stating that any developer who wants to build a high quality software out to master object-oriented programming concept. I learnt that object-orientation was intended to be closer to the real world and also making it easier. Objects in the real world, could be anything such as a house, car, bike, books etc. Objects have attributes and behaviors, that's how we identify them. Attributes are the properties of a particular object. For instance some attributes of the human race are having a nose, having eyes, having legs and so much more. Behaviors on the other hand are actions that the object performs. It could be displaying a message that is useful to the user, sending and delivering an email when a button is pressed, playing certain theme songs when new levels are reached in a game. Objects do not generate themselves, they come from classes througha process known as instantiation. A class is the home or blueprint where attributes and behaviors live. When an object is made out of a class, it is safe to say that it contains the exact content of that parent class.

In relevance to Software development, there exists four expressions to object oriented programming (OOP) namely, Abstraction, Encapsulation, Polymorphism and Inheritance. Abstraction means hiding the implementation details of a particular class. Basically, data and information that is irrelevant to the user is not presented to him/her.  A commonly used example is  about cars and their technical functionality such as burning oil in the combustion engine. As the car executes its source code, the driver does not need to know what events are happening under the hood in full detail.

Encapsulation means having an another object within another object. Sticking to the car metaphor, we can see the idea of encapsulation in car seats or tires. They (seats or tires) could be of different colors, material and from various manufacturers as long as they meet requirements of a particular car. Combined together, they serve the purpose of a car as whole unit.

From the word 'Poly' meaning 'many', Polymorphism is the ability of an object to be inherited by multiple classes. With polymorphism, it's easier to have consistency in data because child cases are reflecting data that comes from parent classes. Errors and inconsitencies are reduced.

Inheritance is the ability to share attributes with other classes. We do not need to repeat source code to execute a particular task. With inheritance, we can generate other classes that have the same properties and behaviors. For instance, a student and a professor both inherit their properties from the class human. They both have physical attributes and behaviors such as speaking, reading and moving.

Don't Repeat Yourself - DRY

I chose thevaluable.dev's example on Don't Repeat Yourself because it well demonstrates the concept. It talks about a shipment class on an e-commerce platform that's used to ship products to customers. First, it's configured for a single warehouse, but is later required to ship to 76 different warehouses with different details such as location and product amounts. Loops and other repetition logic are not the best as far as efficiency is required in this scenario. The programmer would have to re-write the code to meet the new demands. That is a lot of time wasted that could have been employed to fixing bugs or testing the code. This problem could simply have been fixed by creating a single abstraction capable of taking in different values yet delivering similar desired results without code duplication.

The blog also highlighted that the DRY concept was not only to be used in writing source code but also to anytthing that related to your project. "A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation". Whether it's database interaction to store or retrieve data in different parts of the code, a single component that performs this task should be used instead of copy/paste the source code.

When writing software, it's common to come across situations where the same functionality might be required. It's common to copy and paste the same code to varying locations to achieve the same task. Take an example of a coffee ordering system, the system captures a user's identity, financial data and their desired coffee type then generates an order number. Some customers may require that a receipt of their orders be printed out.

How and where would we get the data to print out on the receipt? There is a high possibility that we copy the code that identifies the user and their desired coffee type and then print it out. This is repetition and possible trap that we might find hard to get out of later. Instead, we could create a single user functionality such that printing a receipt is an option instead of making printing a stand-alone functionality. This way, we can also create other stores that use the same logic and we won't have to worry about making changes that only support one store and not the other.

I hope to use this concept in my future projects to avoid unnecessary repetition and time wastage. Clean code is easy to clean-up, refactor and update.