Move server out of reveal FE

[peterMuriuki]

• This is a continuation of work that's taking place here Make it possible to run the frontend without a backend #735. the next steps; steps that would close this issue is to consider the server as a repo in itself.

The 2 schools of thought around this:

• to create a new repo for the server. This would make deployment and setting up CI/CD eaiser. For the latter it would really not be that significant of a factor. The cons for this would be one more manual thing to check; i.e. that versions of server and version of FE can actually work together. Making changes to either server or FE for cross cutting issues would need one to also be vigilant to make corresponding changes to the other.
• To have this as a monorepo: The con expressed above becomes a non-issue. some extra negligible effort in deployment.
• Other that i dont know.

Some of other things that might be affected by this(This is not exhaustive):

• Add server tests to CI process #738
• github/onaio/ansible-express

[moshthepitt]

@p-netm We need to also consider:

1. that this is not a "Reveal server". This is potentially a server that can be used by any other frontend project that we have - first and foremost being OpenSRP web.
2. Speaking of OpenSRP web, it may help to think of Reveal as belonging in the "clients" directory of OpenSRP web, and so to me it doesn't really warrant having its own "server".
3. Right now this is an express server, but the Reveal frontend should be "server agnostic" i.e. if something like the OpenSRP server can one day replace this express backend then all the more power to us

cc: @cKellyDesign @kahummer

[cKellyDesign]

This is potentially a server that can be used by any other frontend project that we have - first and foremost being OpenSRP web

Agreed. I wonder how might we modularize this tiny backend setup in way that we decouple its logics for utility (aka - a server that authenticates react apps, let's say "gatekeeper-server") from the client (aka - the auth'ing OpenSRP specifically, say "opensrp-auth")?

If we could, this opensrp-auth would definitely be hosted in OpenSRP Web packages, while such a gatekeeper-server seems like it should be agnostic of authentication clients and ideally could accept auth multiple clients. Then both of these could be utilized by OpenSRP Web and Reveal (as their server and auth client of choice).

but the Reveal frontend should be "server agnostic"

Feels like ideally all of these pieces should be agnostic to one another. This doesn't really address the question of mono-repo or not, in fact another ideal would be agnostic to this as well.

@moshthepitt @p-netm @kahummer

[peterMuriuki]

Agreed. I wonder how might we modularize this tiny backend setup in way that we decouple its logics for utility (aka - a server that authenticates react apps, let's say "gatekeeper-server") from the client (aka - the auth'ing OpenSRP specifically, say "opensrp-auth")

This is quite a great idea. I like it. We should eventually support this useCase.

[moshthepitt]

Agreed. I wonder how might we modularize this tiny backend setup in way that we decouple its logics for utility (aka - a server that authenticates react apps, let's say "gatekeeper-server") from the client (aka - the auth'ing OpenSRP specifically, say "opensrp-auth")

Nice, I like this. I think we are some way towards that - the server right now does not do anything too Reveal-specific and can be generally adapted to support OAuth for any other frontend project.

Still, I recommend we move it to its own repo and then take stock on what more we can do.

[peterMuriuki]

Still, I recommend we move it to its own repo and then take stock on what more we can do.

ok. Lets move it

[cKellyDesign]

Agreed. I wonder how might we modularize this tiny backend setup in way that we decouple its logics for utility (aka - a server that authenticates react apps, let's say "gatekeeper-server") from the client (aka - the auth'ing OpenSRP specifically, say "opensrp-auth")

we are some way towards that

Yeah I can see this going through a few more iterations over time and maturing a bit before ending up like something like this. 😄