Minimal Deployable Product

[narendasan]

In order to deploy groot, the specified features need to be:

1. We need to be able to add new members
   • This implies we need some sort of members service built
2. All static content needs to be up
   • As I see this we can deploy this hard coded into one of our frontend services or even one that we are going to scrap after groot comes online as static content until a full static site generator comes online.
   • This includes linking to mailman and the SIG sites which from what I gather is not too difficult especially since it seems the sites are hosted independently.
   • If we go with hardcoding this NEEDS to be temporary. Eventually we would want SIGs coming under the groot umbrella, We also want content to be easy to change which is not the case when you need to dig through code to change site content.
3. We need LDAP support?
   * It would be nice to use University Auth for a lot of the site. But we also want a copy. So I am not sure this is necessary for deployment but we need some sort of auth. This is more of a discussion point

From the above requests I think what we need to build this summer is:

1. A frontend service for desktop at least
   • Stack is the implementers choice. All it needs to do is be able to query the API gateway and look better than the current ACM website. It should also have all the static and SIG content from the current site in static pages at least for V1 and support for signing people up.
2. A API gateway
   • We need an API gateway that is scalable enough to handle future services(we don't really want to rewrite this over and over). From my research I have found good implementations in lua (kong - http://getkong.org, what I am leaning towards), go (gin - https://gin-gonic.github.io/gin/) and node (loopback).
   • Ideally this contains the auth for the site, so we don't need to rewrite that logic over, some of the load management and support for inter service communication (some cache will be necessary for this)
3. A User Service
   • From what I see I think this is the only service we need to implement before school. The schema/DB can be completely different from liquid since it looks like now we are migrating the data. Required attributes are those used for signup. Whoever takes this up, feel free to choose the framework but then be prepared to serve as support for any future updates depending on how archaic the framework is. All that needs to be exposed is the API hooks for the API gateway.

It doesn't seem like there is a lot that we need to do so we should be able to get this going before school. But we need at least one or two people on each of these if they are going to get done. Individual issues will go up for each of these so for any non architecture specific convos look there until a long term structure is built since it looks like these might be separate repos.