@hacksparrow lets discuss the details for generating the loopback-next docs based on typescript.

This is mainly the build process.

I am proposing to set an aggressive timeline for the next version and remove any features that are not done on time. Preliminary proposal:

1. 2016-03-31: Any feature that's not mostly complete is removed from this release. (The definition of mostly is intentionally left vague.)
2. 2016-04-30: Feature freeze. Any feature/change not finished by this time is removed from the release.
3. Next 3-6 months: stabilize the code, integrate with APIC and to other tasks required for a new release.

This is based on my experience with managing 3.0 release - even though we drastically reduced the scope of the release in May 2016 (using the rule described in my step 1 above) , the first release candidate was not released until October 2016 and the GA was announced in December. I.e. it took us more than 6 months to finish a release. Projecting this experience to loopback-next and my proposed dates, loopback-next will be released in 2017Q4.

@ritch @raymondfeng @superkhau

Hey everyone,

We need to start coordinating the releases of this project for obvious / not so obvious reasons. Mainly we need to start getting on a cadence that we already are on for LB@3. Below is a proposal / checklist, agreed on with some folks who will help with marketing / promotion of LB.next.

Please note this is a proposal for a timeline that folks can work against. None of the dates are final yet. But as we schedule events around these dates... they will be somewhat set in stone.

Project Announcement - A Call for Contributors

Date: April 7th

• Blog post detailing the what, who, why behind LB.next (@ritch, @ashumz, , @raymondfeng, @chandadharap)
• Change Repo from private => public (@ritch)
• Link from strongloop/loopback (@ritch)
• Twitter and other Social announcements (Dave W.)
• YouTube round table with Ritchie, Raymond, Miroslav, and Simon (LB.next core team, and other non IBM core members???). -- decide on a date and announce

Beta Announcement - Download and Use It (for non prod)

Date: May 1st

• Release to NPM
• Blog linking to videos, docs, and examples. Also announcing LB to the dev community (not just contributors)
• Video explaining how awesome it is to use LB.next (more TBD)
• Example applications demonstrating usage and helping folks get up to speed
• Getting started guide and other rough documentation in the wiki (@crandmck / @superkhau)
• Basic API docs somewhere @crandmck

LoopBack v4.0.0 release

Date: June 1st

• In person talk at TBD Conf (@ritch)
• Formal 4.0.0 announce blogs / social / etc
• Production ready testing

This issue is for new folks to chime in and say hello and that they'd like to be involved offline (off GitHub) discussions. I'm not expecting the working group on this project to be so large that we can't all get to know each other.

Just comment here that you'd like to be added to the LoopBack.next contributors list and I'll create a group in the StrongLoop org with all of you - so we can do things like @strongloop/loopback-next for scheduling external meetings and such.

When we invite you to join our org and you don't receive an email notification for GitHub, then you can accept the invite here: https://github.com/strongloop

Check out issues labelled as good first issue for tasks suitable for new contributors.

Updated on 05/31/2019

Hi all! First of all, thanks for your interests and support in LoopBack 4!

We have been thinking about how to grow our contributor community together with the user community. There are several ways to contribute:

• Provide your feedback
  We'd love to hear your feedback! Feel free to comment on the GitHub issues that interest you or open an issue in this repo
• Contributing code
  Please see below for details. For step-by-step instructions in submitting a PR, refer to https://loopback.io/doc/en/lb4/submitting_a_pr.html.
• Contributing docs
  From the feedback we got, there's a need to improve our docs. This PR outlines some of the enhancements we'd like to make: #2925

Contributing code

Contribute what you need

We hope you are contributing to something that you need or will be using. We'd encourage you to take a backlog and see if any of our GitHub issues capture your requirement. If you're planning to implement a more complex feature, it would be helpful to submit a draft PR with minimal implementation to discuss your approach first. It would also be helpful to include your use case so that we can understand your requirements better. This is to make sure the intended implementation would align with our architecture and direction.

Contribute anything

If you don't have a particular area you want to contribute, you can look up the help wanted: https://github.com/strongloop/loopback-next/labels/help%20wanted

New Contributors?

If you're new to contributing to LoopBack or open source projects in general, don't worry. You can look at issues with good first issue. Those issues are meant for new contributors:
https://github.com/strongloop/loopback-next/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22

Determine the features / examples for how to test loopback-next applications.

The current initial PoC implementation supports only two parameter sources: path and query. We need to add support for the remaining sources defined in the Swagger spec:

• "header"
• "formData"
• "body"

https://github.com/strongloop/loopback-next/blob/master/packages/remoting/package.json#L14

this causes lerna exec npm install to fail - since its not in the registry

In the past year or two, we have repeatedly came across the idea of using a single monorepo containing all core LoopBack modules (strong-remoting, juggler, loopback, possibly others like swagger, etc.). The last time this was mentioned by @ritch when discussing loopback-next kick-off.

In this thread, I'd like to discuss pros and cons of using monorepo approach for the development of loopback-next (and possibly beyond).

@raymondfeng @superkhau @ritch

Controllers decoupled from the data models/ORM is a concept I have had in my mind for very long time and that I am personally interested in exploring.

We have already started some exploratory work in this direction, see
https://github.com/strongloop-internal/scrum-loopback/issues/614#issuecomment-187124065 and the rest of the discussion.

Once we have a basic concept of a connector implemented, it will open up many further areas to investigate, for example:

• Right now, defining custom types to describe input/output values of custom remote methods is a bit cumbersome. The format of these definition is LDL, which is our own non-standard language. I would like to allow users to describe their input/output values using JSONSchema and/or the subset of JSON Schema used by Swagger.

• There are only very basic validation of input arguments that are not Models - we check for type (string/number/object) and whether the argument is required or not. I would like to see improved validations, using either JSON Schema or npm modules like joi

• ORM independence. Let's face it, writing and maintaining a good ORM is a lot of work, and in all honesty, I think we are pretty much failing at that. I would like to make it easy for LoopBack users to switch to a different ORM/data-access library when their needs outgrow the basic ORM capabilities we provide in LoopBack.

For the scope of loopback-next, I think there will be more than enough work to implement Controllers as a first-class entity, meaning:

• the runtime
• support in loopback-boot
• support in loopback-workspace
• a CLI tool to create new controller
• a CLI tool to add a new remote method to a controller
• (optionally, but preferably) support in APIC Editor

MVP instructions on how to install and use Loopback-next.

Our new official policy is that questions are allowed on GitHub, at least until LoopBack4 reaches GA. Users are still encouraged to post their questions on StackOverflow though.

We should apply yellow "functional-area" labels like "CLI", "Examples", "Docs" to questions as part of our issue triage process. This will make it easier for people to find unanswered questions related to their area of interest/expertise.

(See also a follow-up issue to improve Contrib docs in general: #950)

Acceptance criteria

• Update our docs to reflect our policy change: http://loopback.io/doc/en/contrib/Reporting-issues.html. Updated policy along the lines:

<!--
HELP US HELP YOU BY
- Doing a quick search to avoid duplicate issues
- Providing as much information as possible (versions, use case scenarios for features, etc.)
- Open GitHub issue as the last resort
If you have a question then please consider using a more suitable venue:
 - https://stackoverflow.com/questions/tagged/loopbackjs
 - https://groups.google.com/forum/#!forum/loopbackjs
 - https://gitter.im/strongloop/loopback
-->

The original description from Simon for posterity:

Flame war topic.

Pros:

• Centralize developer activity to GitHub
• Easier to search/keep history centralized
• One place to maintain/manage instead of explaining to users (which goes along with our contributor first principle)

Cons:

• WIll inflate number of actual issues on GH
• Split history (but we don't have to remove old posts from GG, so it's sort of moot)

Make/utilize a LINQ-like query builder that helps us more generically define the meat of a query before it runs against the database so that we can avoid pre-loading the entirety of one or more tables in memory to perform filtering and aggregation.

http://kutyel.github.io/linq.ts/

• Setting up Routes
• Application Logic

users will not be able to access the package because a main script is not exposed

Can't "require('loopback-next')" via JavaScript.

"Is there a preferred way to do a health check endpoint in LoopBack? I’m seeing this which looks decent: https://www.npmjs.com/package/healthcheck-fastit" as per @erin.mckean on Slack

Something we should consider IMO.

• - Models should be classified with namespaces, preferrably in the java style package names.
• - Packaging (folder) paths like /common/models or loopback/models can be name spaces
• - this will allow having models with same names to be configured

• Add a test to codehub example to verify that a path-parameter based endpoint works correctly.
• Fix the implementation of that endpoint as needed to make the test pass.

In loopback/strong-remoting 3.x, we allow remote methods to accept parameters of complex types and have the runtime to convert string inputs (e.g. in a query string or formdata) to such complex type.

• consider whether we want to implement this feature in loopback-next too
• figure how to extend SwaggerOpenAPI specification to allow developers to specify a complex parameter type to be coerced from a string
• implement the proposal

strong-remoting 3.x has pretty extensive test suite that we can reuse here - see strong-remoting:test/rest-coercion/

Acceptance criteria (Scope for 4.0 GA)

• Support "type: object" only
• Leverage OpenAPI spec parameter "style: deepObject"
• For deepObject parameters, support both color[R]=100&color[G]=200&color[B]=150 and color={"R":100,"G":200,"B":150} encodings (the latter is our own extension).
• Test + Docs

Everything else (other styles than deepObject, array values, etc.) is out of scope of GA.

The spec: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md#parameterObject

Examples

1. Send a "filter" query as JSON-encoded value:

   GET /api/products?filter={"where":{"name":"Pen"},"limit":10}
   

   Sets filter argument to {where: {name: 'Pen'}, limit: 10}.

   Alternative encoding:

   GET /api/products?filter[where][name]=Pen&filter[limit]=10
   

2. Encode an array of strings as a comma-separated list (OUT OF SCOPE OF 4.0 GA)

   GET /api/domains?tlds=com,net,eu
   

   Sets tlds argument to ['com', 'net', 'eu'].

See https://github.com/strongloop/loopback-next/pull/61/files#r102336527

We need to make it easy to know the input and output of the ctx's APIs. Here are some examples

// Hard to remember the string, easy to introduce typos
ctx.bind('someLongStringHere').to(SomeType);

// Does MyConcreteType implement MyInterface ???
// would be nice if the compiler checked this for me
ctx.bind('MyInterface').to(MyConcreteType);

// when I refactor code - I don't want to have to go find/replace all instances of 'someString'
ctx.bind('someString').to(SomeValue);

I think the main goal of loopback-next should be TypeScript and es6-7 as first class features. Below are the goals:

1. rewrite LoopBack source code as TypeScript classes using es6 / 7 features best practices
2. use TypeScript native modules eg. import and export.
3. promises first and everywhere
4. async and await everywhere

Below is brief list of impact for discussion.

1. drop callback API ??? - we need to focus on promise support, can we do that without dropping callbacks?
2. remove all uses of require()
3. change model script syntax - now export es6 class ???
4. shouldn't force users to use TypeScript - need to provide docs as both TypeScript and JavaScript
5. would tests need to be rewritten in TypeScript ???
6. drop custom impl of mixin and class in juggler

Anything else?

@bajtos @raymondfeng @superkhau

Setup TypeScript build chain and npm config so that npm pack (and npm publish) ships Node 4.x compatible JavaScript sources.

In order to continually verify the correctness of this setup, a simple end-to-end test written in pure javascript should be included.

I don't have an opinion, but since Ritchie mentioned this some time ago, I thought I'd throw it in the mix.
Shall we replace Express with Koa in LB4?

Excuse my naiveté, but would it be possible to add Koa, so that apps could use either Koa or Express style middleware? Or is that impossible or impractical?

What are implications for:

• LB core, connectors, components, etc.
• Examples and docs
• Tools / workspace
• LB users (app developers)

Compare mocha, tap and tape to decide which framework to use.

Concerns to address:

• speed (loading strong-globalize and loopback is expensive, OTOH running tests in parallel would be great)
• what is more friendly to contributors from the community?
• how well do they support promises/async-await style of programming?

The current initial PoC version is based on Express' path-to-regexp, which is know to scale poorly.

We should switch to a Trie-based implementation, consider using an existing module https://github.com/yoshuawuyts/wayfarer

Flame war topic.

We need to address the number of growing/open issues in a sustainable way. Ideas?

cc @bajtos @raymondfeng

Abstract out start function from Application into own class.

Let's talk about Controller's.

Background

• What is a Controller?

strongloop/loopback#591 (comment)

I see this come up a lot, like how you have to "extend built in user model" + "automigrate the ACL, Role, etc" tables. We need a better experience than this (not to mention good docs up front if we're going to leave a bad experience like this for people just getting started).

Here is a minimal but somewhat complete example for a few features / tweaks that I'd like to see. It includes everything that I can think of as fundamental building blocks...

• Creating an Application
• Defining a Model
• Defining / Using a Collection
• A Controller and method (with decorator sugar)
• How decorators can easily pass references to the app (see: @app.controller and other examples
• Hooks
• Named hooks
• Hook ordering / dependencies
• Express middleware support
• Dependency injection (see @app.collection, @inject('currentUserId'))

TBD:

• import {app} from 'app' (ugly, global-ish)
• No simple app.start() / Server usage (missing)

// app.ts
import {Application} from 'loopback';
export const app = new Application();

// todo.ts
import {app} from 'app';

@app.model
class Todo {
    txt : string;
    done : boolean = false;
}

// todo.controller.ts
import {Collection} from 'loopback';
import {app} from 'app';
import {Todo} from 'todo';

@app.controller
class TodoController {
    @app.collection
    todos : Collection<Todo>;

    @app.get('/my/todos')
    list(@app.inject('currentUserId') uid) : Collection<Todo> {
        return this.todos.find({where: {owner: uid}});
    }
}

// hooks.ts
import {app} from 'app';

@app.bind('currentUserId')
function getUserId(ctx : Context) : string {
    const token = ctx.get('accessToken');
    if (token) return token.userId;
}

@app.bind('accessToken')
getToken(ctx : Context) : AccessToken {
    return new Token(ctx.get('req'));
}

@app.before('controller.*.list')
function beforeAll(ctx : Context) {
    console.log('before', ctx.get('method.name')); // "before list"
}

@app.before('controller.**', {express: true})
require('morgan')(); // express middleware also supported

// name your hooks for more control
@app.after({name: 'timestamp', match: 'controller.**'})
function afterAll(ctx : Context) {
    const result = ctx.get('result');
    ctx.bind('result').to({
        timestamp: Date.now(),
        data: result
    });
}

// ensure a hook runs after another hook
@app.after({ensure: ['timestamp'], match: 'controller.*'})
function end() {
    console.log('last hook!')
}

Placeholder: https://www.npmjs.com/package/@loopback/loopback

We can potentially name LoopBack modules as:

@loopback/core
@loopback/remoting
@loopback/connector
@loopback/connector-oracle
@loopback/workspace

Not committed to doing this quite yet... but here for posterity.

• LoopBack runtime consists of multiple modules
• LoopBack should have a well-defined way to declare extension points and extensions to provide extensibility/pluggability
• Should we explore dependency injection?
• What is the packaging model for extensions (components/plugins)?
  • https://code.visualstudio.com/docs/extensions/overview

A way for us to reflect the changes in the source code to an online version. Doesn't need to be 100%, just something working.

• Discussion
• Whether we or throw it up or not

https://strongloop.github.io/loopback-next-apidocs/

See https://github.com/fastify/fastify/blob/master/docs/Validation-And-Serialize.md#serialize, https://www.npmjs.com/package/fast-json-stringify, consider also https://www.npmjs.com/package/fast-safe-stringify.

The fastify framework claims it's gaining 1-4x speed-up from using this module.

Since our routes (controller methods) provide swagger metadata describing the expected output format in a JSON-Schema-like format, we should be able to leverage this metadata to improve the performance.

There are many responsibilities in loopback-datasource-juggler today. We need to decompose them into separate modules for different concerns.

The following slides outline some of the main perspectives around juggler as potential candidates:

LoopBack-Model-Composition.pptx

when I try to return an object I always get the following error on the console, and no response is returned,

loopback-next seems to work only for string data type in response

(node:20186) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): TypeError: First argument must be a string or Buffer
(node:20186) DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

For consistent coding styles. http://editorconfig.org/

https://github.com/louischatriot/nedb

@raymondfeng Thoughts?

See https://github.com/strongloop/loopback-next/wiki/Overview

• Clean up the wiki page
• Fill in Overview table with terms and simple descriptions
• Update wiki page contents
  • Fix up architecture image @ritch @superkhau
    • Replaced image with simple array diagram for now
  • Create issues to fill in content for individual construct sections
    • #197 #198 #199 #200 #201 #202 #203 #204 #205 #206
• Create an issue for @crandmck to migrate contents to LoopBack.io @superkhau

Taking notes on wants from community here (ie. what we hear):

• GUI tool for ACLs
• NeDB to replace memory connector

I understand the desire to initially keep the discussion and development of LB.next internal, for reasons of speed and efficiency and to ensure that focus is on "our" needs vs. rest of the world.

Nevertheless, this is an open source project, so at some point we need to change to open development. Also, at some point we will start releasing it to the public.

Rather than simply presenting the next version as a fait accompli for people to take or leave (or just gripe about), I suggest we have a thoughtful community strategy. If there has been detailed discussion of this, I'm not aware of it.

Here are some suggestions:

• Once the main outlines of the release are in view, write a blog, presenting the high-level goals, priorities, and approach for the next version. (I assume this is a given.) Initial blog doesn't need a lot of detail; just a high-level announcement with sketches of the plans.
• Along with this, we should create a public repo to discuss the release. Technically, we could just make this repo public, but we probably don't want to expose everything here publicly. I think it's critical to solicit community input, regardless of how much we actually take action on.
• Meet with the developer evangelists (and any others appropriate e.g. Ashley McClelland) to get them "in the loop," get feedback, etc. They need to be "on board" with the general goals and strategy so they can promote it. They are also important stakeholders as community representatives, bloggers, etc.
• Set expectations about target schedule, community processes, etc., and publicize them.
• Plan a series of blogs about major features and/or milestone releases. (Someone needs to own this--who?)

Most importantly, we must avoid alienating the community by giving the appearance of ignoring its input or not being good "open-source citizens."

Description/Steps to reproduce

Expected result

Additional information

Moving from https://github.com/strongloop-internal/scrum-loopback/issues/1344

Example code from #79 had bugs in it when landed with @bajtos.

• Revert #83
• Revert #84
• Fix tests and linting properly

Lets try this

https://lernajs.io/

This issue is to track the initial lerna configuration

• create packages/loopback
• copy existing meta files
• stub out all classes
• stub out tests (not framework, just for sanity)
• update this list with classes for impl checklist (or create new issue?)

Like tasks.json -- will lower barrier to entry for common loopback related tasks.