As a developer, it is essential to have scalability and easy maintenance in mind when building applications. OutSystems provides several pre-built features to support this, but isolating end-users from core services remains a significant concern.
When designing a project’s architecture, including the database, services, multiple end-users, back-office, and front-office, it is critical to consider how the interfaces communicate with the backend. Typically, services responsible for data management are created, ensuring that data shown to the user and changes in the database are well-structured and flexible to respond to multiple front-ends.
The input and output for those services can be custom structures instead of entity records to avoid many concerns!
Some benefits to using structures
Remove all end-user references from the database!
Yes, it is possible and is a great way to promote changes in database architecture without concerns in multiple front-ends!
You can use structures as input and output types for your service actions/server actions, and avoid references from your database (entities). This way you can apply changes in your entities that will not affect the front end.
Reduce End user dependencies from Core services
OutSystems have been working to improve dependency management, automatize the update references, and in some cases remove those dependencies.
Using structures, you can reduce dependencies, promoting better task management between teams and maintenance for the future.
Easier task management
Nowadays project size and quality requirements promote multiple teams of expertise, this means that someone can be responsible for the front end (end-user) and others for the backend (services).
Using structures will benefit task management, which is a struggle point for managers when planning projects.
Front-end is directly dependent on services (back end) and this way has more independence. The data source can be changed without affecting the front end and sometimes can be created dummy data to reduce this dependency.
We at Hi Interactive can deliver an entire front-end (end-user) without any services available, creating documentation with the structures needed.
Don’t use aggregates on screens
I know this is a common approach and is one of the main concepts that we learn when starting the OutSystems training, but this is a struggle point when you want to scale, reusing code, and maintain multiple applications.
Use service actions to manage data in the server side and return it to the end user by output structures.
Useful tips and tricks
Use Identifiers type as long integer (common id key)
One of the challenges is how to avoid references from identifier attributes, because is a data type created specifically for the entity keys.
We suggest using the same data type as the original attribute, by default it’s common to be a long integer.
Use service actions instead server actions
Service actions are almost the same as server actions in terms of development experience but have available features that promote the right way to create services. The main advantage is service actions have weak dependencies compared to server actions.
OutSystems allow replacing old server actions with service actions only by moving server actions to the service actions folder.
Don’t forget documentation for your structures
Documentation is important for any project but in special in this case, there will be common to have the back-end team create services that will be used by the front-end team.
We recommend giving contextual and understandable names and descriptions to your structures as minimal documentation but also creating support documentation for your services with all input requirements and output information.
Client-side data management
When Facebook decides to create a virtual DOM concept to solve the struggling data management of their interfaces, a new way of managing data was created and adopted by the web development community.
Until that time, almost all data management was done by the server side and this new approach starts reducing the server-side effort and brings it to the client side, improving the experience of the user and creating what we recognized as reactive apps!
OutSystems have already implemented the reactive apps concept in the platform and those that came from the previous versions (traditional) know how this is a great feature and how this improves app development! But we still need to have this Reactive concept in mind and implement it in our app architecture, structures are a great tool for this!
In cases where you need to manage a bunch of data as in long forms, wizards, interactive dashboards, etc, using local variables with structure types will enable you to manage data on the client side and this way improve app performance, reducing server calls and giving instant feedback to the user.
Use master-detail concept
A master detail form reflects a one-to-many relationship between two tables in a database. Typically, a master detail form displays a master row and multiple detail rows. – Wikipedia
If you have experience as a developer you know which is the main challenge when is need to create a master detail form! Managing a form for a single record and at the same time listing records from another table without losing user experience, means many concerns, but structures are there to help us!
Following the Reactive concept we only need to manage all data on the client side and send it to the server side when is really needed, avoiding issues with canceling the operation and improving user experience.
As you can see in the image, we have information from the single record project and an attribute list of records from another table.
This will enable front-end to manage all data and return the same structure with updated data.
