DEV Community: Franklin Holguin

Decentralized Applications (dApps): Definition, Uses, Pros and Cons

Franklin Holguin — Mon, 08 May 2023 19:24:58 +0000

By JAKE FRANKENFIELD
Reviewed by JEFREDA R. BROWN
Fact checked by MICHAEL LOGAN

What Are Decentralized Applications (dApps)?
Decentralized applications, or dApps, are software programs that run on a blockchain or peer-to-peer (P2P) network of computers instead of on a single computer. DApps (also called "dapps") are thus outside the purview and control of a single authority.

DApps are often built on the Ethereum platform. They have been developed for a variety of purposes including gaming, finance, and social media.

KEY TAKEAWAYS
Decentralized applications—also known as "dApps" or "dapps"—are digital applications that run on a blockchain network of computers instead of relying on a single computer.
dApps are free from the control and interference of a single authority.
The benefits of dApps include the safeguarding of user privacy, the lack of censorship, and the flexibility of development.
Potential drawbacks include an inability to scale, challenges in developing a user interface, and difficulties in making code modifications.
Understanding Decentralized Applications (dApps)
A web app such as Uber or Twitter runs on a computer system that is owned and operated by a company that has authority over the app and its workings. No matter how many users there are, the backend is controlled by the company.

DApps can run on a P2P network or a blockchain network. For example, BitTorrent, Tor, and Popcorn Time are applications that run on computers that are part of a P2P network, which allows multiple participants to consume content, feed, or seed content.

dApps run on a blockchain network in a public, open-source, decentralized environment and are free from control and interference by any single authority. For example, a developer can create a Twitter-like dApp and put it on a blockchain where any user can publish messages. Once posted, no one—not even the app creators—can delete the messages.

dApp Uses
dApps have been developed to decentralize a range of functions and applications and eliminate intermediaries. Examples include self-executing financial contracts, multi-user games, and social media platforms.

DApps have also been developed to enable secure, blockchain-based voting and governance. DApps can even be integrated into web browsers to function as plugins that help serve ads, track user behavior, or solicit crypto donations.

Some examples of practical uses for dApps include:

Financial services: dApps can be used to facilitate peer-to-peer financial transactions, such as the exchange of currencies or the transfer of assets.
Supply chain management: dApps can be used to track the movement of goods through a supply chain, ensuring transparency and accountability.
Identity verification: dApps can be used to securely store and verify identity information, such as for voter rolls or passport applications.
Real estate: dApps can be used to facilitate the buying and selling of real estate directly between buyer and seller, as well as the tracking of property ownership and related documentation such as deeds.
Healthcare: dApps can be used to store and track healthcare records, as well as to facilitate the communication and collaboration of healthcare professionals.
Education: dApps can be used to create decentralized learning platforms, allowing students and teachers to interact and collaborate directly without the need for intermediaries.
Social media: dApps can be used to create decentralized social media platforms, allowing users to interact and share content without the need for a central authority.
Predictive markets: dApps can be used to create decentralized platforms for predictive markets, allowing users to make predictions on a variety of topics and potentially earn rewards for accurate predictions.
dApp Scams
Scams have been perpetrated through dApps. Ponzi schemes, in which early investors are paid using the investments of more recent investors to create the appearance of big profits, have been known to occur on dApps.

Fake initial coin offerings (ICOs) have been used to raise funds for the development of a new cryptocurrency or dApp that the fundraisers have no intention of creating.

Phishing attacks, which use fake websites or emails to trick people into revealing sensitive information, have been seen on dApps.

In addition, some dApps have been used to distribute malware or viruses, which can compromise users' devices and steal sensitive information.

It is important for users to be cautious and do their due diligence when interacting with dApps, as the decentralized nature of these applications can make it difficult to track or hold perpetrators accountable.

Industry analytics group DappRadar found that there were a record 312 hacks and vulnerabilities affecting dApps in 2022, leading to losses of around $48 billion.
1

Advantages and Disadvantages of dApps
Advantages
Many of the advantages of dApps center around the program's ability to safeguard user privacy. With decentralized apps, users do not need to submit their personal information to use the function the app provides. DApps use smart contracts to complete the transaction between two anonymous parties without the need to rely on a central authority.

Free speech proponents point out that dApps can be developed as alternative social media platforms. A decentralized social media platform is resistant to censorship because no single participant on the blockchain can delete or block messages.

Ethereum is a flexible platform for creating new dApps, providing the infrastructure needed for developers to focus their efforts on finding innovative uses for digital applications. This could enable the rapid deployment of dApps in a number of industries including banking and finance, gaming, social media, and online shopping.

American cryptographer and computer scientist Nick Szabo introduced the term "smart contract" in 1996 as a graduate student at the University of Washington.
2

Disadvantages
The use of dApps is still in the early stages, and thus it is experimental and prone to certain problems and unknowns. There are questions as to whether the applications will be able to scale effectively. There are concerns that an app that requires significant computations will overload a network, causing network congestion.

The ability to develop a user-friendly interface is another concern. Most users of apps developed by traditional centralized institutions have an ease-of-use expectation that encourages them to use and interact with the app. Getting people to transition to dApps will require developers to create an end-user experience and level of performance that rivals popular and established programs.

The challenge of doing code modifications is another limitation of dApps. Once deployed, a dApp is likely to need ongoing changes to make enhancements or correct bugs or security risks. According to Ethereum, it can be challenging for developers to make needed updates to dApps because the data and code published to the blockchain are hard to modify.
3

Pros
Promotes user privacy

Resists censorship

Flexible platform enables dApp development

Cons
Experimental, may not be able to scale

Challenges in developing a user-friendly interface

Difficult to make needed code modifications

Frequently Asked Questions
What Are Ethereum dApps?
These are decentralized applications that are developed using the Ethereum platform and are powered by it. Ethereum dApps use smart contracts for their logic. They are deployed on the Ethereum network and use the platform's blockchain for data storage.

What Is the Difference Between a Centralized and Decentralized App?
A centralized app has a single owner. The application software for a centralized app resides on one or more servers controlled by the owner. As a user, you'll interact with the app by downloading a copy of the app and then sending and receiving data back and forth from the company's server.

A decentralized app (also known as a dApp or dapp) operates on a blockchain or peer-to-peer network of computers. Users engage in transactions directly with one another rather than relying on a central authority. The user of a dApp will pay the developer an amount of cryptocurrency to download and use the program's source code. The source code is known as a smart contract, which allows users to complete transactions without revealing personal information.

What Are Examples of Centralized and Decentralized Apps?
Well-known examples of centralized apps include Twitter, Facebook, Instagram, and Netflix. Banks and other financial institutions use centralized apps to give their customers online access to their accounts.

Peepeth, a social network alternative to Twitter, is an example of a decentralized app. Cryptokitties is a dApp game that allows users to buy and sell virtual cats. MakerDAO is a decentralized credit service supporting the stablecoin Dai that allows users to open a collateralized debt position (CDP).

The Bottom Line
Decentralized applications (dApps) are digital applications or programs that run on a decentralized network, rather than a single computer or server. They are built on blockchain technology and use cryptocurrency as a means of exchange. dApps are designed to be open-source, transparent, and resistant to censorship, allowing users to interact directly with the application without intermediaries. They have the potential to disrupt traditional industries by allowing for peer-to-peer interactions and transactions without a central authority.

RESTful API

Franklin Holguin — Sun, 07 May 2023 07:41:23 +0000

RESTful API is an interface that two computer systems use to exchange information securely over the internet. Most business applications have to communicate with other internal and third-party applications to perform various tasks. For example, to generate monthly payslips, your internal accounts system has to share data with your customer's banking system to automate invoicing and communicate with an internal timesheet application. RESTful APIs support this information exchange because they follow secure, reliable, and efficient software communication standards.

What is an API?
An application programming interface (API) defines the rules that you must follow to communicate with other software systems. Developers expose or create APIs so that other applications can communicate with their applications programmatically. For example, the timesheet application exposes an API that asks for an employee's full name and a range of dates. When it receives this information, it internally processes the employee's timesheet and returns the number of hours worked in that date range.

You can think of a web API as a gateway between clients and resources on the web.

Clients
Clients are users who want to access information from the web. The client can be a person or a software system that uses the API. For example, developers can write programs that access weather data from a weather system. Or you can access the same data from your browser when you visit the weather website directly.

Resources
Resources are the information that different applications provide to their clients. Resources can be images, videos, text, numbers, or any type of data. The machine that gives the resource to the client is also called the server. Organizations use APIs to share resources and provide web services while maintaining security, control, and authentication. In addition, APIs help them to determine which clients get access to specific internal resources.

What is REST?
Representational State Transfer (REST) is a software architecture that imposes conditions on how an API should work. REST was initially created as a guideline to manage communication on a complex network like the internet. You can use REST-based architecture to support high-performing and reliable communication at scale. You can easily implement and modify it, bringing visibility and cross-platform portability to any API system.

API developers can design APIs using several different architectures. APIs that follow the REST architectural style are called REST APIs. Web services that implement REST architecture are called RESTful web services. The term RESTful API generally refers to RESTful web APIs. However, you can use the terms REST API and RESTful API interchangeably.

The following are some of the principles of the REST architectural style:

Uniform interface
The uniform interface is fundamental to the design of any RESTful webservice. It indicates that the server transfers information in a standard format. The formatted resource is called a representation in REST. This format can be different from the internal representation of the resource on the server application. For example, the server can store data as text but send it in an HTML representation format.

Uniform interface imposes four architectural constraints:

Requests should identify resources. They do so by using a uniform resource identifier.
Clients have enough information in the resource representation to modify or delete the resource if they want to. The server meets this condition by sending metadata that describes the resource further.
Clients receive information about how to process the representation further. The server achieves this by sending self-descriptive messages that contain metadata about how the client can best use them.
Clients receive information about all other related resources they need to complete a task. The server achieves this by sending hyperlinks in the representation so that clients can dynamically discover more resources.
Statelessness
In REST architecture, statelessness refers to a communication method in which the server completes every client request independently of all previous requests. Clients can request resources in any order, and every request is stateless or isolated from other requests. This REST API design constraint implies that the server can completely understand and fulfill the request every time.

Layered system
In a layered system architecture, the client can connect to other authorized intermediaries between the client and server, and it will still receive responses from the server. Servers can also pass on requests to other servers. You can design your RESTful web service to run on several servers with multiple layers such as security, application, and business logic, working together to fulfill client requests. These layers remain invisible to the client.

Cacheability
RESTful web services support caching, which is the process of storing some responses on the client or on an intermediary to improve server response time. For example, suppose that you visit a website that has common header and footer images on every page. Every time you visit a new website page, the server must resend the same images. To avoid this, the client caches or stores these images after the first response and then uses the images directly from the cache. RESTful web services control caching by using API responses that define themselves as cacheable or noncacheable.

Code on demand
In REST architectural style, servers can temporarily extend or customize client functionality by transferring software programming code to the client. For example, when you fill a registration form on any website, your browser immediately highlights any mistakes you make, such as incorrect phone numbers. It can do this because of the code sent by the server.

What are the benefits of RESTful APIs?
RESTful APIs include the following benefits:

Scalability
Systems that implement REST APIs can scale efficiently because REST optimizes client-server interactions. Statelessness removes server load because the server does not have to retain past client request information. Well-managed caching partially or completely eliminates some client-server interactions. All these features support scalability without causing communication bottlenecks that reduce performance.

Flexibility
RESTful web services support total client-server separation. They simplify and decouple various server components so that each part can evolve independently. Platform or technology changes at the server application do not affect the client application. The ability to layer application functions increases flexibility even further. For example, developers can make changes to the database layer without rewriting the application logic.

Independence
REST APIs are independent of the technology used. You can write both client and server applications in various programming languages without affecting the API design. You can also change the underlying technology on either side without affecting the communication.

How do RESTful APIs work?
The basic function of a RESTful API is the same as browsing the internet. The client contacts the server by using the API when it requires a resource. API developers explain how the client should use the REST API in the server application API documentation. These are the general steps for any REST API call:

The client sends a request to the server. The client follows the API documentation to format the request in a way that the server understands.
The server authenticates the client and confirms that the client has the right to make that request.
The server receives the request and processes it internally.
The server returns a response to the client. The response contains information that tells the client whether the request was successful. The response also includes any information that the client requested.
The REST API request and response details vary slightly depending on how the API developers design the API.

What does the RESTful API client request contain?
RESTful APIs require requests to contain the following main components:

Unique resource identifier
The server identifies each resource with unique resource identifiers. For REST services, the server typically performs resource identification by using a Uniform Resource Locator (URL). The URL specifies the path to the resource. A URL is similar to the website address that you enter into your browser to visit any webpage. The URL is also called the request endpoint and clearly specifies to the server what the client requires.

Method
Developers often implement RESTful APIs by using the Hypertext Transfer Protocol (HTTP). An HTTP method tells the server what it needs to do to the resource. The following are four common HTTP methods:

GET

Clients use GET to access resources that are located at the specified URL on the server. They can cache GET requests and send parameters in the RESTful API request to instruct the server to filter data before sending.

POST

Clients use POST to send data to the server. They include the data representation with the request. Sending the same POST request multiple times has the side effect of creating the same resource multiple times.

PUT

Clients use PUT to update existing resources on the server. Unlike POST, sending the same PUT request multiple times in a RESTful web service gives the same result.

DELETE

Clients use the DELETE request to remove the resource. A DELETE request can change the server state. However, if the user does not have appropriate authentication, the request fails.

HTTP headers
Request headers are the metadata exchanged between the client and server. For instance, the request header indicates the format of the request and response, provides information about request status, and so on.

Data

REST API requests might include data for the POST, PUT, and other HTTP methods to work successfully.

Parameters

RESTful API requests can include parameters that give the server more details about what needs to be done. The following are some different types of parameters:

Path parameters that specify URL details.
Query parameters that request more information about the resource.
Cookie parameters that authenticate clients quickly.
What are RESTful API authentication methods?
A RESTful web service must authenticate requests before it can send a response. Authentication is the process of verifying an identity. For example, you can prove your identity by showing an ID card or driver's license. Similarly, RESTful service clients must prove their identity to the server to establish trust.

RESTful API has four common authentication methods:

HTTP authentication
HTTP defines some authentication schemes that you can use directly when you are implementing REST API. The following are two of these schemes:

Basic authentication

In basic authentication, the client sends the user name and password in the request header. It encodes them with base64, which is an encoding technique that converts the pair into a set of 64 characters for safe transmission.

Bearer authentication

The term bearer authentication refers to the process of giving access control to the token bearer. The bearer token is typically an encrypted string of characters that the server generates in response to a login request. The client sends the token in the request headers to access resources.

API keys
API keys are another option for REST API authentication. In this approach, the server assigns a unique generated value to a first-time client. Whenever the client tries to access resources, it uses the unique API key to verify itself. API keys are less secure because the client has to transmit the key, which makes it vulnerable to network theft.

OAuth
OAuth combines passwords and tokens for highly secure login access to any system. The server first requests a password and then asks for an additional token to complete the authorization process. It can check the token at any time and also over time with a specific scope and longevity.

What does the RESTful API server response contain?
REST principles require the server response to contain the following main components:

Status line
The status line contains a three-digit status code that communicates request success or failure. For instance, 2XX codes indicate success, but 4XX and 5XX codes indicate errors. 3XX codes indicate URL redirection.

The following are some common status codes:

200: Generic success response
201: POST method success response
400: Incorrect request that the server cannot process
404: Resource not found
Message body
The response body contains the resource representation. The server selects an appropriate representation format based on what the request headers contain. Clients can request information in XML or JSON formats, which define how the data is written in plain text. For example, if the client requests the name and age of a person named John, the server returns a JSON representation as follows:

'{"name":"John", "age":30}'

Headers
The response also contains headers or metadata about the response. They give more context about the response and include information such as the server, encoding, date, and content type.

How can AWS help you with RESTful API management?
Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. Using API Gateway, you can create RESTful APIs for real-time two-way communication applications:

Using API Gateway, you can:

Provide users with high-speed performance for both API requests and responses.
Authorize access to your APIs with AWS Identity and Access Management (IAM) and Amazon. Cognito, both of which provide native OAuth support.
Run multiple versions of the same API simultaneously with API Gateway to quickly iterate, test, and release new versions.
Monitor performance metrics and information about API calls, data latency, and error rates from the API Gateway.
Get started with API Gateway by using our step-by-step guidance and creating an AWS account today.

Employee Management System -Project for Practice

Franklin Holguin — Tue, 18 Apr 2023 02:58:57 +0000

Project Description

In the last few weeks i being working in a interesting project the i found, just for put in practice my abilities programing in Java and using Spring Framework (first time using it).

Was to much, finally is in my GitHub you can and bring me your comment. this project is not 100% my but it take all my time.

Areas of improvement for future

I think. this project can be great for a full and functional HR department for all the function that you can add in the future like:

Employee working hours calculations
Full Payroll function
Accessibilities between departments

GitHub link