We talked about making the spa manager be a single instance per domain that can pull from multiple API endpoints then group the paths into a single view and display the versions deployed at each environment.

related #77

Add test framework and a few baseline tests in each package. More tests can be written in the future, this is just about laying the foundation.

E2E test for spa manager.

Tools like Renevate are making it hard to see actual daily update notifications of commits etc by our team across geos because of all they get buried in all the auto-process notifications.

We should try to run these on a weekly schedule, not daily.

Log anytime a user performs a deploy, or delete operation. This can be just to a log file at the beginning, but could be moved to a database later.

• init

A generic interface for authorizing specific actions in spaship, such as deploying a spa etc. This can be plugged in with specific implementations, for example rover groups.

The user should be able to generate/revoke a apiKey
The API key has expire date as optional

This is a post MVP feature.

@sayak-sarkar would start working on it as he is done with API keys.

I know using following way to connect mongodb is easy for use

mongodb://db1.example.net,db2.example.net:2500/?replicaSet=test&connectTimeoutMS=300000

But we will use the MongoDB instance with authentication. it means there should be some secret inside
In the OpenShift, we always store them into single value

example:

• MONGODB_USER
• MONGODB_PASSWORD
• MONGODB_DATABASE

It is very difficult to put them together into one string with OpenShift secret mapping.
Please read each value from environments

This is post MVP feature.

All packages are using same version now.
I think it should be something wrong in lerna config.

I'm plan to fix it in next week.

each package could publish automatically when a new tag created

Have InfoSec check security of Auth*

We are only fetching SPA list from one environment.
We have to fetch the environments list , check how many environments they have, and fetching SPA list from each environments

• set up mock webroot using mockfs
• make requests to path-proxy and verify the requests are proxied to the correct origin (local mock disk, or remote env)
• try variations of URL paths involing underscores, similar to the tests for flatpath

• Add script for /deploy and /list

• Update the script with API key

Tools: newman

We should setup httpd make all requests(not include static files) hit the index.html
to make the history api work

Both sync-service and path-proxy refer to the same environment variable for their port setting, SPASHIP_PORT. I propose removing that var and creating SPASHIP_API_PORT and SPASHIP_PROXY_PORT.

deploy.js was slapped together for the proof of concept demo and needs to be rewritten. We need to make it easier to understand and easier to test.

Need to refactor path-proxy hard coded variables into a config file.

Test scenarios spanning the full usage spectrum, such as:

• launch sync-service & path-proxy, spaship init, spaship deploy, and make sure the deployed app resolves correctly
• others?

Currently, path-proxy needs disk access to the webroot in order to build its list of SPA directory names. It then refreshes the directory list every 750ms. I'd like to consider changing this behavior slightly, by adding an endpoint to sync-service that returns the directory list. This would allow path-proxy to fetch the directory list without direct disk access, so we could run it on a different host for example.

path-proxy example

- let flatDirectories = await fsp.readdir(config.get("webroot"));
+ await fetch(`${syncServiceUrl}/spaDirs`);

path-proxy needs some basic documentation in the README

The manager becoming to more and more complex, the state management looks been a critical issue we will meet soon.

I have familiar with redux with react. but feels it has too many duplicate code.
Maybe mobx is good a choice.
I'll do some research for this part

Rename a few packages to make things clearer.

sync-service → api

• rename npm @spaship/sync-service package to @spaship/api
• rename repo directory: /packages/sync-service to /packages/api
• bulk rename all sync-service references within the repo to api

spa-manager → manager

• rename npm @spaship/spa-manager package to @spaship/manager
• rename repo directory: /packages/spa-manager to /packages/manager
• bulk rename all spa-manager references within the repo to manager

path-proxy → router

• rename npm @spaship/path-proxy package to @spaship/router
• rename repo directory: /packages/path-proxy to /packages/router
• bulk rename all path-proxy references within the repo to router

other tasks

• rename github labels
• publish new packages to npm
• npm deprecate old packages, leave a message about the new package names

It might be worth investigating using fastify instead of express. It has a lot of advantages and also a Red Hatter is one of the maintainers.

Right now autosync will cache any HTTP response. It should be adjusted to only cache when the response is a 200.

We're using axios which followed redirects (up to 5 redirects in a row, by default), so we don't have to worry about handling 300s. The response we get from axios should be a 200 if the request was successful. If it's not, drop it and leave the existing cache in place.

Great job with the contributor guide! But I have a nice container platform at my disposal and I want to ship some SPAs. Let's have a user's guide ... pretty please? :)

We should add a logging system to enforce consistency and provide logging features. Right now I'm liking winston a lot. Definitely open to other options though.

Checklist:

• added logging to common
• added logging to sync-service
• added logging to path-proxy

You should be to delete a spa via the API

@Jared-Sprague, @kunyan would be looking into it as he would be working on addition and similar API endpoints.

@mwcz Was talking to Chris and others during the trip and there is some desire to make Spandx part of the SPAship suite of tools for frontend devs. This issue is to discuss the pros and cons of pulling in Spandx under the SPAship umbrella.

Once #61 is done, then add it to the UI for authentication.

• Code of conduct
• Contributing guidelines
• Issue templates
• Pull request template
• Update all documentation (READMEs, Wikis, et.al.)

Each SPA should have a configuration field for who owns it. It could be an email address for an individual or a team mailing list.

Need to decide what to name it. I'm thinking owner but I'm very open to other ideas.

Here's a mocked up example:

name: My SPA
path: /my/spa
owner: [email protected]

(re SPASHIP-109)

Talking to Chris, he suggested that we add a feature to automatically inject chrome SSI includes based on regex, like putting header right after the tag. This would be optional and people could still use SSI directly. This would also be per-instance, so you would define regex includes for access.redhat.com instance of spaship.

This is related to #163

Create REST endpoints for creating, fetching and deleting API keys. The functions implementing key creation and deletion already exist in sync-service/lib/db.apikey.js, they just need to be wired up to URL paths in express.

Here's my thoughts on endpoint paths and HTTP methods.

Notes
¹ The function deleteKey(apikey) function wants you to pass in the HASHED key, not the original key (since SPA manager does not have access to the original key when you click "Delete key"). That's why the querystring param is hashedKey and not key.
² This should return a JSON object describing whether the key creation was successful or not (key deleted successfully, or key not found).

Create an express middleware function that verifies API keys, and apply that function to every express endpoint that needs auth.

Note, https://github.com/spaship/spaship/blob/master/packages/sync-service/lib/db.apikey.js already provides functions for creating, storing, and verifying API keys. This issue is asking for an express middleware function that uses db.apikey.js to enforce API key auth on certain endpoints. The function getUserByKey is the best one to use for validating that an incoming API key is valid.

It should work something like this:

1. HTTP request comes in
2. If no Authorization header, return 401
3. If Authorization header exists and is of the form Authorization: APIKey MY_API_KEY then get the value of MY_API_KEY and pass it into db.apikey.getUserByKey("MY_API_KEY") to determine if it's a valid key. Proceed to step 6.
4. If Authorization header exists and is of the form Authorization: Bearer MY_TOKEN then get the value of MY_TOKEN and validate it with a JWT validation library.
   1. If the token is valid, take the sub property (we treat this property as a UUID for users) and pass it into db.apikey.getKeysByUser(sub) and proceed to step 6.
5. If Authorization header exists but is not of the form Authorization: APIKey MY_KEY or Authorization: Bearer MY_TOKEN, then return a 403
6. If the function returns a non-empty array, allow the request to proceed (by passing through to the next middleware function). If it returns an empty array, return a 403.

Todo: determine which endpoints need auth.

@Jared-Sprague was telling me about a conversation with @kunyan about environment variables and SPAs. Just opened this issue so that @kunyan and @Jared-Sprague can fill in the details.

Now. the init.html is not in scm.

I suggest we should put it into OpenShift configMap. then it could be mount into the Pod.
But if you want to mount it to some path, the content of path will be overwrite. that's is why I suggest init.html not put into root path of SPA directory.

I think we could put it into /_include_/init.html.
The chrome snippets could also put into /_chrome_/.
It should not be able to read by path proxy or sync-service list api

We need to provide documentation for users on how to use their API keys.

• document using an API key with the cli
• document using an API key with curl

Opening this issue to have a discussion about TypeScript and whether SPAship should be 100% TS. I recall @kunyan and @sayak-sarkar both bringing up TS in past discussions.

The question to answer here is: Should we be writing this tool in TypeScript?

For fun, I've been converting a very old side-project to TS and it's been quite nice. I mostly write vanilla JS though, so it would be a bit of a learning curve for me.

In addition to all the typical pros and cons of TypeScript, here are some additional project-specific points to consider:

• spa-manager is already in TS
• sync-service, common, path-proxy, and the cli are already written in vanilla JS
• if we switch, now is the best possible time
• the cli framework (oclif) is nicer to work with in typescript
• some devs (me for instance) are not TS experts

What does everyone think? @Jared-Sprague @kunyan @sayak-sarkar @npatil9

Whether on MP or elsewhere, decide where to host mongodb and set it up.

< THOROUGH DESCRIPTION HERE >

Once #61 is done, then add it to the UI for authorization.

Unit tests:

• lib/background/autosync.js
• lib/deploy.js (pending #47)
• lib/metadata.js

Funcional tests:

• POST /deploy
• GET /list
• POST /autosync/forceSyncAll

The autosync process should be in it's own service since it is a completely separate concern than deploying and listing SPAs

The following need to be updated in the arch:

• add path-proxy
• change name of sync-service
• put auto-sync in it's own service

This interface can be plugged in with different implementations. E.g Red Hat internal SSO.