Category: Expert stories
Front-end developer and emagineer Kamil Naja delves into diverse approaches for generating front-end code efficiently. From simplifying HTTP requests to optimizing data mapping and creating reusable payloads, he explores strategies to minimize repetition and enhance productivity.
Kamil Naja, Warsaw
As I wrote in the previous article, front-end code is somewhat repetitive. There is particularly a lot of repetition at the boundary between the back-end and the front-end. Since objects from the database are sent from the back-end, the front-end receives and types them (if we use, for example, TypeScript), for further use.
In this process, there is a need for:
Regardless of the type of framework used, we will want to separate these actions into a separate isolated layer. In the further part of the article, I will call it a service.
This whole process is repeated with each addition of a new endpoint to the application. It takes a long time, is not creative, and requires a lot of attention.
More from this author:
How to optimize your workflow as an IT specialist
This code also needs to be maintained and tested. There is often a need to validate data in the same way in many places. We also want to maintain high consistency, using the same, best solutions everywhere.
All these features indicate that the process of creating this basic front-end layer is worth automating. This way, we can focus on the creative work itself.
Two main ways to generate front-end services and interfaces are doing it in the back-end application or the front-end application. In order to generate them, we first need OpenAPI documentation of the appropriate level of detail. For example, it should include all endpoints and fully capture the complexity of objects. If we use enums on the back-end, they should be represented as enums, not strings. Required fields should also be properly marked.
The key here is the collaboration between the back-end and front-end and understanding why accurate OpenAPI documentation is crucial. If creating it on the back-end takes a lot of time, perhaps it can be automated or better tools can be utilized.
Over time, an ideal collaboration model can be developed. I write a lot about the importance of OpenAPI documentation, but it's truly crucial. Not only because it serves as the generator's only source of truth. If the file contains errors or is imprecise, we will have to analyze and change it until we find the cause. We cannot manually correct something in the generated code; corrections are made indirectly by fixing the source.
Our goal is to enable developers to start working with ready-made services that fetch and send properly typed data.
We cannot manually correct something in the generated code; corrections are made indirectly by fixing the source.
The developer can add additional layers specific to the project, such as facades for data remapping or state for storage. These layers can also be generated by using different tools, which I will describe at the end of the article.
Furthermore, if there is a lot of repetitive logic in the application, we can generate entire views, but this approach usually doesn't work well due to business requirements.
Service generation is also a huge time saver when the application changes. To generate a new API, we simply use the current specification file and generate services based on it. With the right architecture, it's then enough to adjust the code in the intermediate layer between services and component code, without making painstaking changes in every layer.
This solution is mainly used when the application is small, doesn't use many microservices, and uses a single repository for both back-end and front-end. Projects are closely related, and the back-end application generates code in the front-end application's folder.
An example of such a solution can be the NSwag project, which includes TypeScriptClientGenerator for Angular.
Learn more:
TypeScriptClientGenerator
In this setup, the back-end generates both the Swagger specification and services and interfaces for objects transmitted between layers. The advantage of this solution is that the front-end always has the latest version of the generated code.
This approach is more dynamic and allows for work independently of the back-end, especially when working with a mocked server. The only thing we need to work is an OpenAPI (Swagger) file. Creating services can be triggered as another command in the front-end repository.
An example of a proven project of this type are:
The application creates a folder containing the generated code, and for each OpenAPI/Swagger file, a separate folder is created containing:
These two twin projects also perform simple data validation, helping to avoid calling methods in a way that could lead to application failure.
A good configuration solution would be to skip generating unused models.
In this article, I treat AI somewhat neglectfully. The problem I presented at the beginning has already been well solved in both the back-end and front-end layers. Generating services and interfaces doesn't require creativity, and what's more, we want to achieve consistent results here, the same every time.
For this reason, I don't use AI to generate these structures, but it's not excluded that in the future, such code will be even easier to generate. AI will certainly help, for example, in quickly creating configurations or introducing how to use a particular generator.
In general, anywhere there is repetitiveness. Examples include NGRX code or repetitive structures in the user interface. It's important to choose the right tool for the specific problem. In the case of an Angular application, automation can be achieved using Angular Schematics.
For instance, Yeoman is a solution with a much broader application. It includes both built-in generators and allows the creation of custom ones. The advantage of Yeoman is that it is an ecosystem of generators and greatly simplifies their creation. Additionally, creating code for Yeoman is a good task for AI.
Learn more:
Yeoman
We can also ask AI to transform existing application code into Yeoman templates and write unit tests for them. AI can be useful for generating ad hoc code, simplifying tasks during ongoing work.
In the network, you can find smaller generator projects for various specific applications.
To summarize, let's try to make our work easier and avoid writing things that are boring and repetitive. In a project with accurate OpenAPI documentation, transitioning to API generation will be quick and bring many benefits.
If we need to write a lot of repetitive code, it might be helpful to extract it into a reusable component with configuration.
More from this author:
Nx for Angular: a reliable tool for simplifying work with IT projects
Ready to grow?Get help with your CV and profile and be found for rewarding projects.
The advent of artificial intelligence (AI) has sparked discussions across various industries about its potential impact on traditional roles and responsibilities. The field of project management is not exempt from these considerations, and as a project manager, it is only natural to ask yourself: How will AI affect my work?
This article serves as a guide to all aspiring project managers, discussing important considerations and essential skills needed to excel in this dynamic career.
As the first step in the project lifecycle, project initiation is critical in determining the ultimate success of a project. Learn the best practices and key considerations for successful project initiation.
