Hi all, I am working with Lyrasis to get the patron-facing web catalog up to a point where it is ready to be deployed as a product on a large scale. The goals here are

1. A solid browsing and borrowing experience for patrons
2. Simplicity of deployment and hosting
3. Ease of development and maintainability. This is especially critical with a distributed team that often incorporates contractors. Complexity should be avoided unless it adds significant value.
4. Theme-able UI.
5. Support various auth protocols (like SAML) for university clients.
6. Integrate analytics so libraries (and providers like Lyrasis) have a clear picture of patron engagement / usage.
7. Bug reporting, so the developers involved in the project know what’s going wrong and how often.

This is how I suggest we get there:

1. Organizational changes.  (Voted against for the time being) opds-web-client, circulation-patron-web and circulation-web are highly related but live in three separate repositories. Bringing them together into one monorepo would make sense so the packages can be developed simultaneously without relying on buggy "npm link", which I have never consistently gotten to work. In the future, this will also allow us to reassess the division of the packages and how they depend on each other.
2. Strip unnecessary complexity.
   1. We currently use Redux mostly as a client-side cache of data requested from the server. This functionality is better supported with a dedicated cache like [SWR|https://swr.now.sh/], which is specifically built for that purpose and thereby offloads the complexity of managing a cache (which is notoriously difficult). By moving to SWR or similar, we could remove ~70% of redux code, relying on it only for actual application state instead of server data.
   2. Remove the custom server and render on the client. This also means deployment is as simple as hosting some static files. There has been some discussion on [github|https://github.com/NYPL-Simplified/circulation-patron-web/pull/77] which is now to continue in this Jira issue: https://jira.nypl.org/browse/SIMPLY-2680
   3. Our build configuration (webpack, babel, typescript, eslint and jest configs) are all custom. We don't do anything special that requires this custom setup, so we should try to offload that complexity to a package like Next.js or create-react-app.
3. Theming. We'll want to re-think parts of the design so that the app is easily theme-able. As in, what theme options do we want to expose? How do we maintain accessibility while allowing themeing? My personal feeling is that moving to a mostly white background while allowing libraries to choose one or two accent colors and fonts would make sense, as well as providing logo assets etc.
4. Auth. Replace custom auth code with a standard auth package that supports SAML, Basic, OAuth, etc and works well with whatever data-fetching strategy we choose (like SWR mentioned above). This should offload significant complexity.
5. Analytics. Track user events throughout the app such as views per book and collection. Integrate this event tracking with the existing Google Analytics tracking in the circulation-manager.
6. Bug reporting. Integrate a 3rd party bug tracking software like Sentry. This should be integrated across the mobile, web and circulation manager. 
7. Continuous Deployment & Devops. Every branch and PR should have its own build and url so it can be easily tested in QC. 

I know this is a lot, and we don't have to discuss all of this here. Let me know your high level thoughts, and then we can start to break these out into separate issues for more specific discussions as need be. Also, if there are any NYPL projects that interact with this, we should sync up on what those are so we can coordinate efforts. 

In addition, these are a few ideas I have for the future that may be worthwhile to express in case you all have been thinking about something similar:

• Make the app installable as a Progressive Web App or Electron app for each library/deployment.
• Once it has been made installable, would it be possible to incorporate reading functionality so it is feature-complete with the SimplyE mobile app?
• Update the CM code so that the endpoints are more concise. It seems like the endpoints are a bit bloated right now... I receive multiple megabytes of data for one book in some instances.