Discussion: MVP

[mpicard]

MVP

This document will outline the requirements for a basic release and serve as a discussion page for the MVP.

Requirements

• basic schema type to loopback model mapping
• basic /graphql endpoint

[mpicard]

Feel free to comment and update the requirements. If we could get the loopback model system hooked up to graphql types with fields and field types and serve a graphQL endpoint with any level of resolver fucntionality that would be good. I doubt we'll be able to tackle the resolvers in the first go

Something like:

Loopback model <==> GraphQL Type ==> executable schema ==> /graphql endpoint

[virkt25]

Thanks for the start @mpicard.

Some limitations with LB4 in alpha (developer preview coming soon) are as follows (which affect the MVP).

• I would say the MVP should be as simple as possible ... and for that we can just start with supporting a TypeScript type / interface as the model rather than a LoopBack Model (mostly because the exact definition of a LB4 Model hasn't been determined yet. LB3 Model will be available for backwards compatibility however ... so we can support them next (after MVP of just a TS Object)) ... and eventually we'll support LB4 models once it's determined what that is.

• graphiql would require some additional work so we can serve html/css/js as the current implementation is limited to json/text. We can do this ourselves or wait till it's done (it's planned as part of the API Explorer Extension).

---

• /graphql endpoint. (Configurable). => LB 4 controller exported via a Component

• Model => GraphQL Type (could possibly use a decorator)

• Be able to define / mark a GraphQL Query & Mutation (decorators again perhaps or any other way we want / makes sense)

• Allow users to define the appropriate resolver's / mark functions as such

• I'd suggest using graphql-js implementation under the hood.

• graphiql (pending a better Send action (unless we wanted to implement it earlier))

cc: @beeman

[mpicard]

I like the idea of using a decorator for the model, does loopback 4 have predefined model actions like CRUDL? We could have a decorator to make those mutations. I'd also say use graphql.js under the hood, all the other servers in node seem to be using it so there's no need to reinvent the wheel there

[virkt25]

You can get the CRUD endpoints using the default legacy-juggler-bridge since there isn't a LB4 version of a model yet. We're working on seeing when we'll get around to this and hopefully I can give you a better idea once I know.

For now I'd say it might be best to start implementing it incrementally. Start with just a TS Model (Interface) => Then simple legacy-juggler models => advanced models (we can see demand for such a feature) => then LB4 Model

I don't think enabling each subsequent model should be too much work once we have something basic working. Thoughts?

[mpicard]

That sounds like a good plan! Let's try and touch base soon and make a board so we can chip away at this piece by piece!