Mobile platform. How not to be afraid of ReactNative
We decided to devote the first blog post to “mobile” topics and talk about the development of a global solution for launching and creating applications - the ESF Mobile Platform.
What is it? This is a multi-module product that allows you to massively create mobile applications, replicate them and maintain them during operation.
')
So, what we do in order and by points.
We develop our own framework using the React Native library. Our framework is included in the EFS mobile applications for employees and is the mobile core containing the native code. Mobile business applications are now being developed in JavaScript.
We take out typical code fragments in essence, which we call “components” or “services”.
At the moment, our components are of three types:
Components have a wrapper bridge in JavaScript (using the ReactNative mechanism), thus we allow JavaScript developers, using the JS / TS, React + Redux stack, to create mobile and frontend clients.
Behind each of the components is native implementation. We use objective-c as the main language, strictly approach the architecture, and also care about performance and optimization.
We were not satisfied with the organization of the ReactNative library, because it did not look isolated, multi-layered and suitable for scaling, so we invented our own component library architecture - now our architecture is multi-layered and follows the basic rules from VIPER, SOLID and SOA.
Conceptual sketch in the figure below:
In fact, we made friends with ReactNative and VIPER.
We have almost completely abandoned the standard components developed by Facebook, and will re-implement those required to build our applications. Why?
When creating we adhere to the following principles.
When analyzing and choosing a solution, we had several output parameters and criteria:
Since one of our initial tasks was to unify the development stack and minimize costs, we started to select a solution that allows us to create mobile applications using JavaScript as a language for writing application code.
Cordova and PhoneGap quickly disappeared, because using them, we get a non-native application at the output.
ReactNative interprets JS-code in objective-c calls in Runtime, which allows you to execute native code and build interface forms from UIView descendants.
ReactNative is a natural continuation of React, which enables us to write unified code that runs on mobile applications and frontend clients on desktops.
We always test what we develop, because one of the essential qualities of platform libraries is reliability.
Now we have automatic Unit tests that run on every PR and build of the framework.
We consider it necessary to test the individual components and code of the demo project by hand.
In the near future, they will be joined by automated integration tests between modules, UI tests and Performance tests for implementation in business projects.
Also in the strategic plans are: the development of its framework for writing cross-code tests (JavaScript <-> objc-C) and static analyzers for analyzing the code of business projects.
We automate what we do. We now have CI and CD for individual platform modules. We have a separate physical build machine connected to the corporate Jenkins.
Running tests, code coverage report, updating indicators in dashing.io , building a version and publishing to nexus is just a small list of all the processes that are automated at the moment.
We are developing DevOps and we plan to integrate CI / CD with all applied projects, as well as automate work with customer support, incident analysis and much more.
We are currently working on a global architecture and principles for building all mobile applications within the ESF using the platform.
To be able to reuse between projects, we are working on a system for the separation of application code and design in the form of independent JS Bundle. JS Bundle are distributed in the form of npm-packages and are connected to the application at the compilation stage.
This approach will allow you to create static applications and update them through the assembly. This does not solve the problem: the business wants to see different “sets” of JS Bundle in applications depending on the role of the user (sellers have one functional, the heads of another). This problem can be solved either by creating a large number of small applications by role, or by including all JS Bundle one binary
Unfortunately, in this case, we are violating our time-to-market requirement, since the larger the application, the longer the regression tests are aimed at detecting defects of a particular version.
The concept of dynamic loading of the JS Bundle into a mobile application was proposed. Yes, it sounds very cool and innovative! But this is a new system requiring development, prototyping and piloting. Today in the world of such systems units (especially for native applications).
We will begin the study of this concept with R & D. Great opportunity to join the team if you are interested in such an ambitious story :-)
Our development teams of the ESF Mobile Platform work on Agile methodologies using the Scrum approach.
We have a two-week delivery cycle, as well as all the required Scrum-artifacts: planning, stand-up, grooming, demo, retro.
Stand-up help us to actualize problems every day, as well as to share realized between all team members. Important: we do not spend more than 15 minutes a day on a stand-up and spend them only standing.
We regularly overestimate our backlog and detail our tasks — this helps us spend less time planning. A retro and demo are with us fun and initiative (we participate in contests and nominations organized by our scrum master).
In addition to processes, we strictly monitor the technical side of our product: we write documentation, guides, conduct consultations and provide assistance to other projects.
We document our processes and approaches so as not to forget them and minimize active discussions next time.
Newbies do not feel lost, because we sit side by side, always pick out a mentor and have internal instructions-cheat sheets.
Interesting to know more? Let's talk to the creators of the platform right in the comments to the publication, who are interested in this topic, we will be glad to have a lively dialogue.
You can also watch our performances.
And if you feel the strength and desire in yourself, we invite ambitious and talented specialists to the team:
A start has been made, then we will publish a lot of interesting and useful content on the topics of development and process management, design and design.
What is it? This is a multi-module product that allows you to massively create mobile applications, replicate them and maintain them during operation.
')
So, what we do in order and by points.
Product development
We develop our own framework using the React Native library. Our framework is included in the EFS mobile applications for employees and is the mobile core containing the native code. Mobile business applications are now being developed in JavaScript.
We take out typical code fragments in essence, which we call “components” or “services”.
At the moment, our components are of three types:
- visual components (stylized buttons, switches, lists, switchers, loaders, etc.);
- non-visual services (networking, authentication, logging, remote configuration, etc.);
- mobile widgets (end-to-end components that allow you to display some aggregated indicators in a special section called “Dashboard”).
Components have a wrapper bridge in JavaScript (using the ReactNative mechanism), thus we allow JavaScript developers, using the JS / TS, React + Redux stack, to create mobile and frontend clients.
Behind each of the components is native implementation. We use objective-c as the main language, strictly approach the architecture, and also care about performance and optimization.
We were not satisfied with the organization of the ReactNative library, because it did not look isolated, multi-layered and suitable for scaling, so we invented our own component library architecture - now our architecture is multi-layered and follows the basic rules from VIPER, SOLID and SOA.
Conceptual sketch in the figure below:
In fact, we made friends with ReactNative and VIPER.
We have almost completely abandoned the standard components developed by Facebook, and will re-implement those required to build our applications. Why?
- Our components must have a unique, uniform EFS visual style and be unsuitable for modification (only valid settings through properties).
- We cannot cover ReactNative code with tests and be responsible for their quality, as well as correct behavior.
- We do not accept fork libraries and their further development.
- Our understanding of the architecture is not shared by the creators of ReactNative and we cannot inject or reuse certain parts of the code that are used in the components.
- ReactNative - even in the deep beta-version and dynamically changed. Between version changes, backward compatibility is not supported and we cannot be sure that the code of our library will compile correctly after the release of updates from Facebook.
- We want to have “in stock” native code, which potentially allows this component to be used in other projects and even outside the concept of ReactNative.
Why ReactNative?
When creating we adhere to the following principles.
- Create a solution that allows developers with the same technical stack to develop both mobile and frontend applications.
- Allow to quickly reuse the previously developed functionality.
- Minimize bank costs for application development and support.
- Provide fast time-to-market.
When analyzing and choosing a solution, we had several output parameters and criteria:
- a large number of legacy systems in the bank, developed for the Web;
- As a result, a large number of developers with competencies in JavaScript;
- an emerging and promising Web product using JS, React and Redux in its principles.
Since one of our initial tasks was to unify the development stack and minimize costs, we started to select a solution that allows us to create mobile applications using JavaScript as a language for writing application code.
Cordova and PhoneGap quickly disappeared, because using them, we get a non-native application at the output.
ReactNative interprets JS-code in objective-c calls in Runtime, which allows you to execute native code and build interface forms from UIView descendants.
ReactNative is a natural continuation of React, which enables us to write unified code that runs on mobile applications and frontend clients on desktops.
Testing
We always test what we develop, because one of the essential qualities of platform libraries is reliability.
Now we have automatic Unit tests that run on every PR and build of the framework.
We consider it necessary to test the individual components and code of the demo project by hand.
In the near future, they will be joined by automated integration tests between modules, UI tests and Performance tests for implementation in business projects.
Also in the strategic plans are: the development of its framework for writing cross-code tests (JavaScript <-> objc-C) and static analyzers for analyzing the code of business projects.
Process automation
We automate what we do. We now have CI and CD for individual platform modules. We have a separate physical build machine connected to the corporate Jenkins.
Running tests, code coverage report, updating indicators in dashing.io , building a version and publishing to nexus is just a small list of all the processes that are automated at the moment.
We are developing DevOps and we plan to integrate CI / CD with all applied projects, as well as automate work with customer support, incident analysis and much more.
Scaling
We are currently working on a global architecture and principles for building all mobile applications within the ESF using the platform.
To be able to reuse between projects, we are working on a system for the separation of application code and design in the form of independent JS Bundle. JS Bundle are distributed in the form of npm-packages and are connected to the application at the compilation stage.
This approach will allow you to create static applications and update them through the assembly. This does not solve the problem: the business wants to see different “sets” of JS Bundle in applications depending on the role of the user (sellers have one functional, the heads of another). This problem can be solved either by creating a large number of small applications by role, or by including all JS Bundle one binary
Unfortunately, in this case, we are violating our time-to-market requirement, since the larger the application, the longer the regression tests are aimed at detecting defects of a particular version.
The concept of dynamic loading of the JS Bundle into a mobile application was proposed. Yes, it sounds very cool and innovative! But this is a new system requiring development, prototyping and piloting. Today in the world of such systems units (especially for native applications).
We will begin the study of this concept with R & D. Great opportunity to join the team if you are interested in such an ambitious story :-)
How we are working?
Our development teams of the ESF Mobile Platform work on Agile methodologies using the Scrum approach.
We have a two-week delivery cycle, as well as all the required Scrum-artifacts: planning, stand-up, grooming, demo, retro.
Stand-up help us to actualize problems every day, as well as to share realized between all team members. Important: we do not spend more than 15 minutes a day on a stand-up and spend them only standing.
We regularly overestimate our backlog and detail our tasks — this helps us spend less time planning. A retro and demo are with us fun and initiative (we participate in contests and nominations organized by our scrum master).
In addition to processes, we strictly monitor the technical side of our product: we write documentation, guides, conduct consultations and provide assistance to other projects.
We document our processes and approaches so as not to forget them and minimize active discussions next time.
Newbies do not feel lost, because we sit side by side, always pick out a mentor and have internal instructions-cheat sheets.
How to find out more and join?
Interesting to know more? Let's talk to the creators of the platform right in the comments to the publication, who are interested in this topic, we will be glad to have a lively dialogue.
You can also watch our performances.
And if you feel the strength and desire in yourself, we invite ambitious and talented specialists to the team:
- iOS developers (obj-c, ReactNative, VIPER, JS, SOA, Typhoon).
- frontend developers (typeScript, javascript, react, redux).
- interface designers and designers.
- automators and mobile testers.
Email Evgeny Rtishchev to ESRtishev.SBT@sberbank.ru or Ostrovskaya Anastasia ASOstrovskaya.SBT@sberbank.ru
A start has been made, then we will publish a lot of interesting and useful content on the topics of development and process management, design and design.
Source: https://habr.com/ru/post/321828/
All Articles