Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussing the next steps for JSLB4 #2567

hacksparrow opened this Issue Mar 11, 2019 · 2 comments


None yet
3 participants
Copy link

commented Mar 11, 2019

Continuing the discussion from #1978.

Meeting notes by @dhmlau:

Based on what has been done in this JS Spike, would like to discuss how we should move it forward considering other priorities.

UPDATE Mar 7. Raymond and Yaapa were able to have some discussion. Here are some view points from Raymond.

To make us easier to think about the incremental updates, there are different personas using LB4:

  • Persona 1: use LB4 as foundation to build ur large scale application:

    • what we have to cover that are IoC and DI container. But we heavily depend on the TS decorator to supply the metadata and places for injection.
  • Persona 2: API developer

    • they probably think about how to write controller, how to contribute as controller using ES2017/2018 structure, to make it accessible to the LB4 routing structure and API experience.
    • for controller, there are some kind of decorators as well, e.g. how to expose REST metadata. Yaapa has some sugar methods so that ES6 class can be recognized as LB4 controller.
  • Persona 3: Extension developer

    • don't anticipate for LB4. they should be comfortable enough to write TS
  • On top of the 3 persona, there is plain Express developer

    • how to pick the right tool for different things. we can achieve that with the express-composition tutorial. Existing PRs to leverage express middleware.

We need to find the right balance on how much we want to replicate for JavaScript, because we've made the decision to go for TypeScript. It would be useful to have lightweight integration to get it going, and some meaningful story to compose between LB4 and node.js module (e.g. Express experience should be good enough)

Next step:

  • Yaapa to write a blog about:
    • why we're trying this JS experience
    • what we found
    • what's the tentative decision

Follow up by @bajtos:

In the list of personas (see the original email quoted below), I am missing a fourth type.

Persona 2.1: API developer with FP background building microservices

  1. The microservice has about 5-10 endpoint routes. Using OOP and Controllers feels like overkill, the developer prefers to use function-based route handlers similar to Express programming model.

  2. They want to leverage LB4's integration with OpenAPI, so that routes can declare their parameters via OpenAPI spec and let LB4 do parameter extraction, parsing/coercion and validation. This is the selling point for upgrading to LB4.

  3. They would prefer to use our ORM (models, repositories and service proxies) to leverage the integration we provide. However, they would prefer to do so without DI, in the traditional JavaScript way.

    • At start up, they would like to configure datasources without custom classes & @inject decorators, just by calling JS API. For example:

      app.dataSource('db', {url: process.env.DB_URL, connector: 'mysql'});

      A declarative approach automated via @loopback/boot would be even better.

      // src/datasources/db.json
        "name": "db",
        "connector": "mysql",
        "url": "${ENV.DB_URL}",

      I think this feature is useful outside JavaScript story too (declarative support, feature parity with LB3, AppConnect requirements). I created two issues to capture this use case, see #2557 and #2556.

    • Models and Repositories are deeply rooted in Object-Oriented design. I think it would be too difficult to apply functional programming techniques here, thus the developers has to accept classes. We need to find a way allowing developers to provide model definition (juggler schema) from JavaScript and how to write custom Repository classes in JavaScript - obtaining the datasource instance is the difficult part.

    • In route handlers, they are ok to use something similar to ServiceLocator pattern to obtain repository instances. For example:

      const repo = await app.getRepository('UserRepository')
      // possibly better - no DI is required
      const repo = new UserRepository(app.getDataSource('db'));
    • For the ORM part, I think we need to come up with an example/docs showing how to write such code in the first step, and them write CLI tools to generate JavaScript artifacts in the second step.

Re: Persona 1: use LB4 as foundation to build ur large scale application

From what I am hearing, maintaining large scale projects in JavaScript is difficult. Once applications grow over certain size, most developers start naturally looking for ways how to introduce more type safety and usually switch to TypeScript.

In that light, I think we can afford to intentionally exclude large scale applications from our Plain JavaScript experience and tell our users to use TypeScript from the start, to save theirselves from future pains.

Re: On top of the 3 persona, there is plain Express developer

I have slightly different opinions about the user experience we should provide. Let's discuss in the meeting and/or on GitHub.

@bajtos bajtos added the discussion label Mar 11, 2019


This comment has been minimized.

Copy link
Member Author

commented Mar 14, 2019

Updates from the meeting:

  1. We went through the personas and narrowed down on a single one: A developer who wants to use Express-style callbacks and access LB4's request context to use LB4 features.

  2. The previous usecase's implementation can be spiked in #2501. Two spikes will be involved in it: 1. #2474, 2. #2557.


This comment has been minimized.

Copy link

commented Mar 22, 2019

Looks like the discussion is done. Blog post is in progress and spike stories are created.

@dhmlau dhmlau closed this Mar 22, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.