Using microservices with Uvendia
Posted on October 14, 2019 by Sherlon Gerard
Uvendia E-commerce can be used in a Monolithic architecture
but also in a Microservices architecture.
Microservices is an architectural style that structures an application as a collection of services that are:
- Highly maintainable and testable
- Loosely coupled
- Independently deployable
- Organized around business capabilities
- Owned by a small team
Separate Database
When installing Uvendia you can choose to have a separate database for your e-commerce data. One of the main reasons to have a separate database is Performance.
CMS systems like Umbraco usually has a very high data access rate. So, it is better to separate your e-commerce database in a situation where you have multiple API services interacting with your e-commerce data.
By separating your e-commerce data from your CMS, you also will increase the maintainability and testability of your application.
The illustration here below proposes a basic design case in a situation where you have multiple (API) services interacting with your e-commerce data.
Uvendia E-commerce Microservices proposal
Uvendia Service Bus
As mentioned before this is just a proposal architecture. Of course, you can design your Microservices architecture the way it suits your business domain it best. The Uvendia Service Bus is a software design which connects all the services together over a bus like infrastructure. It is also called Enterprise Service Bus (ESB). It acts as a communication center by allowing linking multiple services, applications and data all together.
Message Broker
An ESB is a reliable and secure platform for (a)synchronous data and state transfer. Data is mostly transferred between different applications and services using messages. Messages are sent to and received from queues. Queues enable you to store messages until the receiving application is available to receive and process them. A message is in binary format, which can contain JSON, XML, or just text. The most popular message brokers are: Kafka, Azure Service Bus, NServiceBus and Amazon SQS.
Use case
For instance, orders need to be exported to a Backoffice system for further processing. The reference to the new order or the whole order data (as a json message object) can be posted on such a queuing system. The OrderExportService is always listening the queue for new orders. When a new order arrives on the queue, the OrderExportService picks it up and processes it accordingly.
Or instead of listening, the bus can be sending new orders data directly to the OrderExportService. There is no Right-or-Wrong, it is all about implementanting the right solution for a specific scenario.
Although I prefer a situation where the bus has no dependency with external serverices, but sometimes there are occassions in a real world scenario where it is impossible to be independent from an external system.
As long you can explain why such desicion has been made after considering all the options, you are good to go!
Nuget Package
For a Microservices approach we recommend you download and install Uvendia.Importer package from nuget.org. It has a lightweight API you can use to easily import a bulk of products into your database. Make sure your connection string is named: uvendiaDbDSN.