Discussing the next steps for JSLB4

[hacksparrow]

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 From datasource config to DataSource instance with no custom classes #2557 and Variable substitution in DataSource JSON files #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.

[hacksparrow]

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 Spike: Port the examples/todo app to JavaScript #2501. Two spikes will be involved in it: 1. Spike: Create Route in JSLB4 #2474, 2. From datasource config to DataSource instance with no custom classes #2557.

[dhmlau]

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