Our Frontend Journey about Healthcare Solutions Project

We are the frontend team of Turkcell Healthcare Solutions and we are leading the transformation of the current project. The project was coded with Ext JS and we decided to write it with React.

There are more than fifty modules in Healthcare Solutions and we are planning to transform each module separately. We need to start this transformation while current project is still running and being used. There are many technical barriers and decisions to make and we want to share our journey which is still going on…

Modules

Considering Micro Frontends

First, we decided to make every module as a separate app so we came with the idea of using Micro Frontends. We’ve tried to learn the subject from multiple sources like articles, experiences, stories and finally took a course to dive deeper. Later, we’ve written a small project, to test if it fits to our needs.

But, we understand that:

  1. We have 40 fullstack and only 2 frontend developers so working as separate teams for each project is not possible.
  2. We didn’t plan to use multiple frameworks, only React.
  3. Too complicated webpack configs and dependency management.
  4. We didn’t need Domain-Driven Architecture, each module can be routed in SPA.
  5. Testing the whole project is difficult.
  6. CSS, Local Storage and Cookies usage can be cumbursome and conflicts may occur.
  7. Following the conventions can be hard for each team.
  8. Shared state between apps is not possible, communication can be done with window object or via API calls.

As a result, we decided to choose Monolith Project Architecture rather than Micro Frontends. But, we’ve built our structure which can be convertable to Micro Frontends, easily. In the future, if we’d like to use this architecture, we can change every module to a micro app.

Main Structure

Later, we’ve started to think about our main structure in this monolith project. With react-router-dom, we’ve created our routes and directed every route to modules folder. Because in our app every module is a separate view and those views are composed of components. We’ve separated shared components from custom components and specified core components in shared folder.

Then, we’ve started to think redux folder to correlate with components. Modules can be managed in modules and components can be managed in components under the redux folder.

Main Structure

custom components: These components can be used only once and their states can be managed in redux/modules folder.

shared components: These components can be called from different views and their states can be managed in redux/components folder.

core components: These components are pure components. They have no state and they take state over shared or custom components. Button, Datagrid, Input, Dropdown are the examples of core components.

Conclusion

In this article, we’ve briefly talked about the obstacles we’ve faced and how we’ve solved them. The main idea is to understand the project’s scope and come up with the related solutions. We’ve tried to describe main concept and structure and how we wanted to implement our components upon that structure. We’d like to discuss technical details of this implementation on another article so hope to see you there ! :)

References

https://github.com/edanurascii/microfrontends

--

--