Tech & Experiences Vol. 3
Tech & Experiences is the lightning-fast way in which the Flux IT tech community shares its most juicy experiences and learnings from projects in multiple industries.
State Management in a Start-up
By Iván Dackiewicz, Technical Leader
Scenario
For the past 3 years, we have been walking a start-up client through the development of its platform. Our client has already released 3 versions of the platform and is now implementing its fourth. The changes between versions involved not only UX/UI, goals, and audience aspects but also the way in which we manage states in a React app. We evolved our approach based on the team’s needs and growth.
At first, we would manage the state using Redux Toolkit. At that time, Redux was still at its peak, and using RTK to implement it made life much easier for Developers. This went on like this for quite some time, and eventually, we started using Redux Toolkit Query to send requests to the back end.
Ironically, this final step marked the beginning of the end for Redux as our default state manager. Since RTK Query abstracts the handling of responses and query states, there was little left to manage manually in the state, and doing so with Redux became somewhat cumbersome.
How We Solved It
Almost simultaneously, we started using Context API for specific cases in which we needed to maintain a particular state in certain areas of the DOM (more on this soon). This made us grow fond of Context API and use it to manage (not so global) new states.
The new version 4 brought together a significant change. Instead of just revamping its design (and target), we also took the opportunity to update its technology. We left behind the nearly 3-year-old project and started working on a completely new repo. This allowed us to reconsider the technologies we had previously been using and brought in new ones like Zustand. Even though we still use Redux Toolkit Query for managing back-end requests (and we do not replace it to avoid having to learn too many new things at once), all non-local state is now handled by Zustand, and when needed, by Context API.
Why? Although Context API is much less verbose than Redux (even with RTK), it still is not as simple as Zustand, and it has an issue to consider. If a context value is changed, every component within that context provider will be re-rendered. In some cases, this is not a problem, but it can be a significant limitation. Therefore, we decided to add another library to address this disadvantage.
By doing so, data that is particularly static or that changes at the highest level of the DOM contained by the context (which would cause a re-render anyway) is handled by Context API. But the rest (the majority) now uses Zustand. This allows us to write a well-structured state with very little code, makes prop drilling elimination easier than before… and gives us a new toy to play with.
Now, I ask you: How has your experience been with the different state management methods in your apps?
Maximizing the Reliability of Scheduled Tasks in Microservices with ShedLock and Spring
By Darío Aguiar, Technical Leader
Scenario
For one of our clients from the insurance industry, it was essential to execute reliable processes when adopting a microservices architecture. These processes needed to be executed asynchronously, outside of operational hours, and they would be responsible for updating the status of customer requests, either individually or in bulk.
How We Solved It
For batch processes in microservices, we incorporated ShedLock (along with Spring, the base framework for services), which provided us with an elegant and scalable solution to the lock problem between such processes. This allowed us to focus on business logic while delegating process synchronization to ShedLock, thus avoiding undesired executions and data integrity issues.
Using ShedLock’s integration with the Spring framework provided us with a complete and robust solution for managing scheduled tasks and locks in distributed apps that were developed with Spring Boot. Spring offers a flexible and scalable development environment, while ShedLock adds the crucial feature of distributed locking. The result was a highly efficient and reliable system: 100% recommended!
Creating a Base Template to Develop React Apps
By Leonardo Galdames
Scenario
In our team, we develop web apps for clients across various industries. In a recent project, we faced the challenge of creating multiple React apps with similar components and styles but with specific features for each one. This involved a repetitive and slow development process, since we had to manually set up the base of each app.
Base Template for React Apps
It is a predefined template that contains the basic structure of a React app, including reusable components, predefined styles, and essential configurations. By using a base template, Developers can save time and effort when starting new projects since they do not need to set everything up from scratch.
How We Solved It
To tackle the challenge of creating multiple similar React apps, we decided to develop a base template for that technology and a component and style library using Storybook. This base template included:
- Reusable components: basic components such as buttons, forms, cards, and tables.
- Predefined styles: a color palette, typography, and global styles.
- Essential configurations: basic set-up for tools like Webpack, Babel, and Jest.
Conclusion
Creating this base template allowed us to:
- Accelerate the development of new apps, since Developers could quickly start new projects with the base template and focus on the specific features of each app.
- Maintain consistency, since all apps developed with the base template share a coherent look and user experience.
- Improve code quality, since the base template establishes coding standards and best practices, thus enhancing the overall quality of the app code.
Express Two-Factor Authentication (2FA) Built On Simple JWT Authentication
By Walter Alessandrini, Technical Leader
Scenario
A major client operating train terminals in the United Arab Emirates requested the inclusion of a second factor of authentication via email. At that time, we had a JWT-based authentication/authorization implementation and limited time to incorporate this new requirement.
How We Solved It
Instead of developing a solution from scratch, we decided to implement the second factor of authentication using Redis, an open-source, in-memory data warehouse. With Redis, once the user and password are validated, a one-time password (OTP) is generated, which is communicated to the user via notification service, and stored in Redis (encrypted) along with its expiration time. When users receive an email with the OTP code, they access it through the app’s UI and submit it. If the submitted OTP code matches the one stored in Redis, the JWT is generated and sent. The authentication and authorization process then continues as previously implemented.
