SPIKE - Migrate LB3 to LB4 is possible

[dhmlau]

Acceptance Criteria

• Attempt to migrate a LB3 application to LB4, testing each of these areas:
  • Reuse
    • Models
      • Properties
      • Relationships
  • LB3 Juggler
    • Operation hooks
    • Properties/Relationships
  • Remote hooks
• Note which areas are laden with friction as areas for improvement/areas that need tooling

[Setogit]

LoopBack Next is probably the biggest architectural change we ever made to LoopBack since the first release.

IBM Cloud business as a whole, API Connect in particular, we are trying to expand the business. GBS and the company's Sales&Marketing effort is aligned to the direction.

Purpose

In this spike, I will explore and come up with a list of ENGINEERING OPTIONS AND VALUES to execute in LB Next Beta for:
a. LB 2/3 users migrating to LB Next,
b. New users to start LB Next development, and
c. Beneficial for Both

[Setogit]

A couple of points/thought as a result of this spike:

• (1) A task is going on in this sprint to implement Repository/Model in the hello-world. From there, we should figure out the migration story/support tool from v2,v3 model/juggler to LB.Next repository.

Note: relationship feature is not currently supported in repository if I understand it correctly. This information might be out-dated..

• (2) It's valuable for both existing and new users to beef up the OpenAPI-based solution pipeline, i.e., building/debugging specs using the swagger ( https://editor.swagger.io ), spec validation in each package ( already implemented in LB.Next using swagger-parser Nodejs package), and runtime API testing against exiting(v2,v3) or new (LB.Next) service with real data using Dredd package ( initial working sample code is in loopback-next-hello-world )

• (3) For remote methods -- quick solution is to document the steps. tool may or may not be worthwhile because they

• (4) it's important to put equal or more emphasis on new users because a. it's IBM' strategic direction to drum up business in Cloud using API Connect story; GBS is deploying resource to chase businesses with API Connect offerings. The target enterprise customers are mostly new and are looking for next-generation solutions with long-term IBM commitment.

In general, it seems more cost effective to focus on new usersand extend the solution for existing users in a 80:20 way. We should invest in building and demonstrating simple/solid values with LB.Next so that new as well as the existing users clearly see the value to climb up to the top of the LB.Next mountain as opposed to try to pave the road, in a sense, for the existing users (migration path). Note that each user lives in a different house, paving the road from each house to the mountain is obviously not cost effective.