Forem: Vanderlei Alves da Silva

Bringing Web3 Principles to Enterprise Systems

Vanderlei Alves da Silva — Mon, 27 Oct 2025 07:26:02 +0000

While getting back to the basics of the blockchain architecture some rather philosophical thoughts just popped up into my mind, the enterprise software landscape is build around centralized platforms, potentially build in a distributed manner but vendor locked-in, and opaque systems that businesses have accepted as "just how things work." But ...

What if these systems were built on fundamentally different way? On Web3 principles? How would they look like??

This article series explores this question through a proof-of-concept: a blockchain-based booking system that aims to validate whether Web3 principles can address real enterprise challenges while meeting strict regulatory requirements like GDPR.

Web3.0: Is that still a thing?

Though the cryptocurrencies continue steady striving the term Web3.0 doesn't feel to follow the same path. Looking by the main articles on the topic most of them used to date back 2 to 3 years, we could naturally argue that the boom of AI and the shallow specialists writing about it everywhere, have left the internet a bit more "poor" in terms of variety of content, still the way I see it, the web3.0 term sounded more as a philosophical aspirational goal, which is likely not to achieve its full idealized potential.

Letting the philosophical discussion aside and going into the interesting engineering part, at its essence, Web3.0 proposes five architectural principles: decentralization (distributed control instead of central authority), user ownership (individuals own their data and digital assets), transparency (verifiable systems and open rules), trustless architecture (smart contracts execute automatically without intermediaries), and composability (interoperable systems that work together through open standards).

These aren't just blockchain buzzwords. They represent a fundamentally different way to architect systems—one that addresses real enterprise pain points like vendor lock-in, opaque pricing, high intermediary costs, and data privacy concerns.

With that in mind I want to propose the following exercise:

Can we extract its valuable principles and apply them pragmatically to solve real business problems?

The Booking Platform POC: Validating Web3 Principles

To explore whether these principles work in practice, we need a concrete example. I will call it: blockchain-based booking system.

Why a Booking Platform?

Booking systems are ideal for this exploration because they:

Have clear business logic - Rules for availability, pricing, and reservations are well-defined
Involve multiple parties - Customers, resource owners, and potentially intermediaries
Require trust - Bookings must be honored; payments must be released
Handle sensitive data - Personal information, payment details, booking history
Face real regulations - GDPR compliance is mandatory in many markets

If we can build a booking system that embraces Web3 principles while meeting regulatory requirements, we can much more confidently assert that the concept works for enterprise applications.

The Specific Web3 Principles We're Testing

This POC validates five key principles:

1. Decentralization

No central platform controls bookings
Smart contracts manage state, not a company
Anyone can verify the system's integrity

2. User Ownership

Customers control their booking data
Data can be deleted on demand (GDPR "right to be forgotten")
Booking records are portable across platforms

3. Transparency

Booking logic visible in open-source smart contracts
All transactions auditable on the blockchain
Pricing rules are transparent and verifiable

4. Trustless Execution

Smart contracts automatically enforce booking rules
Payments released when conditions are met
No intermediary needed to arbitrate

5. Privacy-Preserving Design

Personal data never touches the blockchain
Cryptographic hashing enables verification without exposure
GDPR compliance through architectural design

What Are We Building?

Below is the system architecture diagram showing how we're implementing these Web3 principles in practice:

The User Interface Layer serves as the entry point to the system, providing a command-line interface (CLI) built with Node.js and TypeScript. This layer represents the client, it could be any other kind of client, web page in the browser, mobile application, internet of things (IoT), you name it. But for this use-case to make things simpler, we go with a simple CLI application.

The Application Layer acts as the intelligent middleware that orchestrates all system operations. Let's think of it as a backend services which houses five critical services: the Blockchain Service interfaces with Ethereum using Ethers.js to handle all blockchain transactions; the Encryption Service to generate unique key pairs for each booking and performs AES-256-GCM encryption on personal data; the Storage Service which manages the lifecycle of encrypted data stored off-chain; the Wallet Manager securely handles user cryptographic identities and signing operations; and the Config Manager maintains network settings and system configuration. This layer is responsible for the critical separation between what goes on-chain (only hashes) and what stays off-chain (encrypted personal data). More on that later :)

The Blockchain Layer represents the immutable, transparent core of the system running on Ethereum. At its heart are smart contracts written in Solidity that contain all booking business logic—resource management, availability checking, and booking state transitions. These contracts interact with the broader Ethereum network through a JSON-RPC Provider that connects to Ethereum nodes. Crucially, this layer stores only cryptographic hashes and public booking metadata (dates, prices, status) while keeping zero personal information. The blockchain serves as the source of truth for booking existence and availability, providing transparency and preventing double-booking through distributed consensus.

The Off-Chain Storage Layer is the privacy-preserving counterpart to the blockchain, designed specifically to handle sensitive personal data in a GDPR-compliant manner. It consists of an Encrypted Data Store (PostgreSQL, MongoDB, or any other storing mechanism) that holds encrypted personal information, a separate Key Vault that stores encryption keys in isolation from the data they protect, and a Privacy API that manages GDPR operations like data export and the "right to be forgotten." The architectural decision to separate encrypted data from encryption keys is critical—when a user requests deletion, removing the keys makes the encrypted data mathematically irretrievable, achieving GDPR compliance while leaving blockchain hashes untouched.

The Storage component represents two distinct persistence mechanisms: Local Storage for user-side data like wallet keystores and configuration files, and On-Chain Storage within the blockchain itself that holds only hashes and non-sensitive booking metadata. This dual storage approach reinforces the system's privacy-first design—sensitive data never crosses into blockchain storage, while blockchain benefits (immutability, transparency, auditability) are preserved through cryptographic hashes that prove data existence without revealing its contents. The integration between these storage types is mediated entirely through the Application Layer, which ensures proper encryption, hashing, and separation of concerns throughout the data lifecycle.

Ethereum as the Blockchain Platform

Ethereum for those who still may be in doubt of what exactly it is, is a decentralized computing platform that runs on a global network of computers instead of a central server. This means that no single company controls the system, a capability we are really looking for this exercise, and applications built on Ethereum — called decentralized apps (dApps) — continue to run as long as the network exists.

For a booking platform, Ethereum and dApps bring interesting possibilities. Instead of depending on one central business to record reservations, availability and payments, the blockchain can ensure the records are shared, trusted, and consistent across all participants — hotels, partners, and users. Smart contracts could automatically handle payments, deposits, cancellations, loyalty points, insurance, or secondary resale of bookings without intermediaries. And since the system is open and auditable, fraud and double-booking become much harder.

Coming Up Next

This article aimed to establish the why Web3 principles matter and what we're building. The next articles will dive into how, exploring the implementation in details, having a bit of fun in the way while playing with: Ethereum blockchain platform, Solidity code, business logic on-chain, and how to build contracts that enforce rules transparently while respecting privacy.

View the Architecture

If you got interested and want to dive into all details just goal ahead in the following link to the public repo, which though still a WIP, already have an extensive system architecture in place:

Or view the complete codebase on GitHub

A piece o merchandising

Lastly a small pause for sharing you some very exciting new, at least for myself :), recently I've just released my first book:

Micro Frontends Architecture for Scalable Applications

Which bring lots of architectural insights about the frontend development, and more specifically about the micro-frontends, go a head have a look and let me know your thoughts.

Did you find not connected to web3.0, blockchains and this article at all? Yeah, indeed is not, but why would we put boxes around what we can work/learn if we can explore them all ...

Thanks for reading and let me know your thoughts/feedbacks/comments and or any other thing you may find relevant to share!

NextJS Progressive Web App

Vanderlei Alves da Silva — Tue, 17 Mar 2020 07:36:54 +0000

What if we could quickly setup a progressive web app, with server side rendering and routing mechanism out of the box? Would that sound interesting? That’s why you here, stick with me and enjoy the road.

It all starts with NextJS, we install it and run it as the following code:

"scripts": {
    "dev": "next",
    "build": "next build",
    "start": "next start"
},

The first question that come up is why would we go to a different approach to start a react project other then create-react-app? The question is pretty straightforward, if you wanna have server side rendering and a better and easy way to work offline. You not sure? Here it goes …

create-react-app comes out of the box with an offline support, however it’s restricted in how stores locally its assets. It restricts us to the generated assets (js, css, images, fonts ...), however what if you also wanna store CDN files, backend apis, system specific routing? How would go there, probably ejecting your project and(or) using other libraries, such as react-app-rewired, but at the end these approaches soon or late end up adding more complexity to your code and more code to maintain .. Anyway why would you enjoy maintaining custom script building systems?

Now take a look at this code:

const isProd = process.env.NODE_ENV === "production";

const withPWA = require("next-pwa")

module.exports = withPWA({
 pwa: {
   disable: !isProd,
   dest: "public"
 }
})

With a simple higher order function we add the desired functionality! Too fast? Let’s digest this properly.

First thing first, have a look on this dummy example (if you wanna fully experience all features, use chrome, nothing against the others, but while I’m writing this article, progressive web app functionalities are still a work in progress and the installable option of our app will not work on them)

Once you there, open the developer tools and check while you navigate and/or refresh the pages, the resource (js, css, fonts, api calls ..) are being locally saved:

Check also on the plus icon right after the website url bar:

And if you inspect the network tab, you’ll see that the initial load comes with all your app already rendered from your server .. :)

That’s it, these are the user functionalities of our dummy app, disable the internet connection and then you can see a friendly message saying that there is no connection and the app still working.

But then now it comes the question, how is that done? Tired of reading? Go directly to what matters: the code!

The implementation is as NextJS project, using MaterialUI for the interface elements, Typescript for type checking, next-pwa a next plugin for the progressive web app functionalities and a quick bonus, check this code. An MDX support for next provided by next-mdx.

If you look at the code you may notice the absence of a routing coding, a react-router or similar, that’s NextJS in action, it gives an automatic routing system, just put your routes under page folder and the routing is done:

Wondering how does it work and how is that done, check here: https://nextjs.org/docs/routing/introduction

Here we can clearly see how easy can be set a project with advanced feature just by choosing the right tools, because at the end, the heavy work of a developer is not developing thing and yes choosing the right tools for what we need.

There is so many nice wheels to be used, why would we create our owns? Let’s grab them and construct our beautiful cars!

Middlewares with react context and hooks

Vanderlei Alves da Silva — Mon, 07 Oct 2019 07:32:11 +0000

Continuing the idea explored in the previous article of having a global state management using pure react (with react context and hooks), we’re going to explore now how to take advantage of the middlewares concept, implementing for that a loger and localStorage middleware to our todo app, check here the live demo and here the source code

About middlewares

The term can slightly differ from each depending on the middleware type (Database Middleware, Integration Middleware, Application Middleware, Object Middleware, Remote Procedure Call (RPC) Middleware, Message Oriented Middleware ...) but essentially they have the idea of a composable peace of code running in the middle of to distincts processes improving their communication, and by process we could use more specific terms according to the scenario that we are talking about.

In the web development niche this term is spreedly used in server side technologies such as Laravel, ExpressJS, nestJS among others as:

A composition of functions that are called, in a given order, before the route handler and that usually each one of them have access to the request information and a reference to the next function in this chain

This idea was taken by the front-end fellows, mainly applied by the state management libraries: redux, mobx, vuex (the last even though with a different nomenclature “plugin” the idea is the same), and what they all do is to provide a way of running some code between dispatching an action, and the moment it changes the application state.

Of course this concept can be used in other scenarios, this article explores its usage attached to the router change in angular, getting closer to the above mentioned server-side ones. But for now we’re going to explore the first one.

Show me the code

import { initial, final } from './log';
import localStorage from './localStorage';

export default ({ state, action, handler }) => {
  const chain = [initial, handler, localStorage, final];

  return chain.reduce((st, fn) => fn(st, action), state);
};

That’s all what matters, we need a function to create a middleware chain and execute all them in a given order and of course call our handler (the reducer function called by a given action in our application).

const chain = [initial, handler, localStorage, final]

Here we define the middlewares that will be called and in which order they will, the ones that comes before handler are the pre-middlewares (you put here all middlewares that you want to run something before the state have changed) and the others the post-middlewares (the ones that execute something with the new state).

The middleware function signature follows the same pattern of the reducers:

(state, action) => newState

As an example here is the initial log middlewares:

const initial = (state, action) => {
  console.log(action);
  console.log(state);
  return state;
};

The middleware just log the initial state (before the state have being change by the reducer) on the console.

Here we have a more interesting one:

import store from 'store2';

export default state => {
  store.set(state.storeId, state);
  return state;
};

This middleware saves the current state on the local storage, I’m using for this a small library store2 just to make sure retrocompatibility with old browsers and also avoiding working with try catch statements.

I have on the app state an storeId property with the name of the key that will be saved on the local storage, so basically in this call:

store.set(state.storeId, state);

I store in the given key the given state. If you check the app again, play around and refresh the page, the information will still be there.

And lastly we have:

return chain.reduce((st, fn) => fn(st, action), state);

We use the reduce array method to iterate over each item of the chain getting the result of the previous and passing to the next item.

There it is

We have now returned to the basics and explored how the main state management libraries conceptually work with middlewares, giving us the same results with less dependencies and less complexity. We now understand what happens, instead of just blindly using them.

What do we got from it!? A better reasoning of when to use these state libraries.

What do we go from now!? More hooks on the way, check here the new custom hooks from react-router-v5.1 and see you soon. ;)

References

https://dev.to/vanderleisilva/global-state-management-with-react-hooks-and-context-5f6h
https://vanderleisilva.github.io/react-context/
https://laravel.com/docs/6.x/middleware
http://expressjs.com/en/guide/using-middleware.html
https://docs.nestjs.com/middleware
https://redux.js.org/advanced/middleware
https://github.com/mobxjs/mobx-state-tree/blob/master/docs/middleware.md
https://vuex.vuejs.org/guide/plugins.html
https://www.w3schools.com/jsref/jsref_reduce.asp
https://reacttraining.com/blog/react-router-v5-1/

Global state management with react hooks and context

Vanderlei Alves da Silva — Tue, 24 Sep 2019 07:33:09 +0000

From prop drilling to centralized global state management with react

It all started with amazing frameworks like react, vue, angular and some others that have had the brilliant idea of abstracting the application data from the document object model (DOM). React specifically, with your reconciliation algorithm and soon with the fiber architecture, rocks on how fast these layers (abstraction and DOM) are updated. With that we can focus on our components instead of the “real” HTML implementations, however from that also come some other new challenges, let’s put it in images:

That’s the classical prop drilling react anti-pattern, the process of going through the react component tree in order to pass properties between them. Higher order components or Decorators, if you are in a more object oriented style, give us more flexibility and some others architectural possibilities. We can now extract away that functionality which we want to share and decorate the components that need use it.

It’s all fine while dealing with small apps with few components interacting with each other, however when we have complex communication between a vast component ecosystem than this approach starts getting complicated and bug prone. From that reality our unidirectional data flow comes into stage:

Until here nothing new, but what if we take the concept and apply it using react context and hooks!? That’s why you here!

Main concept

The main highlight by now is our great and new friend react hooks, and your consequently functional approach:

Hooks are a new addition in React 16.8. They let you use state and other React features without writing a class.

Then the center idea is to use the context API together with useContext and useReducer hooks to make our store available to our components.

import React, { createContext, useContext, useReducer } from 'react';

export const StateContext = createContext();

export const StoreProvider = ({ reducer, initialState, children }) => (
  <StateContext.Provider
    value={useReducer(reducer, initialState)}
    children={children}
  />
);

export const useStore = () => useContext(StateContext);

We export from this file source code here a StoreProvider (responsible for making the context/store available in the application), that receives:

the reducer function with the signature (state, action) => newState;
application initialState;
and the application content (children);

And the useStore hook that is responsible for getting the data from the store/context.

Even though the nomenclatures are different from now on I’ll reference our context as store, because the concept is the same and we can easily associate to our well known redux architecture standard.

The beauty relies on this simplicity:

StateContext.Provider receives a value object (your current state);
useReducer receives a function: (state, action) => newState and an initialState then any dispatch made from our app will pass here and update our application current state;
useContext get our store and make it available in our application!

All the rest is just code organization and minor changes, nothing to worry about :)

Going into details

As a proof of concept, I’ve done this basic todo list application, check here the source code and here the live implementation, it’s a basic interface that contains a couple of component and the current state tree so then we can see the state modifications over the time.

The project structure looks like this:

The structure is pretty straightforward (action as we’d normally do in a redux application), I’ve moved the initialState from the reducers, because reducer is about state modification and not definition, besides that the store folder contains the already discussed react context / hooks implementation.

The reducer file has a quite different design:

import * as todo from './todo';
import * as types from 'actions/types';

const createReducer = handlers => (state, action) => {
  if (!handlers.hasOwnProperty(action.type)) {
    return state;
  }

  return handlers[action.type](state, action);
};

export default createReducer({
  [types.ADD_TODO]: todo.add,
  [types.REMOVE_TODO]: todo.remove,
  [types.UPDATE_TODO]: todo.update,
  [types.FILTER_TODO]: todo.filter,
  [types.SHOW_STATE]: todo.showState,
});

The point here is just to avoid those huge switch statements usually seen in reducer functions with a mapping object, so basically for every new reducer we just add a new entrance in the mapping object.

But again, it’s all a matter of implementation the requirement here is that the function needs to have the (state, action) => newState interface as we’re already used to with Redux.

And finally but not least our component subscribing to the store:

import React from 'react';

import { useStore } from 'store';
import { addTodo, filterTodo } from 'actions';

import uuid from 'uuid/v1';

import Button from '@material-ui/core/Button';

export default props => {
  const [{ filter }, dispatch] = useStore();

  const onClick = () => {
    dispatch(addTodo({ id: uuid(), name: filter, done: false }));
    dispatch(filterTodo(''));
  };

  return (
    <Button
      {...props}
      variant='contained'
      onClick={onClick}
      disabled={!filter}
      children='Add'
    />
  );
};

What comes next

The next steps will be related to middlewares and type-checking, how do we work here? Technically the middleware is a function called just before the dispatched action reaches the reducer, so the createReducer function above is a great place for that, and what about type-checking!? Typescript on it! And see you soon!

Cheers!

References:
https://github.com/acdlite/react-fiber-architecture
https://reactjs.org/docs/reconciliation.html
https://reactjs.org/docs/hooks-intro.html
https://github.com/vanderleisilva/react-context