CUBA Platform Roadmap 2018

Announcements
#42

A bit late to the party but thrilled to see the fatures list.

Already used the DnD add-on in a custom GUI component and it is pretty good. Also waiting eagerly “components based on other components”, because when you go the programmatic way for the UI (when declarative is not an option), it is significantly more difficult than the standard way.

For multi-tenant, it’s yet a good thing to make the single database case easy to code. The fact is, as a developer choosing single or multi database that is generally imposed to us, especially for SaaS. And regulatory environment should be taken into account.

In Europe with GDPR for instance I have to guarantee my clients the highest safety and security possible for their data (article 4), which means among other things segregation of data between clients. More generally, there is a worldwide trend of protecting client data like gold (ask Mr Zuckerberg).

Months ago I started a prototype and even if I could not push the research too long I would not say it is an unreachable objective. Combine 2 things: the tenantId session parameter, and changing CUBA main Datasource to be like the TenantsRoutingDatasource of the current proposed approach. And ballpark you have the solution.

Of course then there is (probably quite of) work to manage the fact that CUBA main connection is now dynamic (cached data, build process, etc.).

Michael

1 Like
#43

It could also mean that you have to go a step further and segregate also your application infrastructure wise. Because if it is possible to somehow compromise the app server, it will be very easy to get on all customers / tenants data. Therefore it might also be necessary to run different app instances and segregate on a infrastructure level (multi-db-multi-app).

I don’t see a clear difference in the two single-db-single-app-tenant and multi-db-single-app from this regard, because the attacker in both cases just has to have access to the single application…

Probably don’t concentrate too much on this made-up and very hard to achieve multi-db-single-app solution and invest more time in other security related parts through threat modeling is more beneficial for the business and also for the user.

Bye
Mario

#44

From the GDPR point of view you might be right, but there are a lot of other reasons for multi-db-single-app. Imagine having 100 of small databases having identical structure (same schemas, same tables struct, different data) - and these 100 dbs are accessed by the same tenant. What is the purpose of having 100 tomcat instances for every db, if it could work with a single app and dynamically connections to the dbs? Imagine the cost for the hosting server in this case, the client won’t be happy. It’s not practical for scaling. If the client’s business grows and it needs another bunch of 50 dbs the cost grows astronomically.

#45

Sorry @tudorghircoias but I agree with @mario in this regard…

What’s the main reason for multi-db multi-tenant approach? Security, and security costs money, period.
If your clients demand security, they must be prepared to spend more money.
As Mario said, you don’t have more security just because you have split your user’s data in more databases. For example, if you have a single core app instance, and an attack is performed at that level, an attacker could gain access to ALL your databases, no matter how many are there.
But that’s an extreme case, what about a software bug at the app level that gives access to other databases to a given user? Bugs happen, and given that you rely on code to dynamically select the target database, that code could fail like any other.
Personally, I don’t see any advantage in multi-db tenant approach, without a proper security plan that covers every other area of the solution, you just get a false sense of more security.

Just my 2c, adding to Mario comments.
Paolo

#46

Obviously, one size does not fit all, especially regarding security & safety. Different levels of mechanism address different concerns. This is why this kind of debate is interesting.

What’s the main reason for multi-db multi-tenant approach? Security, and security costs money, period.

You can add safety and flexibility. In the sense that for a particularly demanding client you can for instance propose data replicated over two geographical locations (e.g banks).

If your clients demand security, they must be prepared to spend more money.

Yes, but it does not mean we do not have to maintain the cost at a reasonable level, does it ?

As Mario said, you don’t have more security just because you have split your user’s data in more databases.

Different databases, different files on different servers, different credentials, potentially different locations, all of that contribute isolating an issue if it happens (not only for security). Not the panacea of course, but clearly increases the security. At the cost of simplicity I agree, but it’s a trade-off.

For example, if you have a single core app instance, and an attack is performed at that level, an attacker could gain access to ALL your databases, no matter how many are there.

Accessing to all databases would mean capturing all credentials of all of them, in any case that would be much more difficult than getting one single set of credentials for a single database.

But that’s an extreme case, what about a software bug at the app level that gives access to other databases to a given user? Bugs happen, and given that you rely on code to dynamically select the target database, that code could fail like any other.

Alas, that’s also true with single database, you rely on code in order to filter data by tenantId dynamically, just replace “access to other databases”, by “access to data of other clients”.

The fact is, there is no perfect model for multi-tenancy, it’s a choice that has to be made, and will necessarily involve some trade-off. Here is an article on the topic that I find enlighting.

For now, we have chosen the multi-db path, with one full application by tenant. Most simple to setup, but being costly resource wise, it is currently acceptable with a low number of our clients having moved to SaaS. It has sped up development until there because we do not have to code around multi-tenancy per se, it’s just build & deployment.

Of course the more of our clients will move to SaaS the more build/deployment effort and cost will increase. We’ll see when arriving there. I will be happy to share our experience.

Michael

1 Like
#47

Loving the work the CUBA team is doing so far this year, and lots of promising items to come. I’m currently evaluating a customer who wants to utilize features of WebDAV. I notice that’s listed on the roadmap as a Q2 item. Several components slated for Q2 release have appeared on the marketplace already. Is WebDAV still in the works?

#48

Hi Ryan,
WebDAV component is ready technically, we are preparing it for publishing.
We are hoping to see it live within a month.
Hope this helps!

2 Likes
#49

Any news on the Dashboard component?

#50

Now in cuba we have entity browse, lookup and edit screen, In Cuba 7, is any plan to include the standard view screen? It would be very useful for details view of an entity instance.

#51

Hi Ray,

Dashboard component is currently in development. We think this component will be released in August.
Also we are going to publish this component on Github soon and you will able to try first snapshot version.

2 Likes
#52

Flowable looks even promising where it has Augmented Machine learning components (AI), Case management, Decision management apart from BPMN

1 Like
#53

When is this new data API planned to be released?

1 Like
#54

In version 7.0. We have no exact release date yet.

1 Like
#55

Any update on both the WebDAV and Dashboard components? The last updates were targeting August for these. Is there a revised timeline for their release?

Thanks!

2 Likes
#56

Hi Ryan,

Dashboard component is still in development, I wish we will publish component in the CUBA Platform marketplace at the end of October or in November.
WebDAV component is ready and we are going to publish the component within a few weeks.

1 Like
#57

Thanks for the heads-up Evgeny.

Could you tell us if there will be a feature allowing user to create its own dashboard and save it ?

It appears that 2 months ago, some of our Sales client asked us for a dashboard (speak about timing…). So we had to develop our own version whilst waiting for CUBA add-on.

Our plan is to merge our work with dashboard add-on when available.

If customisation feature is coming we can make our clients wait for it, otherwise we will have to develop it.

1 Like
#58

Hello! Please tell me when you will add Public Registration in MarketPlace?

#59

Another question.

There was a sentence or two on the roadmap that said the Portal team was going to allow for different UI framework rather than just Polymer. Is this still planned? I was hoping to use Angular.

I guess I could just build a separate project and just talk to the Cuba app through REST services, but it would be great if we could have client and engine in the same project.

#60

In fact, React support is already available in the front-end module since 6.10. We’ve not announced new documentation on that but the functionality is ready and you can use it right now in Studio 6.10.

image

1 Like