Voxi

While working as a subcontractor for MMT digital, I was brought onto a green field project for Vodafone.

Vodafone launched VOXI which is aimed at the younger audience aged 16 – 30. I came into this project in the early stages as a front end React/Node developer, the MVP was delivered August 2017 and has been progressively enhanced with new features. I worked in a scrum team of five which then grew to eight including UI/UX designers, PO’s and TPO’s.

The application technology stack was:

• The App was built using React
• We used SCSS to style our components and used elaborate higher order components to apply styling to components dynamically.
• As we were siting on top of a Spring backend (Java), the micro services at the time I was working on the project were not tailored for the VOXI app but more for the rest of Vodafone. This mean't that we had to build quite a few Node middlewares that did aggregation relevant to the VOXI app. This has since change the last time I checked this.
• We used MOBX as our state manager on the frontend.

• Built reusable React components which would be used consistently throughout the site based on the UX/UI designs. 
• Worked using an MVC type architecture on the front end to manage separations of concerns i.e. Pages, Stores, Routes. 
• Created JavaScript interfaces for microservice integrations.
• Writing Node middlewares.

Using MOBX was a bit of paradigm shift for me when building frontend applications. It gave a more of an MVC approach to the structure of code on the FE. This was before the time of React 16 which introduced React hooks. although React hooks was an abstraction of state, the state would destroy as soon as the component dismounts.

As an external state manager, state can persist during the client session until the page is refreshed. MOBX provided this functionality in a great way to orchestrate application state on the FE.

Although there was Redux out at that time, I gravitated to this way of handling external state outside of React components. We structures the site like so:

Service Interface (Model) -> MOBX Store (Controller) -> React Component (View)

Node middlewares were implemented to aggregate and interact with the backend service architecture. At that moment of time VOXI was a green field project sitting on top of the Java backend (to which at this point did not have proper micro service architecture). We had to make several backend calls within the node server to compose the correct data for the VOXI front end. It exposed the fact that the Java backend needed refactoring, splitting services into more consumable micro services. Latency was an issue with this current implementation as just to login require 7 different service calls.

Now I understand that this is now only 1 service call and is much faster.

On another note serverside rendering had not be implemented at this point of time which require the HTML file to have quite a bit of meta data on it. I know that there is work currently happening to implement prerendering functionality to apply SSR.