search

LoveNationArmy / roadmap

Project roadmap discussions.
MIT License
0 stars 0 forks source link

Backend discussion #1

Open stagas opened 6 years ago

stagas commented 6 years ago

backend

local development

deployment

stagas commented 6 years ago

A technical goal we want to achieve is:

We want people with little to no technical knowledge being able to deploy applications for their cities - this also builds resiliency - one goes down, ten are spawn the next day. It's something to keep in mind whenever we want to introduce a technology that includes build steps or complicated or otherwise being non-standard or not available to the default setup of a smartphone or desktop computer or a hosting provider.

This affects both frontend(#2) and backend. For example, is node.js the technology for this, or maybe php (lamp stack) is more highly available worldwide and makes more sense? Can we leverage jsx or a micro React-like framework that doesn't require the huge babel-stack for the frontend? What is the state on the native Web Components?

Does it make sense spending time answering these questions at this point or should we build something and mark these for a refactor/version 2, using the knowledge that we will have then?

sgimeno commented 6 years ago

Some quick thoughts:

A technical goal we want to achieve is:

  • Make the deployment as easy as clicking a button, if possible.

Given this requirement, for MVP#1 I would argue in favour for a single monolithic repository (Even if FE & BE are decoupled inside the sources).

This brings the following trade-off (scalability vs easy-deploy):

Does it make sense spending time answering these questions at this point or should we build something and mark these for a refactor/version 2, using the knowledge that we will have then?

I agree on postponing this decision

stagas commented 6 years ago

We can use lerna / yarn workspaces so that we can publish separate modules from the same repo. A monorepo is a better approach IMO. My main arguments against the monolith is better testing which leads to faster development down the line and reusability of components/modules across projects. The argument against the multi-repo approach is mainly that a single PR can touch all of the involved components at once, so deployments are more predictable. Teams are reporting a 5x increase in productivity after switching to a monorepo architecture.

fmarts commented 6 years ago

I see this as project-specific decisions, in future projects we may have to use different stacks, so I would suggest moving this to the ride repo itself.

I agree with the monorepo until we see the need to separate into different repos.

I agree with dockerizing the app, it makes it more portable to deploy in different ways, plus making the environment consistent.

How are we going to store state? Is there any decision or suggestions on that?

stagas commented 6 years ago

@fmmrtns Regarding state, I've been researching a bit and so far I've come up with these that looked reliable enough (there were more but didn't look so professional):

Postgres:

Mongodb: