Mastering Data Modeling with Liferay Objects

Course Overview

Accessing and Managing Related Data

After defining an object relationship, you can use it to link entries, creating meaningful connections within your data models. Then, once you've related entries, you can access, manage, and display related data in various ways. For example, you can design custom object layouts that include relationship fields and tables. Alternatively, you can use Liferay’s page builder features to create engaging user interfaces that include related data. For more advanced use cases, you can also use headless APIs to access related data with external services, including client extensions.

While Module 5 delves deeper into each of these methods, this article provides a foundational overview of layouts and relationship APIs.

Using Layouts with Relationships

Object layouts provide a basic, utilitarian UI for creating and editing entries. These layouts are best suited for testing and administration purposes, where user experience and site integration aren’t priorities. Though Liferay automatically generates a basic layout for each object, this layout only includes relationship fields and does not include relationship tables. To display relationship tables, you must create a custom layout that includes a relationship tab.

Object layouts provide a basic, utilitarian UI for creating and editing entries.

Once implemented, users can access the relationship table in the newly created tab when editing object entries. Here, users can select from existing object entries, or create new ones in the related object.

Users can access relationship tables.

Liferay's headless APIs offer robust mechanisms for accessing and managing related object data programmatically. This includes supporting parameters for retrieving nested data and generating dedicated endpoints for relationship tables.

Using Relationship Endpoints

When you add relationships to objects, Liferay generates REST endpoints for accessing the relationship tables. With these endpoints, you can

  • Relate and disassociate entries.

  • Retrieve an entry's related entries.

Relationship endpoints are included in the parent object for one-to-many relationships and in both objects for many-to-many relationships. Though, if the object has a many-to-many relationship with itself, Liferay only generates relationship endpoints for the parent side.

Liferay generates these relationship endpoints:

  • GET /{objectEntryId}/relationshipName: Returns a list of all entries related to the specified object entry using the relationship.

  • PUT /{objectEntryId-1}/relationshipName/{ObjectEntryId-2}: Relates the first object entry with the second object entry.

  • DELETE /{objectEntryId-1}/relationshipName/{objectEntryId-2}: Disassociates the first object entry from the second object entry.

When you add relationships to objects, Liferay generates REST endpoints for accessing the relationship tables.

Besides relationship endpoints, Liferay provides the nestedFields parameter, which you can use to return multiple levels of related object entries in a single GET request. When using nestedFields, you enter the names of the relationships you want to include, separating each relationship with a comma (e.g., nestedFields=[firstObjectRelationship],[secondObjectRelationship]). If the relationships span multiple levels, set the nestedFieldsDepth parameter to the depth you need. You can include up to five levels (e.g., nestedFieldsDepth=5).

When working with Liferay Objects and relationships, deciding how to retrieve related data is crucial for performance and usability. Depending on your use case, both relationship endpoints and nested fields can provide distinct advantages and disadvantages. Before committing to a strategy, carefully consider the following pros and cons of each approach.

Relationship Endpoints

When using relationship endpoints to query related entries, a single API call retrieves a list of all entries related to the current entry using the specified relationship. This focused scope provides these benefits:

  • Granular Control: Minimize unnecessary data fetching by retrieving only the data you need.

  • Reduced Payload Size: When loading data in response to user interactions, keep API responses lean and reduce network load.

  • Lower Initial Database Load: Fetch fewer relationships to simplify and focus individual database queries.

However, in some situations you may need more information than what relationship endpoints provide. For example, you might need the primary object as well as related entries from multiple relationships. This requires additional API calls, which can introduce these drawbacks:

  • Increased Latency: Multiple API calls can increase latency due to network round-trips, potentially slowing performance, especially with many related objects.

  • Increased Overhead: Frequent server communication can increase the number of requests, impacting server and client performance, particularly with many objects.

Nested Fields

When using nestedFields to query related entries, a single API call retrieves the primary object entry and any related entries using the specified relationships, up to the defined nesting depth. This comprehensive approach provides these benefits:

  • Single API Call: Reduce network latency and simplify interactions between the frontend and backend by retrieving all necessary data in a single request.

  • Optimized Rich Data Views: Build optimized, rich data views that include all necessary related information in a single API call. This is ideal for pages that require comprehensive data upfront, such as a detailed ticket view with dependencies, assignees, and related tickets.

  • Enhanced User Experience: Deliver a seamless and responsive user experience by making all related data instantly available without requiring additional clicks or loading screens.

However, this comprehensive approach to data retrieval is not recommended for all use cases. For example, your solution might only require some related data upfront and load additional data via user interactions. In this case, retrieving all information at once can have these drawbacks:

  • Complex Queries: Using nestedFields increases the complexity of the database query. While this is often more performant than multiple API calls, it does put more strain on the database.

  • Payload Bloat: Retrieving too many nested fields can lead to a large payload. This increases the amount of data transferred and may negatively impact page load times if the information isn’t used immediately.

  • Unnecessary Data Fetching: Fetching unnecessary data can decrease efficiency. If you don't need some related data immediately, loading it in advance with the initial API call can be counterproductive.

Warning: Use the nestedFieldsDepth parameter carefully. While it enables you to multiple levels of related data, it can significantly increase database load and result in bloated payloads. To avoid performance issues, limit nestedFieldsDepth to the levels necessary for your specific use case.

Deciding Which Strategy to Use

Both approaches have their place, and the key is understanding the requirements of your application. For scenarios where all data is displayed or used at once, nested fields can save API calls, improving user experience and performance. However, when data is revealed progressively or only upon user interaction, using relationship endpoints and multiple API calls is more efficient and reduces unnecessary data fetching.

Conclusion

Mastering object relationships requires understanding how to access and manage related object entries through the Liferay UI and headless APIs. Next, you’ll implement and test relationships for Clarity’s distributor management app.

  • Using Layouts with Relationships

  • Accessing and Managing Related Data with Headless APIs

  • Headless Strategies for Querying Related Data

  • Conclusion

Loading Knowledge

Capabilities

Product

Education

Contact Us

Connect

Powered by Liferay
© 2024 Liferay Inc. All Rights Reserved • Privacy Policy