"Going into production" docs update #2373
Conversation
Signed-off-by: Mihovil Ilakovac <[email protected]>
| title: CI/CD Scenarios | ||
| --- | ||
|
|
||
| TODO: we'll talk about how to e2e test Wasp apps in the CI |
There was a problem hiding this comment.
Interesting. It makes sense, but one can also run e2e tests, or any kind of tests, in the CI, even if they are not doing deployment -> what I mean to say is, CI is actually not tied to deployment. Deployment can be part of CI (I guess the "CD" part), but CI can be without any deployment happening. So e2e tests in CI -> sounds like it shouldn't be under "Deployment"?
|
|
||
| TODO: we'll explain the database in the context of deployment | ||
|
|
||
| TODO: the only requirement from Wasp's point of view - it has to be a PostgreSQL database accessible from the server via the `DATABASE_URL` environment variable |
There was a problem hiding this comment.
Ok maybe redundant but feels better to be explicit when dealing with env vars. And I know this is note for yourself but it will transfer to docs.
| TODO: the only requirement from Wasp's point of view - it has to be a PostgreSQL database accessible from the server via the `DATABASE_URL` environment variable | |
| TODO: the only requirement from Wasp's point of view - it has to be a PostgreSQL database accessible from the server via the `DATABASE_URL` server environment variable |
|
|
||
| TODO: we'll talk about migrations: how are they created in development, how are they applied in production, how to debug failed migrations | ||
|
|
||
| TODO: we'll talk about how to open the DB studio in development and production |
There was a problem hiding this comment.
It's interesting how non-production stuff creeps in so easily here. Which makes sense - you want to talk about DB studio in production, it is a bit weird not to mention the rest of it (development).
I wonder how to go about this. What maybe sounds most "correct" to me is to write all this stuff without thinking about production first -> so there would be a piece of docs about DB studio, connecting to the DB. And it would explain how to do it from development, and I guess it would also explain how to do it for production! But yeah, I would expect that explanation to be there, since that is where we have the context. Then, from production docs, I would merely expect a link to that, and possibly a bit of additional explanation if really needed -> if we have some context we didn't have there and it is important to mention it.
So the question is kind of: if we have features A and B, with their own doc pages, and we have doc page P for production, do we go with this structure of docs:
- A (maybe links to A.P)
- B (maybe links to B.P)
- P
- A
- B
or do we go for
- A
- P
- B
- P
- P (links to A.P and B.P when talking about A and B)
I guess the question is, when talking about A in production, wihch context is more valuable -> that of A, or that of P? I think usually it will be that of A, which is why it makes more sense to me to go with A.P, B.P, and P then linking to those + maybe providing a bit of additioanl context as needed.
| title: 'Deploying Manually', | ||
| description: 'Build the app and deploy it manually', | ||
| linkToDocs: '/docs/advanced/deployment/manually', | ||
| title: 'Deploying with PaaS', |
There was a problem hiding this comment.
I have to admit I wasn't 100% what I can expect from this based on the title. I thought ok, PaaS, that is Heroku? But I wasn't 100% sure. I wonder if there is a way to put this simpler. If not, that is all right, maybe this is the best way to shortly describe it, but I wanted to ask nevertheless.
| title: 'Deploying Manually', | ||
| description: 'Build the app and deploy it manually', | ||
| linkToDocs: '/docs/advanced/deployment/manually', | ||
| title: 'Deploying with PaaS', |
There was a problem hiding this comment.
So "Using Wasp CLI" -> that doesn't tell much to somebody who hasn't already read that piece of docs. What if we instead named it One-"click" deployment with Wasp CLI? Or is that too long?
There was a problem hiding this comment.
OK, nice, we can put stuff here when it is small enough, and if it becomes big enough we can in the future create separate sections.
| title: Introduction | ||
| --- | ||
|
|
||
| TODO: the time to share your app with the world has come |
|
|
||
| TODO: we'll take you through the process of deploying your app to the web | ||
|
|
||
| TODO: first, you'll need to understand the structure of a Wasp app: Node.js backend, React frontend, and a PostgreSQL database. We'll explain the client app, server app and how it connects to the database. |
There was a problem hiding this comment.
This sounds tempting to be a concept explained outsdie of Deployment, as a core concept, and then linked to from here + expanded upon with more deployment specific stuff. ALthough one could argue that structure of Wasp app is an implementation details important only for deplyment hehe, but that is probably going too far yeah, you certainly want to understand it even before deploying, of course. Just arguing with myself here for a bit.
There was a problem hiding this comment.
Interesting, I like it. I wonder how easy it is to understand it though if you don't already understand it quite well.
Those two urls -> they don't have to be separate urls though right? We could have /api and have them be proxied correctly by the proxy?
Also, db doens't have to be in the docker here with server app, right? It could be running directly without docker, or in another docker container, or even be outside of our server.
There was a problem hiding this comment.
One thing when talking about self-hosted solutions that I wonder about the most is the database -> what is with some kind of database backups? I guess in self-hosted scenario, that is the main problem really -> everything else I can fix, but I manage to somehow mess up my machine so bad I corrupt or loose the db data that is on the drive on it, I am screwed, that is the only thing I can't recover. So I would say that one topic we should address sooner than later is how to mitigate that, how to ensure you have some kind of redundancy. Of course one option is to use some kind of db provider, so we can also mention that, we can host everything but database, that is also ok I think, but we could also give some ideas what to do if you want to host database on your own. Or at least warn you + point you to some reading materials.
This is the first PR in the deployment docs series, it covers:
The idea is to have general concepts of deployment explained first: Wasp app structure (it's React + Node.js + database), env variables, database (migrations, connecting to the DB) and then describe deployment methods. There are some CI/CD things I'd like to mention and then some extras like custom domains, CDNs etc.
I'll be branching from this branch when I'll write the other parts of the deployment docs: