3 ms·

This technique never ends well. When your service interface is some untestible semi-script language your clients will hate you. Nice work on building an interp

by alttab 10y ago

This technique never ends well. When your service interface is some untestible semi-script language your clients will hate you. Nice work on building an interpreter, but I'd throw the entire SOA book at you for deploying this in a production environment. I haven't even addressed stability, latency and load of programmable Web interfaces, or security.

epoberezkin 10y ago
It's out of stock - https://www.amazon.co.uk/Service-Oriented-Architecture-Concepts-Technology-Computing/dp/0131858580 https://www.amazon.co.uk/Service-Oriented-Architecture-Conce... Joking aside, why do you think it is any more untestable than any other batch endpoint out there? The concerns you are listing are all valid and can be addressed.
- alttab 10y ago
  They can be addressed, but you'd have to address them anyway with a simpler interface and it would be less work to do so. This is more untestable because the service that provides the scripting interface needs to have a test bed that is similar to the test bed of an entire language itself. Are there corner cases? Can a client cause a script to loop indefinitely? Is there a test case for every known combination a client would attempt? If so, why not just support each use case explicitly? There are 1000 reasons why being additionally clever causes more headaches than its worth. I'm not too upset about it - because I'm confident those that don't heed this warning will learn the lesson the hard way.
tony-allan 10y ago
I agree that this isn't an SOA architecture. I see this more like an SQL stored procedure where you want to get simple code closer to the data for performance and efficiency. I would like to see some use case thoughts about where this would work better than other alternatives.
- epoberezkin 10y ago
  Thank you. One use case that's already working is an express middleware - allows you to bold on JSONScript on existing express ap in a single line of code. Another is a proxy to manage batch processing across multiple services - going to make it.

by alttab 10y ago

epoberezkin 10y ago

It's out of stock - https://www.amazon.co.uk/Service-Oriented-Architecture-Concepts-Technology-Computing/dp/0131858580 https://www.amazon.co.uk/Service-Oriented-Architecture-Conce... Joking aside, why do you think it is any more untestable than any other batch endpoint out there? The concerns you are listing are all valid and can be addressed.

alttab 10y ago
They can be addressed, but you'd have to address them anyway with a simpler interface and it would be less work to do so. This is more untestable because the service that provides the scripting interface needs to have a test bed that is similar to the test bed of an entire language itself. Are there corner cases? Can a client cause a script to loop indefinitely? Is there a test case for every known combination a client would attempt? If so, why not just support each use case explicitly? There are 1000 reasons why being additionally clever causes more headaches than its worth. I'm not too upset about it - because I'm confident those that don't heed this warning will learn the lesson the hard way.

tony-allan 10y ago

I agree that this isn't an SOA architecture. I see this more like an SQL stored procedure where you want to get simple code closer to the data for performance and efficiency. I would like to see some use case thoughts about where this would work better than other alternatives.

epoberezkin 10y ago
Thank you. One use case that's already working is an express middleware - allows you to bold on JSONScript on existing express ap in a single line of code. Another is a proxy to manage batch processing across multiple services - going to make it.