During several Re-architecture discussions, different options have been evaluated for the infrastructure of the Dataverse frontend (S3, Dataverse Payara server, Docker, etc), as well as for its deployment (.zip vs .war, pull vs push, bash and Python scripts, Jenkins, etc).
Although being a static website there are several options for its deployment and infrastructure, we need to offer a standard solution to ease the installation process. For example, when planning to deploy the frontend to a QA environment, we have had to evaluate different options on the fly.
The goal is to define a standard design for the infrastructure of the Dataverse frontend SPA and configure the necessary automations that allow the application to be easily deployed to the chosen standard infrastructure. For greater adaptability, It is important that the chosen solution does not exclude the application from being deployed in different ways.
Once the design is established, it should be applied to the QA environment, since it should mirror a production SPA environment. Until this issue is completed, we will use alternative ways to deploy to QA in order not to block the QA phase of the workflow.
Possible approach to follow:
We can offer a transition solution for people who want to run the SPA alongside Dataverse in an all in one solution - serve it via payara through proxypass but also offer a clean sheet deployment guide such as S3 or some other method, similar to how we described our server architecture: start out with all components on a single server and as your needs grow you can place different services, ie db, solr, payara, on different servers or even in a cluster.
What kind of user is the feature intended for?
Dataverse frontend developers and QA
What inspired the request?
Working on #5
Discussion with @kcondon
What existing behavior do you want changed?
N/A
Any brand new behavior do you want to add to Dataverse Frontend?
N/A
Any related open or closed issues to this feature request?
mreekie
commented
1 year ago
Overview of the Feature Request
During several Re-architecture discussions, different options have been evaluated for the infrastructure of the Dataverse frontend (S3, Dataverse Payara server, Docker, etc), as well as for its deployment (.zip vs .war, pull vs push, bash and Python scripts, Jenkins, etc).
Although being a static website there are several options for its deployment and infrastructure, we need to offer a standard solution to ease the installation process. For example, when planning to deploy the frontend to a QA environment, we have had to evaluate different options on the fly.
The goal is to define a standard design for the infrastructure of the Dataverse frontend SPA and configure the necessary automations that allow the application to be easily deployed to the chosen standard infrastructure. For greater adaptability, It is important that the chosen solution does not exclude the application from being deployed in different ways.
Once the design is established, it should be applied to the QA environment, since it should mirror a production SPA environment. Until this issue is completed, we will use alternative ways to deploy to QA in order not to block the QA phase of the workflow.
Possible approach to follow:
We can offer a transition solution for people who want to run the SPA alongside Dataverse in an all in one solution - serve it via payara through proxypass but also offer a clean sheet deployment guide such as S3 or some other method, similar to how we described our server architecture: start out with all components on a single server and as your needs grow you can place different services, ie db, solr, payara, on different servers or even in a cluster.
What kind of user is the feature intended for?
Dataverse frontend developers and QA
What inspired the request?
What existing behavior do you want changed?
N/A
Any brand new behavior do you want to add to Dataverse Frontend?
N/A
Any related open or closed issues to this feature request?
5