search

scaife-viewer / scaife-viewer.org

Scaife Viewer project website
https://scaife-viewer.org/
1 stars 0 forks source link

Organizing scaife-viewer components #2

Closed jacobwegner closed 3 years ago

jacobwegner commented 4 years ago

The Scaife Viewer team has been having some discussions in Slack and within https://github.com/scaife-viewer/scaife-skeleton/issues/60 about how to organize repositories and structure reusable packages to help build out individual sites.

"Key Repositories" has a pretty good overview of the existing repo structure.

I have a few ideas that I'd appreciate further discussion around:

1) Merge scaife-skeleton and scaife-widgets into a frontend repository

We can release individual NPM packages from scaife-viewer/frontend, but work out of a single repository.

2) Create a scaife-viewer/backend repository

This repository would house reusable bits for ATLAS or CTS backends

3) Rename scaife-viewer/scaife-viewer as scaife-perseus-org or sv-pdl

This makes it clearer that the repository is geared towards a particular site. Over time, we can factor things out of sv-pdl into frontend and backend so that sv-pdl truly contains the "site-specific" functionality. This can also be done for other sites based on / forked from scaife-viewer/scaife-viewer.

4) Provide guidance on building a new site using frontend and backend

Initially this could literally just be some walkthroughs at https://scaife-viewer.org to help someone get started (and would be a good reference for our team to use as well); eventually we might end up with something like a scaife-viewer/cli repo where we ship a small CLI to help stand up site scaffolding.

jacobwegner commented 4 years ago

@paltman and @jtauber: Please see some of my initial ideas above; I'm open to other naming conventions or naming suggestions, but I think separating our "building blocks" for FE / BE into two separate and explicitly named repos is important to help us refactor existing scaife-viewer 1.0 sites into 2.0 sites, and helping share code across 2.0 sites (sv-mini, explorehomer, digital-sira, etc).

paltman commented 4 years ago

@jacobwegner I think this is a reasonable solution. Some prior art for monolith repos for frontend are: React and Babel

paltman commented 4 years ago

@jacobwegner as I think about this though, isn't the "Scaife Viewer" by name "frontend" where things like Atlas are the "backend". Not sure it makes sense to have something named "Viewer" as having backends. In other words, I see Scaife Viewer and ATLAS as frontend and backend so I'm not sure what it means to have scaife-viewer/frontend or even having ATLAS in the scaife-viewer organization.

jacobwegner commented 3 years ago

As an update, we currently have:

scaife-stack was used to spin up beyond-translation-site.

Still hoping to loop back around on the "parent" scaife-viewer repo.

In the future, these types of discussions will be conducted via https://github.com/scaife-viewer/scaife-viewer.org/discussions