docs: add example-microservices

[bajtos]

Move https://github.com/strongloop/loopback-next-example to our monorepo.

The project was pretty outdated, the codebase needs a lot of further improvements which are out of scope of this pull request.

Here, I made the minimal changes needed to make this new example project "work" in our monorepo, i.e. to pass npm test.

See #836

Checklist

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

---

List of changes that are out of scope (I'll open a new issue for them once this PR is landed):

• Rework services to follow the standard app project layout,
  replace ts-node with proper tsc-based build,
  add prettier & tslint scripts to individual services packages

• Rework services to use model & repository best practices, see http://loopback.io/doc/en/lb4/Implementing-features.html

  • models are standalone entities decoupled from repositories/datasources
  • repositories should inherit from DefaultCrudRepository and return typed
    data

• Remove tslint:disable:no-any exceptions

• Ensure each service is covered by tests. We don't need high coverage,
  but at least the most important scenarios must be covered.
  The tests should follow our best practices outlined
  in http://loopback.io/doc/en/lb4/Testing-your-application.html

[bajtos]

FYI: I split the changes into multiple smaller commits, I hope it will make it easier for you to review them. The first commit adds the code from https://github.com/strongloop/loopback-next-example without any changes, the subsequent commits contains the important changes to review.

[bajtos]

Before this change, the result of toObject was considered as an object with no properties. The following code is rejected by the compiler:

modelInstance.toObject().id

After this change, the result of toObject is considered as object with arbitrary properties, thus the code above passes compiler checks again.

[bajtos]

@raymondfeng @kjdelisle before you start reviewing the code, I'd like to ask a high-level question: are we sure this example belongs to the monorepo? Raymond mentioned that eventually this microservices-example should leverage gRPC transport, which lives outside of our monorepo right now. More importantly, this example is a mini-monorepo on its own. Wouldn't it better to keep the example as a standalone GitHub project? Using lerna instead of hand-written scripts (see bin/test.js for an example), and "fetching" dependencies from possibly multiple sources (e.g. REST transport from our main monorepo, gRPC component from the community-maintained singlerepo, etc.).

Thoughts?

[kjdelisle]

I don't think this should be a part of the monorepo, or an example we continue to maintain in general. While I do want to see us dogfooding the framework with more advanced use cases, I don't think this one really fits the bill in terms of actually validating the capabilities of LoopBack 4 with respect to the sorts of things I'd want to see:

• development time
• performance
• UX
• etc...

This comes across as a "best-practice" example; the sort of thing a well-known community member or evangelist would produce to demonstrate the capabilities of LoopBack.

If we're looking to demonstrate proper use of this framework in the greater context of making and managing microservices, it should:

• use cutting edge industry tech outside of LoopBack (using Istio, or some other framework to coordinate the microservices)
• show how we fit into that space with an example that goes beyond a basic demonstration
• be in a separate repo
• not happen before MVP (too much churn means there will be a constant upkeep for this advanced example)
• have a blog post to go with it that really hammers home why we're a good fit

[bajtos]

@kjdelisle +1 on what you wrote above. I am closing this pull request.