I want to separate a part of the application to be stand-alone and act as a microservice. I know the REST functionality, but wanted to know if there are some other components that will help with this task or if there is a “CUBA-way” of achieving this. Maybe the EntitySerializationAPI or the EntityImportExportAPI should be used here?
1 Like
Hi @klaus,
So are you planning to access data from one app to the other? Or are you going to sync data between apps?
Regarding the serialization API: are you planning to use it on the client side?
Generally speaking, the generic REST API can be useful for internal integration purposes. But keep in mind that you bind the consuming app directly against the servers internal entity model. If you control producer and consumer perhaps it is acceptable, but one thing to keep in mind.
Cheers
Mario
Hi @mario,
Yes, exactly. One application (#1) should provide data from a big database and is responsible to regularly update this data. The other application #2 is the actual application for the end-user and consumes the data from application #1. Application #2 will send search queries to application #1 and #1 will provide the search results.
Well, whatever works best and is the most straight-forward solution. 
Yes, that’s true and yes I control the producer and the consumer side. I thought of putting the shared entities in a separate repository maybe, so I don’t have to sync the entity classes everytime I make a change.
For now I want to go fast, but don’t lose flexibility. So the tight coupling of the internal entity model would be ok for me now. If the producer application evolves and other applications want to use the data, then I could still improve the API.
Thanks for your answer!
So in this case, are you planning to keep a copy of the data in app #2? Or would you want to do HTTP interactions every time a user picks something? Generally, in a distributed (microservice) based system you have those two possibilities when it comes to splitting the data into multiple systems.
It depends a little bit on your requirements what you want to do with the data from #1 in #2. If you have entities in #2 that should somehow link to data from #1, then you probably need some form of persistent representation in order to keep the ability to link on the JPA side, but also to not lose all the beauties of CUBAs standard functionality, like: Filtering on that “copied” entity, security, display the instance name of the entity from #1 etc.
From your explanation it seems like this is your use-case. Back at a previous project we had a similar situation where we copied master-data from one system that kept the master data to the apps, that were using them.
If you are going down the route of “HTTP interaction” every time a user does some interaction with a #1 entity in #2 on the other hand then you can e.g. look into GitHub - aleksey-stukalov/github-statistics: The project demonstrates how to use external objects provided via REST API in a CUBA Application as an example. There you can look at how to use an HTTP client (in this case retrofit). There is no special CUBA sauce to it in here.
Cheers
Mario
Ok, I don’t have to make a mystery out of this. The provider #1 holds data about companies and the consumer #2 is an application, where users can maintain their own costumers and suppliers. When a user in #2 creates a new costumer/supplier and enters the name the system will suggest found companies from #1 and will recommend to auto apply the found data for the company. You could call it a convenience feature, so the user doesn’t have to enter all the company data for the added costumers/suppliers.
Also I have the idea to periodically check the data and notify users who have outdated company data. Users can modify this data on their own, so yes, it is copied.