We are on a greenfield design phase for a Web application for an enterprise, where we will be utilizing Dell Boomi for the first time. In other words, Boomi will be the iPaaS solution that the company will be moving towards, and the web application will be the first app that should be making use of Boomi.
Short introduction about web application: There is a need for BE api's for a consumer type mobile application. Very shortly, the application will allow users to view and edit some data that rests on Salesforce. You can imagine something like you see/edit your account details and settings. 5-6 pager mobile app.
Lets take one example scenario, where users read/write their account information such as contact data.
The question is a generic architectural design question. For these kind of scenarios, will we need a seperate Backend(BE) application or, shal lwe use Boomi processes.
Theoritically boomi processes seems to be quite capable of doing something like this. Yet Boomi does not provide any platform where you can store your transactional data. Another concern is that if we have too much complex of processes that are implemented at Boomi WF, I believe we may end-up in the same mistake that many enterprises did with ESB's, by implementing Business logic on it and make the maintanence of it a nightmare.
Although not an expert for an iPaaS scenario, my instinct suggests to have some kind of seperate application implementation that should be hosted on a Platform (like Azure) that will playy the role of BE services. So that keep the WF layer thin, limited to integration logic only. (like you receive the data from Saleforce, pass it through your BE, and return the result that is received from BE).
I am aware that it requires more detail and study to take such a decision, but I would expect some examples or ideas to support us about the options that we have on the table.