You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 22, 2022. It is now read-only.
I had an idea while at APIStrat to attempt a microservice "optimization" by means of code-on-demand and hot code loading.
Terms:
Microservices: an isolated service with a single responsibility and its own data store running at or behind a specific IP and managed independently of other services.
Code-on-demand: one of the optional constraints of the REST architecture that allows an endpoint to provide the code necessary to use or interpret a resource representation.
Hot code loading: the ability, as in Erlang, to add or change a running program or module without a full deployment.
Erlang natively supports hot code loading by means of its use of modules as compilation units. F# does not have this capability natively, but we can simulate hot code loading in part by recompiling based on file changes (see reload). A better solution might be to build infrastructure to load referenced modules into an AppDomain and then repeat and migrate to new AppDomains as new code is compiled and loaded. This approach has the benefit of adding additional security options.
The code on demand aspect would allow a microservice to provide representations either as source code + configuration or its standard JSON, XML, etc. formats. For consumers asking for source code + configuration, those consumers could optimize by re-compiling and consuming the microservice's behavior and data itself. You will immediately recognize security issues here, but this may be useful for internal services. For external services, code-on-demand may provide the source or assembly (binary) that may be used to consume the microservice. Even this latter option comes with security issues, i.e. do you trust this provider enough to compile and run their source or reference their compiled assembly in your application?
Note
For the internal-use microservice optimization to make any sense, Freya would need to support some form of an API Gateway and load balancing. Load Balancing by means of OWIN is a possibility, so the Microservice bit may be completely out-of-scope.
The text was updated successfully, but these errors were encountered:
I had an idea while at APIStrat to attempt a microservice "optimization" by means of code-on-demand and hot code loading.
Terms:
Erlang natively supports hot code loading by means of its use of modules as compilation units. F# does not have this capability natively, but we can simulate hot code loading in part by recompiling based on file changes (see reload). A better solution might be to build infrastructure to load referenced modules into an
AppDomain
and then repeat and migrate to newAppDomain
s as new code is compiled and loaded. This approach has the benefit of adding additional security options.The code on demand aspect would allow a microservice to provide representations either as source code + configuration or its standard JSON, XML, etc. formats. For consumers asking for source code + configuration, those consumers could optimize by re-compiling and consuming the microservice's behavior and data itself. You will immediately recognize security issues here, but this may be useful for internal services. For external services, code-on-demand may provide the source or assembly (binary) that may be used to consume the microservice. Even this latter option comes with security issues, i.e. do you trust this provider enough to compile and run their source or reference their compiled assembly in your application?
The text was updated successfully, but these errors were encountered: