Microservices in Crossbar

#1

Greetings again,

While I was surfing, I happened to come accross this article

https://www.nginx.com/blog/time-to-move-to-a-four-tier-application-architecture/

which illustrates 4 different tiers in the software architecture

The Four-Tier Engagement Platform Makes Delivery Its Own Tier

Considering the image illustration above,

how would this be applied within Crossbar?

Just top of my head and my limited knowledge,

if I’m assuming that I will have IoT project with devices that serve commercial transactions for different customers (Vending Machine example)

Client Tier - web app, devices

Delivery Tier - CB components that sanitise presentational data

  • *.list_devices

  • when message received, it will call *.devices.get and do the sanitisation on the return value and return it to the client

Aggregation Tier - CB components that take care of security (filtering?). E.g., Vending machine at Coles can only access Coles data.

  • *.devices.get

  • if it receives coles.devices.get then it will call app.devices.get with filtering option ({domain: ‘coles’})

Services tier - CB components that directly communicate with DB mostly taking care of CRUD operation

  • app.devices.get

So if I visualise the operation of a vending machine manager at Coles getting all the devices that Coles have,

Client Tier . --coles.list_devices()–> Delivery Tier(registered *.list_devices)

Delivery Tier --coles.devices.get()–> Aggregation(registered *.devices.get)

Aggregation --app.devices.get({domain: coles})–> Services Tier(registered app.devices.get)

But wouldn’t this cause an overhead in Router? one call will have to travel through different components. or is it going to be fine if all components live on the same environment?

or is it wrong to have business specific domain variation in URI?

Crossbar is amazing but I don’t think I’m doing amazing at using it :frowning:

Thanks for reading may the force be with you

0 Likes