How should we handle platform deployment and routing to the individual projects

[meganmckissack]

Looking for clearer instructions for handling routing to project pages and what needs to be set-up with the devops in relation to the EC2 instance.

Per Micheal Lange in relation to a question about the need to containerize this setup from Mike Lonergan:

"it's evident that we are interested in doing server-side rendering using express. Which means we need a node environment. Perhaps this is what you mean by the architecture that david is working on.

If it isn't, then we do need to containerize front-end code and deploy it, and we cannot use S3, since we need node.

The piece that I haven't heard about is how we plan on coordinating the various front-ends. My suspicion is we will deploy front-end separately (creating x node processes) and use nginx to route traffic to the correct places. However, this wouldn't give us inter-project client-side routing, so maybe there is a grander scheme in the works."

[MikeTheCanuck]

I've generated three straw-man diagrams to illustrate how this architecture might work. It's based on no detailed knowledge of how the "React Router" I've heard mentioned works, or how to use Express in the outermost layer and/or residing right on the frontend of each HO project. I'm sure there are details misunderstood here, and I'm hoping that by putting together these diagrams we can surface the actual details of the intended request flow from the client through the civic platform central server to the frontend and API layers of each project.

Guess #1 https://drive.google.com/file/d/0B04ORgI23dk7NzhLaHI5WEVVckU/view?usp=sharing Guess #2 https://drive.google.com/file/d/0B04ORgI23dk7eU9Ja1JzRmZaZ3c/view?usp=sharing Guess #3 https://drive.google.com/file/d/0B04ORgI23dk7cFMzSVlOY0JTWUk/view?usp=sharing

[DingoEatingFuzz]

Here's another straw man to add to the mix. This one doesn't concern itself with how the API works, but it shows a user session and the interplay of nginx (or apache), express, and the client session.

Technical nit: React Router is used for server-side rendering and client-side rendering, so it isn't a good term to use to distinguish what happens in node/express and what happens in the browser.

(click to enlarge)

[DavideDaniel]

They can also all be client bundles hosted on s3 that export configured routes, consumed by the main app, and exposed as sub routes. The hitch is the big api change to react router which I'm spiking on this weekend.

[DingoEatingFuzz]

consumed by the main app, and exposed as sub routes.

What is the main app you are referring to?

[MikeTheCanuck]

@DingoEatingFuzz thanks for adding another viewpoint to the discussion.

@DavideDaniel thanks for spiking this big issue. We'll need the clarity sooner than later to stabilize our infrastructure pipelines - we're hoping to get the big moving pieces worked out earlier than later.

The big question at the moment (for the DevOps squad) boils down to this: we're currently enabling frontend teams to automatically deploy their repo's files to S3, and we're assuming that something upstream (your main app or the browser client) will retrieve these files and render them as a React app. Does this need to change - will we need to stand up a Node.js/Express server directly in front of each of the 5 project frontends (i.e. 5 x Express servers)? If so, that will require migrating our infrastructure from files to VMs (S3 to EC2 or ECS), and a bunch of changes to the CI/CD pipeline.

The DevOps squad meets again tonight in class to continue rolling out our automation infrastructure - if we can say with some confidence that Hack Oregon needs us to abandon S3 and move all frontend work to Express on VMs, that would save us a bunch of re-work down the line.

Thanks for any insights you can provide.

[DavideDaniel]

The main app will be the civic front end react application in this case.

It should work with the s3 setup. I'll stand up an example app this weekend.

On Tue, Feb 21, 2017 at 12:11 PM Mike Lonergan notifications@github.com wrote:

@DingoEatingFuzz https://github.com/DingoEatingFuzz thanks for adding another viewpoint to the discussion.

@DavideDaniel https://github.com/DavideDaniel thanks for spiking this big issue. We'll need the clarity sooner than later to stabilize our infrastructure pipelines - we're hoping to get the big moving pieces worked out earlier than later.

The big question at the moment (for the DevOps squad) boils down to this: we're currently enabling frontend teams to automatically deploy their repo's files to S3, and we're assuming that something upstream (your main app or the browser client) will retrieve these files and render them as a React app. Does this need to change - will we need to stand up a Node.js/Express server directly in front of each of the 5 project frontends (i.e. 5 x Express servers)? If so, that will require migrating our infrastructure from files to VMs (S3 to EC2 or ECS), and a bunch of changes to the CI/CD pipeline.

The DevOps squad meets again tonight in class to continue rolling out our automation infrastructure - if we can say with some confidence that Hack Oregon needs us to abandon S3 and move all frontend work to Express on VMs, that would save us a bunch of re-work down the line.

Thanks for any insights you can provide.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/hackoregon/civic-platform/issues/1#issuecomment-281465620, or mute the thread https://github.com/notifications/unsubscribe-auth/AIZSegnrqoRMIrcij_IfZHd9kj3-tewFks5re0T4gaJpZM4MGwBv .