CRUD operations are the four basic functions used to manage and interact with data in a CRUD application.
These are:
Create: Adding new data or records. For example, creating a new user profile in a database.
Read: Retrieving or viewing existing data. For instance, viewing a user’s profile details.
Update: Modifying or editing existing data. Updating a user’s email address would fall under this operation.
Delete: Removing data or records. Deleting a user profile permanently removes that data from the system.
These operations are fundamental to database management and are the backbone of most applications that handle data in general. In a CRUD app, these actions allow users to interact with data easily through a user interface, often with forms and buttons.
CRUD apps vs CRUD ops
A CRUD app is a software application that uses the four CRUD operations to interact with data storage and databases. In more technical programming terms, CRUD operations are equivalent to the SQL statements of Insert, Select, Update, and Delete, and to the HTTP methods of Put, Get, Delete.
CRUD apps are used in many industries, including task management, booking systems, and CMS platforms. This guide will show you how the four operations of CRUD are applied. If you want to know more about apps specifically, you might find it more beneficial to check out our CRUD apps blog before reading on — if you haven’t already.
How does the Create operation work?
This is typically the first step in CRUD applications, as it allows users to input new information into a system, such as creating an account, adding an item to an inventory, or submitting a form.
1. User input
In a typical CRUD application, the Create operation starts with a user providing data through a form or other input method. For example, in a contact management app, the user might enter details like name, email, phone number, and address to add a new contact.
The app interface often includes input fields, dropdowns, checkboxes, and other form elements that collect this data.
2. Data validation
Before the data is saved, it usually goes through a validation process. This ensures all necessary fields are completed accurately and meet the app’s requirements.
Validation is in place to check whether a required field is empty, an email is in the correct format, or a username has already been taken. This process prevents incorrect or incomplete data from entering the system, improving data quality and integrity.
3. Data formatting and pre-processing
After validation, the data might be formatted or pre-processed. For instance, names and phone numbers might be capitalised or formatted to a specific pattern.
This step can also involve encrypting sensitive data, like passwords, ensuring information is stored securely.
4. Sending data to the back-end
Once formatted, the data is sent from the front-end (the user interface) to the back-end server, which handles the storage process.
This usually involves an API request if the front-end and back-end are separate. For example, a REST API request might send the data to an endpoint designed for creating records.
5. Database interaction
When the back-end receives the data, it interacts with the database to store it. This could involve an SQL INSERT command for relational databases, adding a new table row.
For example, an SQL command to create a new user might look like:
INSERT INTO Users (name, email, phone) VALUES ('John Doe', 'john.doe@example.com', '123-456-7890');
The process would vary in NoSQL databases, but would also involve saving a new entry in a specific format, like JSON.
6. Generating an ID or primary key
When the data is saved, the database usually assigns a unique identifier (primary key) to the new record. This ID allows the system to easily retrieve, update, or delete this specific entry in the future.
Some databases automatically generate this ID. In other cases, it may be manually specified or generated using code.
7. Confirming and returning a response
Once the data is successfully stored, the back-end often returns a confirmation response. This might include the unique ID of the new record, along with a success message.
For instance, after creating a new user, the back-end might return a response indicating the user ID and confirmation that the user has been successfully created.
8. Front-end feedback
The front-end receives this confirmation and may display a success message to the user, like “User profile created successfully.”
In some apps, the front-end may immediately refresh to show the new data entry or redirect the user to a new page.
Example of a Create operation in a no-code platform
In a no-code platform, creating data often involves configuring a form to submit the necessary information to a database.
You’d typically add a drag-and-drop form to the page, set fields like name and email and configure an action for the “submit” button. Behind the scenes, the no-code platform handles data validation, API requests, and database storage.
How does the Read operation work?
Read operations are fundamental to any application presenting data, such as viewing user profiles, browsing product catalogues, or reading blog posts.
1. User request
The Read operation is usually triggered by a user action, like clicking a link to view details or loading a page that displays a list of records.
In a contact management app, for instance, a user might click on a contact's name to view their details. Or, on an initial page load, the app might automatically request a list of all contacts to display.
2. API request
For many applications, particularly web or mobile apps, the Read operation involves a request to a back-end server via an API.
The API request might include parameters specifying which data to retrieve, such as a specific contact ID or filters for which items to include.
In RESTful APIs, this Read request is often a GET request. For example:
GET /contacts/123
would retrieve the contact with the ID 123 while:
GET /contacts?city=NewYork
could retrieve all contacts from New York.
3. Database query
When the back-end receives the request, it interacts with the database to retrieve the required information (much in the same way as described for the Create operation).
For relational databases, the Read operation involves an SQL SELECT query to fetch specific records. For example:
SELECT * FROM Contacts WHERE id = 123;
would retrieve all data for the contact with ID 123.
In NoSQL databases, a query might fetch a specific document (record/object) or filter based on particular fields.
The query can retrieve data in different formats (i.e. a single item or a list), depending on what the user needs to view.
4. Data filtering and sorting
For example, if a user wants to view contacts sorted by last name, the query might include an ORDER BY clause in SQL.
Filters are applied here, such as showing active users or items within a certain price range. This ensures the user only sees relevant data.
5. Data transformation (optional)
Once data is retrieved from the database, it may be transformed before being returned to the front-end. This could involve converting timestamps into readable date formats, grouping related data, or aggregating information (like displaying a total count).
Transformation presents data in a format that’s user-friendly and easy for the front-end interface to handle.
6. Sending data to the front-end
After processing the data, the back-end sends a response to the front-end. This data is typically in JSON format for web applications, allowing it to be structured in a way that’s easy for the app to handle.
The response includes the requested data and may include metadata (such as the number of records found), which can be useful for pagination or navigation in large datasets.
7. Displaying data in the user interface
The front-end receives the data and displays it to the user. This could mean showing a single item on a detailed view page or a list of items in a table or grid.
The user interface may format the data further. For example, currency fields might be displayed with a currency symbol, or dates might be shown in a specific regional format.
In apps with search and filtering options, the front-end can update the displayed data in real-time as the user applies different filters or changes sorting options.
Example of a Read operation in a no-code platform
In a no-code platform, the Read operation is often configured through data binding options, where you can select which data source to display on a page. For example, you might drag a “List” component onto a page and connect it to a specific data table like “Contacts.”
The no-code tool will handle the API calls and display logic behind the scenes, so you don’t have to write the code. Some platforms might also let you add filtering and sorting conditions directly within the interface to show certain records or apply specific orders.
How does the Update operation work?
This could mean editing a user profile, updating inventory quantities, or changing an order status. Update operations ensure the data remains accurate and relevant, adapting as information changes.
1. User input for updating data
As with Create and Read, the Update process starts with a user action, such as editing an object or record. For example, in a profile management app, users might click an “Edit Profile” button to modify their name, email, or phone number.
The application often displays the current data in an editable form in the user interface, allowing the user to make changes directly to the fields.
2. Front-end data validation
Before sending the updated data to the back-end, the application often performs validation to ensure the changes are valid.
For example, it might check that required fields aren’t left blank, dates are valid, or that email addresses are in the correct format. This validation step prevents errors from entering the system and maintains data quality.
3. Sending an update request to the back-end
Once validated, the updated data is sent from the front-end to the back-end via an API request, typically using an HTTP PUT or PATCH request in RESTful APIs. The endpoint and request body contain information specifying which record to update and what changes to make.
For instance, if a user updates their email address, the API request might look like:
PUT /users/123
with a request body that includes the updated data:
{
"email": "new.email@example.com"
}
4. Identifying the record to update
The back-end uses a unique identifier (like a user ID) provided in the request to locate the correct record.
This identifier ensures the update is applied to the right record. In SQL databases, this often means targeting a specific row using a WHERE clause:
UPDATE Users
SET email = 'new.email@example.com'
WHERE id = 123;
5. Updating the database
The back-end processes the update request by modifying the specified fields in the database.
This involves an SQL UPDATE statement to alter specific columns in a table for relational databases. NoSQL databases might involve updating a field within a document. Some databases also allow partial updates (modifying only the fields that changed), while others require resaving the entire record.
6. Data validation in the back-end (optional)
Depending on the application, additional validation may occur on the back-end to ensure the updated data adheres to any business rules or data integrity constraints.
For example, a back-end might check that a username is still unique across the entire system, even if it passed validation on the front-end.
7. Saving the changes and confirming the update
Once the data is updated successfully, the back-end usually sends a confirmation response back to the front-end.
Like the Read operation, this response can include a success message or the updated data, which the front-end can use to refresh the display without needing a full page reload.
8. Updating the user interface
After receiving the back-end confirmation, the front-end often updates the interface to reflect the new data.
For example, if users update their profile information, the front-end might immediately show the new details in the profile view.
This feedback confirms that changes were successfully applied, enhancing the user experience.
Example of an update operation in a no-code platform
In a no-code platform, the Update operation is usually set up by adding an “Edit” button and a form where users can modify data.
Once the user submits the form, the no-code platform sends the update request to the back-end, validates the response, and updates the display.
Some no-code tools allow conditional logic, so the UI can change based on the response, like displaying a “Changes saved” message.
How does the Delete operation work?
The Delete operation is crucial for managing data, especially to keep the database organised and to remove sensitive or irrelevant information correctly.
1. User action to delete data
For instance, in a to-do list app, users might click a “Delete” button next to a completed task they no longer need.
Applications often include a confirmation prompt (e.g., “Are you sure you want to delete this item?”) to prevent accidental deletion, as this action is typically irreversible.
2. Sending a delete request to the back-end
Once confirmed, the application requests the backend to delete the specified data. In RESTful APIs, this usually involves an HTTP DELETE request.
The request will specify which item to delete by including a unique identifier, such as an ID. For example:
DELETE /tasks/456
where 456 is the ID of the task to be deleted.
3. Identifying the record to delete
The back-end receives the delete request and uses the provided identifier (e.g. the ID) to locate the exact record in the database.
For relational databases, this involves a WHERE clause in the SQL DELETE command to ensure only the specific item is removed. For example:
DELETE FROM Tasks WHERE id = 456;
In NoSQL databases, it might mean deleting a document or item with the matching identifier within a collection.
4. Soft Delete vs Hard Delete
Soft Delete: Instead of completely removing the record, a soft delete marks it as deleted (e.g. setting a “deleted” field to true). This allows the data to be “undeleted” or restored later and is useful in applications that require record-keeping or have data recovery needs.
Hard Delete: This permanently removes the record from the database, freeing up storage space and ensuring data can’t be retrieved.
The application might use soft delete for records that could be needed (like customer records) and hard delete for records that won’t (like temporary files).
5. Executing the deletion
For Hard Deletes, the back-end executes the deletion command, which removes the specified data from the database. In cases where cascading deletes are used, related data (like records in other tables with foreign critical dependencies) might also be deleted automatically.
For Soft Deletes, the back-end simply updates a field in the record to indicate it’s deleted without removing it entirely.
6. Confirming deletion and sending a response
After the record is deleted, the back-end typically returns a response confirming the deletion. This response is returned to the front-end, indicating the operation was successful.
The response may include a success message or the identifier of the deleted item, which the front-end can use to update the user interface.
7. Updating the user interface
Once the front-end receives the deletion confirmation, it removes the deleted item from the view to provide immediate feedback to the user.
For instance, in a task management app, the deleted task might disappear from the list. This visual feedback reassures the user that the item was successfully deleted.
Example of a Delete operation in a no-code platform
In a no-code platform, the Delete operation is often configured by adding a “Delete” button next to each item in a list or form.
You can set up this button to trigger a delete action, automatically requesting the back-end to delete the specified record.
The no-code platform usually handles API requests, data updates, and user interface changes, making the process seamless without requiring custom coding.
Perform CRUD ops with no coding expertise
Although the principles of CRUD are easy to understand, and the level of technical expertise required is often low, the no-code world opens many doors for experienced and non-experienced coders to create high-functioning CRUD apps.
The Starhive ultimate guide to no-code development is the perfect place to explore how these principles can be applied across a range of use cases. Explore the many benefits and intricacies of the practice in this comprehensive, free download and advance your knowledge on all things no-code.
Get your copy today and see where it takes you.
