Edouard Maleix

The second challenge (see project below for intro) was to define a (soon to be) SaaS solution that could

- provide enough service to be (worth being) integrated by customers into their ERP for evaluation

- create an API first solution as it would be integrated to ERP (SAP only in fact) by integration partners

- be documented enough for integrators to work mostly independently

- scale with the company growth for 4-5 years

- integrate existing key management solution

- be deployable via PaaS provider (Heroku in our case)

The minimal set of functionalities exposed being:

- create (or reuse from existing BIP39 mnemonic) crypto wallet

- two operational modes, test and live with distinct resources (think Stripe test mode, https://stripe.com/docs/test-mode)

- validate and render certificates as PDF and HTML

- notarize certificates (certificates are considered notarized when a given certificate hash is embedded in a transaction signed by the issuer and sent to a DLT node in our federated network)

- verify notarized certificates

- webhooks and mail notifications for all parties included in a certificate

- a low level API to enable tech savvy customers to create, sign and send their own transactions.

I have been actively working on this product for the past 3 years and there has been many challenges, from its design, to its implementation and maintenance. One of the most complex (technically) was the move to a “real” micro (or rather mini service architecture) where each service was deployed on different location and was responsible for its own data sources BUT still had to (potentially) share and synchronise their data with other services. I adopted the saga pattern (https://microservices.io/patterns/data/saga.html) where each service could communicate through RabbitMQ channels.

Of course it triggered other challenges such as data integrity insurance (solved with optimistic locking and data versioning) and overall performance monitoring (solved recently by using OpenTelemetry instrumentation libraries and distributed tracing solution from Sentry).

I was also responsible for hiring my future colleagues to collaborate on the data models (described in the project above), build the front end applications and consolidate / maintain the backend applications.

My participation went :

- from (failing to do good) head hunting

- to benchmark and select hiring platform and agencies

- to think of a stimulating hiring process

- to write job descriptions

- to create technical challenges for front end and backend candidates

- to lead technical interviews and offer guidance and feedback on the first (introduction) interviews

- to promote a high quality coding standards

When i joined the company, a first PoC was built to present a demo to potential customers, it worked pretty well to make you understand the concept but was unscalable and unsafe.

As i was the first in house developer, there were many challenges that needed to be tackled with a very limited amount of time. Still there were two main directions that could be identified :

- the data models used to represent those material certificates and the related tooling (to validate, render as HTML and PDF, parse and extract properties …)

- the platform itself and the services it should offer to customers

The former was probably the smartest choice to start with, to onboard a company they need to be able to represent their existing certificates into machine readable format (JSON in our case), so that is the entry point. The challenge here, was to define a solution - to manage multiple type of certificates (for different industries / materials and different standards) - that allows to use public and private data models - that enables versioning of models and their bound static resources (schemas, translations, scripts … ) - to provide a generic library that could be used in our future platform (and potentially customers) that would interact with all those data models and would abstract all the differences between them.

So that the consumer of this library would just pass an instance of these models and could validate, render, parse … without caring about the type of the certificate.

The resulting design is described in this documentation, https://s1seven.github.io/SEP/schemas/#proposed-enhancement. Some of those data models can be found in this GitHub organization, https://github.com/orgs/material-identity/repositories.

The library that interacts with those models is the company organization, https://github.com/s1seven/schema-tools. It also relies on a (NodeJS) micro service which synchronises content from Github repositories (via web hooks triggered on release creation and update) and serve what is needed to make our utility library works. It makes heavy use of caching and streaming to guarantee low latency. This project is private.

To this day we still use this architecture, after 3 years designing and implementing it.