Open davidvoler opened 5 years ago
Thanks, @davidvoler . Really interesting.
This may be useful in the more sophisticated use cases (e.g., collaborating in a team). Let us discuss this.
For the simple use case (a scientist doing some analysis at her laptop), having fewer processes will have advantages (e.g., accessing all components from the same REPL; being able to debug more easily; better performance with large datasets).
So, in my opinion, it may be better to keep this option of microservices in mind, but implement the first versions without it.
What microservices should we have in VIP-REPL? An alternative to microservices would be that all functionality is implemented by a single process.
Here is an initial suggestion for microservices.
From VIP_REPL point of view: In development: When you make an API call to VIP-REPL ((let chart = vip-r-create-chart [ :pie-chart, data, legend]) ;; vip-repl-chart is created, static page is generated (show chart) ;; 1. server start if not already started 2. WS Starts, 3. Web development starts if not already started ) In production: All microservices will be started explicitly using a command line, docker-compose or helm chart for Kubernetes. A configuration file will indicate to the API to interact with these microservices.
We might want to add or remove microservices, for example, do we need a REST server?