Updated dependencies doc to be a little more use-case focused #23
Conversation
components/dependencies.mdx
Outdated
| create a new component from one of Architect's starter projects. | ||
|
|
||
| ```sh | ||
| $ architect init backend |
There was a problem hiding this comment.
This command needs more instruction. We need to explain what they should select from the dropdown list and that a new project will be created in the directory provided (backend). We should explain that this command is cloning one of our starter projects locally.
There was a problem hiding this comment.
I'm not sure which to select. We don't publish the node-rest-api project as a starter project any longer. We publish the nodejs project, which contains a frontend, instead.
There was a problem hiding this comment.
I see what you mean, but I think if we verbosely explain the init command every time we cite it we're going to have a LOT of duplicate documentation.
What I think makes more sense given your two comments is not to make this a full "guide" with running examples, but rather to simply talk about the dependencies feature abstractly and the register and link command respectively. If you agree I can make some changes to shorten.
components/dependencies.mdx
Outdated
| and call it `frontend`. | ||
|
|
||
| ```sh | ||
| $ architect init frontend |
There was a problem hiding this comment.
Tell them what to select from the dropdown list.
| AUTH_EXTERNAL: ${{ | ||
| dependencies['authentication'].services.auth.interfaces.main.ingress.url | ||
| }} | ||
| BACKEND_ADDR: ${{ dependencies.backend.services.api.interfaces.main.url }} |
There was a problem hiding this comment.
I would explain where this address comes from and possibly link to components/service-discovery
There was a problem hiding this comment.
I see you bring in service discovery below. It would still be helpful to explain here that the address comes from the backend app's service declaration in its own architect.yml file.
components/dependencies.mdx
Outdated
| ```yaml | ||
| Citing dependencies as part of your component is not the most natural way for developers to integrate with | ||
| software made by other teams, but its also the only way to achieve [on-demand environments](/environments/pull-request) | ||
| for [distributed applications](/architecture/microservices). |
There was a problem hiding this comment.
The linked page doesn't exist.
There was a problem hiding this comment.
Whoops! My bad. Making changes.
| for [distributed applications](/architecture/microservices). | ||
|
|
||
| Every time a component is deployed with Architect, it will automatically deploy (if needed) and connect to | ||
| cited dependencies. Perhaps even more impressive than that is that it will also deploy the dependencies OF your |
There was a problem hiding this comment.
| cited dependencies. Perhaps even more impressive than that is that it will also deploy the dependencies OF your | |
| cited dependencies. Perhaps even more impressive than that is that it will also deploy the *dependencies your |
There was a problem hiding this comment.
I'm not sure this suggestion captures what I was trying to say which is that we deploy the dependencies you didn't know you had as well (e.g. the dependencies OF your own dependencies). Is there a better way to phrase that that you can think of?
|
|
||
| Every time a component is deployed with Architect, it will automatically deploy (if needed) and connect to | ||
| cited dependencies. Perhaps even more impressive than that is that it will also deploy the dependencies OF your | ||
| component's dependencies and ensure they're integrated as well. |
There was a problem hiding this comment.
| component's dependencies and ensure they're integrated as well. | |
| dependencies* and ensure they're integrated as well. |
Co-authored-by: Mandy Hubbard <[email protected]>
Co-authored-by: Mandy Hubbard <[email protected]>
Co-authored-by: Mandy Hubbard <[email protected]>
Co-authored-by: Mandy Hubbard <[email protected]>
Closes #22 by updating the dependencies doc