In 2020 FarmHedge signed two customers that needed a new app and dashboard to trade and communicate with their own customers. Their requirements were quite similar at the core. Also, we needed to migrate our existing customers to a newer, more powerful version of the system. Their core requirements also matched the ones of the two new customers. We decided to build a system for creating FarmHedge-based apps easily and in a scalable way.

The first step was to identify the core-set of features needed by the applications. Once we did that, we built a library that worked as an interface between the front-end applications and the two main components: a domain-based set of configurations and the FarmHedge APIs. The high-level design is depicted in the current picture:

UI library

The UI library stores information shared among all the FarmHedge UI apps:

• DB model: definition of the classes that represent the DB models interfaced by the API.
• Services: The layer that help asynchronously access the data via the FarmHedge APIs.
• Configurations: A set of configurations based on the current active profile. The configuration contains the personalisation of different views or processes.
• Test tools: The library also provide basic test tools for unit tests and e2e tests to be used in the apps. The test tools also provide way of testing different configurations.

Deciding the technology to be used for of a common library was easy because all apps are based on the Angular framework directly or wrapped within the Ionic framework. Once the library was created, we published it in a private NPM package. Note that when using private NPM packages, apps need to authenticate with a API key provided by the NPM hosting environment.

Sub-domain-based profiles

The UI library loads different configurations based on the subdomain used by the front-end app. For example one of our customers subdomain is “ufeeds.farmhedge.co.uk”. All apps using this prefix will automatically load the configuration.

For consistency the app and bundle ids stored on the Android Play Store and iOS App Store are the same of the customer sub-domain.

The following picture shows an example of the composition dashboard.ufeeds.farmhedge.co.uk will render the dashboard for a customer while dashboard.rwa.farmhedge.ro will render the dashboard for another customer.

Conclusion

The definition of this architecture was crucial for avoid code duplication. This allowed our team to reduce costs in maintenance and incompatibility issues in models and functionalities early in the development process. Having a set of tools as a starting point will also make the creation of new apps faster and less error prone. Most importantly, new customers with non trivial customisation requirements can easily be supported.