Wineapp for Enartis

Enartis is a company that provides products and services to the wine industry. They have a series of products that help wine producers to manage their production. The University of Johannesburg, contacted F.Technology to develop a web app that would help wine producers to manage their wine tasting sessions.

The requirements

The platform would consist of a web app and a mobile app for the wine tasters. The web application will be used by the wine producers to manage the wine-tasting sessions and the mobile app will be used by the wine tasters to record the results of the wine-tasting sessions. The tasting session manager will be able to create a tasting session and invite the wine tasters to the session. During a tasting session creation, the manager will be able to add the wines that will be tasted during the session as well as the different attributes that will be evaluated. The wine tasters will be able to revisit the results of their tasting session and the manager will be able to see the results for all of the participants. Some graphical representation of the results will be provided, like a word cloud chart or a spider chart. The tasters are not going to need an actual authentication system, they will be able to access the app by providing some generic information like their name, age, and work position. This is necessary to create some kind of profilation of the tasters.

The solution

The first decision that we had to make was to decide if we wanted to develop a native app or a web app for the taster application. We decided to go with a web app because the set of functionalities where limited and no access to the device hardware was needed. A big factor in this decision was the stores (App Store and Play Store) process to publish and sign apps. We didn’t want to go through the process of publishing an app in the stores. We wanted to be able to deploy the app on the web and be done with it.

After choosing a web path for the taster application we had to decide which technology to use. We decided to go with React and Typescript. The main reason for this choice was the familiarity of the team with the technology. We also choose (as we do always for this kind of product) to put all the parts of the product inside a monorepo. This lets us share a lot of components between the two main UI applications, developing some kind of design system. For example, the rendering of the graphs is done by a shared component that is used by both the taster app and the manager app but also by the backend to render the graphs as images. The need to generate the graphs images server side was since those assets were going to be downloaded by the manager and also sent inside recap emails to testers. To achieve this server-side rendering we used virtualization of a dom browser using jsdom and sharp to generate new images from the SVG string generated by the graphing library. We used D3.js for the graphing library.

My thoughts

Isomorphic Javascript is a concept that has been around for some time now. I think that the runtimes, at the time I’m writing this, are not quite there. From Node.js to Deno, Bun, and V8 the surface area of the javascript APIs that are available in those runtimes are not quite interchangeable yet. Nonetheless, writing a small subset of functionality to be isomorphic is not that hard. In this project for example I’ve been able to manage the rendering of the graphs in the browser and the server with the same code (a series of functions that generate an SVG using D3). What it took me to achieve this, on the server side, was writing a small rendering wrapper powered by jsdom and executing the rendering function of the graph against it. This is a statement on how flexible of a language and an ecosystem is Javascript. In the future, I will still bet on Javascript.