Thanks. This is a fair point. I made up the example only to illustrate the idea. Since Stripe is considered some sort of benchmark here I was curious to see how they tackle all the learnings they will have over time...I feel it is very hard to think through all the future cases especially when you are just about starting out with your product.
For example, in financial services and insurance, regs change and what data we need to collect change and sometimes their dependency will change. I am curious what's companies that have grown substantially had to do to their APIs.
Can someone share how they handle versioning in their API when it comes to data model changes? For example `POST /users` now takes a required field `avatar_url` but it was not part of `v1`.
Since this field is validated in the DB, merely having `v1` `v2` distinction at the API layer is not sufficient. So I was thinking we will have to either 1) disable DB validations and rely on app validations or 2) run two separate systems (e.g., one DB per version) and let people 'upgrade' to the new version (once you upgrade you cannot go back).
Even though people refer to Stripe's API versioning blog, I don't recall any mention of actual data model changes and how it is actually managed
Can someone confirm if this can be used in a multi-tenant saas app environment?
Customers want to have their own SSO setup or user roles and instead of providing all those functionalities in the app, can we use Keycloak in front and the Customer can manage their own users/permissions via Keycloak?
So in essence:
Customer A: Have 5 users (login / password), 1 admin and 4 regular users -- admin can add or remove users
Customer B: Have an LDAP and would like to authenticate using it
Congrats on the launch. Your API looks very clean.
Do you support NuBank in addition to the big banks? I have heard NuBank has pretty aggressive anti-scraping approaches. Not sure if you support them or plan to in the near future.
Could you please share your reasons for looking at alternatives to Drools? I am in the process of evaluating Drools and it will be great to understand why people move away from it.
In case people from this project are still checking this thread. I am actually looking into Drools at this moment so the timing cannot be better...
I have a few questions:
1. Is this a new skin/interface for existing tools like Drools / jBPM or re-implementing that functionality?
1a. If new skin: is it fair to say, once the business application is built (there maybe bugs along the way due to the stage of this project), since the foundation is Drools / jBPM, we can expect production quality that we would expect out of Drools/jBPM?
2. What is the KIE Group? Is this owned by Redhat? It is very hard to tell by reading the footer.
3. Does the team provide consulting services to use these tools for an enterprise adoption?
For example, in financial services and insurance, regs change and what data we need to collect change and sometimes their dependency will change. I am curious what's companies that have grown substantially had to do to their APIs.