[e12e]

Perhaps several layers of input data validation? Typically the problem is that you want the client side (ie: javascript) to do form validation for early-feedback to the user, and the back-end to do actual input filtering/validation -- but I suppose one might want to push input-errors/validation-errors as far out towards the input as possible -- also in case of a web of micro-services? Things like allowing only utf8, or maintaining data integrity for relationships (eg: in order to add dependants to a person, those need to be defined with some kind of minimal data, like a social security number?).

I am a bit puzzled as well -- I normally think of this as a problem of synchronizing back-end and front-end -- but then again, if you have a proper SQL-schema, with a thin REST-layer abstraction/API on top, you'd probably have to have other services know about your models in order to do input-validation before attempting to post/insert/update data?

[fmontesi]

What we can do right now is having a microservice for input validation and call it when we need to validate something, both from the client and the server parts. In Jolie, adding calls to a validator for all functionalities exposed by a microservice is easy with courier constructs (http://docs.jolie-lang.org/#!documentation/architectural_com...).

However, if your client application is a web app, that may mean generating a lot of traffic between clients and web server.

In theory, we could make a tool for automatically propagating validation checking from Jolie to client code, but that's a hard problem because some checks depend on information that only the server knows, so sometimes you need to make remote calls anyway. Not all hope is lost, because in many cases a static analysis could tell us what can be safely exported to the client and what cannot.