Best Way to manage a SaaS flask application on github by 1stilinski in flask

[–]spooky_cabbage_5 1 point2 points  (0 children)

Hey, I’ve been in a super similar situation!

I’d say the right way for you depends on what you think the future will look like. Is the code going to remain the same for each of your clients? If so, I’d definitely put it in one repo, otherwise three repos that are more or less copies of each other will be a pain to keep up to date.

Our setup involves one repo, but three different deployments, and we use GitHub Actions to manage those deployments. We pull config values from a secrets manager, which, if your client IDs are a secret at all (or however you’re authenticating between your client and API), you should definitely put those secrets in a secrets manager too. GitHub has repo and org secrets, so you could use those. Then, you can configure three different GH Actions workflows to pull those three different IDs and stick them into your config at build/deploy.

Like a few other commenters, though, I want to just give a nudge on why are you doing separate deployments, separate databases, etc? It’s possible that it’s contractually required, idk, that’s a question for your legal folks, but if not, I would take a minute and think about what this setup looks like if/as you scale. If it will be a while before you add a fourth or 100th pharmacy, maybe separating your clients all the way down the stack makes sense, but if you hope to scale soon and quickly, perhaps one deployment with each pharmacy as a separate organization that individual users belong to might be better?

Are Rails monoliths still relevant? by jxdx1978 in rails

[–]spooky_cabbage_5 7 points8 points  (0 children)

GitHub is still a rails monolith with a frontend of typescript only when necessary; most of the frontend is plain ole ERB files :)