Extensions!

[kjdelisle]

@strongloop/loopback-next

Overview

We're looking to see what sort of extensions people would like for loopback-next. Building a list of desired functionality that you want to see will give us a list of ideas to work with.

Once we've got a list of extensions, we'll begin reaching out to you to work with you to make these components/extensions. The goal here will be that you, the community, will own these extensions.

We'll work with you to build these items, and as they progress, we'll get feedback on things like:

• current documentation (how hard was it to get started, find answers to questions, etc)
• current API (are the current interfaces difficult to work with, missing things you think are essential, etc)

Post Your Ideas

Make a comment below with your idea, and include the following:

• Purpose of the extension
• How long you think it would take (roughly) to make this extension
• Please don't hesitate to post your ideas, even if you won't be able to implement them!

Vote for Ideas

If you like an idea:

• please give it a 👍 on the comment
• please do not make a comment saying "+1" or the like.

If you don't like an idea:

• please give it a 👎
• again, don't say "-1" in a separate comment

If you're dead-set on making an extension, feel free to start as soon as possible!
Not a member of @strongloop/loopback-next ? That's okay! We still want to hear from you!

Feel free to share links to this issue to everyone you think would love to participate!

UPDATE: See below for an example proposal. There's no particular template, so feel free to phrase it in whatever way suits you, as long as you cover those three bullet points.

UPDATE#2: There are more wish list for potential extensions in #512

[kjdelisle]

RequestContext Extension

Purpose

Using the existing ParameterObject definitions, and your OpenAPI spec, make a new custom Sequence extension that automatically converts incoming requests into POTOs (Plain Old TypeScript Objects) that will simplify handling of incoming arguments and parameters.

Example:

const offsetSpec: ParameterObject = {
         name: 'offsetSpec',
         type: 'number',
         in: 'query',
};

const pageSizeSpec: ParameterObject = {
         name: 'pageSize',
         type: 'number',
         in: 'query',
};

const List: RequestObject = {
   parameters: [
     offsetSpec,
     pageSizeSpec,
   ]
};

class MyController {
  @operation('get', '/', {responses})
  @request(List)
  list(list: List) {
    // Auto-populate a List (RequestObject) instance based on provided values
  }
}

See #476 for a complete proposal.

Why?

• Don't have to deal with parsing requests yourself; it gets turned into a request object for you!
• You can make those objects extensions of your models (ex. ListRequest extends List) to transform those objects into logical model instances for ease-of-use in your Repository implementation(s).

Estimated Development Time

Assuming no technical blockers, I'd roughly estimate this to take approx. two weeks for development and unit testing

Will You Build It?

I would be willing to build this myself, with some help of course. :)

[raymondfeng]

I just created a wish list for potential extensions to inspire discussions - #512.

[MartinCerny-awin]

Audit Log

Log changes performed on models. It would help to keep track of who used, created or changed an entity and the point in time this happened.

The same model that is being audited would be created with added properties mentioned in what should be stored section. This model will get updated when audit action happens.

When should audit happen (taken from #2872)

1. We give users the option which RESTfull endpoint (or which model) they want to have the audit middleware active for. Or introducing exceptions option which makes the middleware active for all endpoints except the ones mentioned in exceptions
2. We give them option which req.methods they want to have this middleware active for... I think it does not make sense to have this middleware active for req.method == 'GET' since this middleware would become a bottleneck of the application and you would not get that useful information either.

What should be stored

• Model properites
• Created timestamp
• Modified timestamp
• HTTP method
• Path
• User Id

[bajtos]

Cross-posting from #119

Real-Time features

I'm opening this thread to discuss and define a scope for real-time functionalities possibly provided by LB-Next.

Currently there are implemented functionalities like event streams, but honestly are not helpful at all when building real life applications, therefore I have built several real-time approaches on top of loopback, which I believe 2 were the most important.

1.- Implemented PubSub functionality.
2.- Implemented Firebase alike interface.

[jackrvaughan]

ACL Restrictions on Model Properties

Restrict certain model properties to different user types. For example, a user model could have an account-type property that could only be changed by an admin and not by the owner (but the rest of the model could be changed by the owner).

Will You Build It?

I don't think I'd know where/how to start - but I could definitely try with some guidance.

[akashjarad]

Loopback mqtt/amqp support.
make an extension for MQTT protocol.
Will You Build It?
i am willing to contribute , and need guidance .

[rpinaa]

Features!

• Define validating data inside @Property annotation like Java Bean Validation (https://docs.oracle.com/javaee/6/tutorial/doc/gircz.html). Making this approach we can delegate the business constraints to domain-model layer.
• Standardize the environment profiles, local (default), development, staging and production; perhaps using the loopback 3.x.x functionality or making it better.
• Improve the transactional support for relational data bases, helping it with an annotation @transactional and define isolation levels like loopback 3.x.x approach.

[monster910]

API Tool Improvements

1. Make a custom API and expose it to explorer
   https://groups.google.com/forum/#!searchin/loopbackjs/swagger%7Csort:date/loopbackjs/l6FQGCjNpEY/rrTqHFbZAQAJ

2. Make a custom API and generate swagger def from it. Same as RFC: Monorepo #1 above except make sure the export to swagger works

3. Improved error handing for APIs using 400 and 500 HTML status codes and allow the explorer to test those cases

4. Generate swagger properly from Initial LoopBack Core Refactor: Stubs #3 above

5. Ability to defined a API that is NOT attached to a model

Will You Build It?

Perhaps

[ganeshkbhat]

Feature/External Component Support

Please remove whatever is implemented. I have not read 4.0 docs completely

• Current 3.0 like generators (Model, Relation, API, Swagger support, etc)
• Model property level ACL
• Multi-Tenant level support (add remove model properties for specific tenant, different ACLs for tenant) for models
• Flow Support (possible extended component for Workflow support component based on BPMN/CMMN)
• OAuth Server (Auth/Resource) / Login system External Component
• Comprehensive Storage External Component
• Comprehensive DB Support like 3.0 Single API - Multiple DB Adaptor Component
• Working Example or Implementation based Documentation (bettered). Currently new loopback users like me can find it blocking to implement some sections without working example

Will you build it?

I would definitely like to contribute if I have guidance

[virkt25]

@ganeshkbhat Great list! Is there any one in particular you would be interested in starting with, depending on which we can see who can help with the guidance from the team.

[dhmlau]

Thanks for those who've posted their wish list / ideas in this issue, I've copied your content to #512, so that we have one place regarding the extension wish list. Please continue the discussion in #512 instead. Thanks!

Closing it in favor of #512.