[RFC] feat: add base code for the image of Appsody LoopBack stack

[raymondfeng]

This is an attempt to extract code to loopback-next repo from https://github.com/appsody/stacks/tree/master/incubator/nodejs-loopback. The move will make maintenance of the LoopBack Stack for Appsody much simpler.

Items for discussion:

1. Can we use a different repo than appsody - https://github.com/appsody/stacks/blob/master/index.yaml#L61?

2. This PR creates a module as the base for appsody/loopback applications - we can release it independent of the stack.

3. What about the template? Can it be hosted on our repo and referenced via https://github.com/appsody/stacks/blob/master/index.yaml#L61?

Checklist

👉 Read and sign the CLA (Contributor License Agreement) 👈

• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• API Documentation in code was updated
• Documentation in /docs/site was updated
• Affected artifact templates in packages/cli were updated
• Affected example projects in examples/* were updated

👉 Check out how to submit a PR 👈

[emonddr]

@raymondfeng , I have two questions:

• why do we have one application loading another application? Are other stacks designed this way? I couldn't find relevant documentation on or off the appsody site
• do we really need mocha tests for the loader application and the template application? Why not just the template application?

:)

[raymondfeng]

@emonddr Good questions.

Yes, Appsody stacks by design break down an application into two parts:

• The base image contains the loader that sets up common things for all apps. In our case, the base mounts health/metrics/... components to provide cloud native facilities.
• The app templates focus on application logic.

Developers can only change the 2nd part and it's packaged with the base into a Docker container by Appsody as it goes.

See https://appsody.dev/docs/stacks/stack-structure.

[bajtos]

In general, I agree it's more convenient for us to keep the Appsody template in our monorepo.

I have few major concerns though:

• Duplication of content between lb4 app and Appsody templates. Besides the difficulties of keeping these two templates in sync, it's also not clear to me which parts are intentionally different.

• How are we going to test the correctness of the template and verify integration with Appsody?

• What impact will the Appsody-related test suite have on duration of npm test (local development) and Travis CI jobs? Our tests are already taking too long to run, we must be mindful about introducing more long-running tests.

[bajtos]

Is it a good idea to include the /ping enpoint in the base stack? Isn't this just a dummy endpoint useful for testing, but not suitable for deployment to production?

[bajtos]

I am concerned about the duplication of .gitignore content. Can we find a way how to produce this file as part of build and/or at publish time? I would expect that most of the ignore rules should be the same as we are using for new projects created by lb4 app.

The same concern & comment applies to other parts where the Appsody template is duplicating the output of lb4 app.

[bajtos]

This is an attempt to extract code to loopback-next repo from https://github.com/appsody/stacks/tree/master/incubator/nodejs-loopback. The move will make maintenance of the LoopBack Stack for Appsody much simpler.

Instead of committing the code to git, have you considered introducing a new CLI option or command to scaffold the Appsody-enabled application? If Appsody is not able to run a 3rd-party script as part of project bootstrapping, then perhaps we can run that script ourselves to create files to be published for Appsody consumption?

For example, the instructions for updating the Appsody template can look like this:

1. Move to an empty directory
2. Run lb4 app --appsody base (or maybe lb4 appsody --base?)
3. cd base
4. Publish the files for consumption by Appsody (via npm publish?)

[emonddr]

@raymondfeng , another thing I noticed is that the port 3000 seems to be hard-coded in the stack/template. Even if I change the port number in the rest server application config, I can see docker commands still using 3000.

[achrinza]

Since Appsody development has ended, should we close this pull request?