1st party integration with user protocols

[fed135]

Is it the right time or place to consider tighter, unified integrations with a subset of prominent user protocols, such as Graphql and grpc ?

The premise being that most web frameworks are built with REST at the core and other protocols are loaded as plugins.

[wesleytodd]

Is it the right time or place to consider tighter, unified integrations with a subset of prominent user protocols, such as Graphql and grpc ?

I think this is a great topic for discussion! I think that a small core is the best approach, and today we have that with just lower level protocol support and userland implementations of the rest. The innovation happening in the high level protocols you mention is great, and I really want to see that continue. Having a core implementation of any of them would stifle that innovation IMO.

The premise being that most web frameworks are built with REST at the core and other protocols are loaded as plugins.

I think this is really the problem with today's landscape. I think we need a better understanding of the problems faced when shoehorning high level things like graphql ontop of a frameworks working at a much lower level.

Express for example is really tightly coupled to the http1 semantics. It makes less and less sense when you are writing anything other than a pure http1 api (rest, rpc over http, etc.). I think the paradigms which many frameworks have can be great for higher level tools, but today it is really difficult to mesh them well, so they really just do as you say "load as plugins".

This actually reminds me that I need to invite @mikermcneil to the group! He has probably the longest experience in maintaining a multi-protocol high-level web framework in the ecosystem!

[drawm]

Maybe its of interest to this conversation. I am working on a project to decouple route implementation from the "web library". (think dependency inversion at the framework level)

The goal is to be able to switch the underlying library without having to rewrite most of the application. It also enable multiple protocols like graphql and swagger (for now, each protocol must be binded to the same web library ie:express but could be changed in the future).

web lib -- register --> framework <-- register -- route
express + graphql + swagger -- register --> framework <-- register-- route implementation

I wonder if we could make something similar but with the protocol decoupled from the web library.
Here's a flow chart I quickly put together.

Web Library is Koa, express or node's http module.
Protocol is graphql, rest, swagger, openapi, jsonapi, etc. It contrain the code to understand the route's schema.
Route Implementation Holds the route's business logic and schema (easy to decouple outside of the framework)
The framework receive each part individually and orchestrate incoming request between each layer.
in -> web library -> protocol -> route implementation -> back to protocol -> web library -> out

Link to svg

graph LR;
  http[Web Library];
  protocol[Protocol];
  route[Route Implementation];
  subgraph Framework;
    ioregister[IO Register];
    ioconnector[IO http & friends]
    routeregister[Route Register]
  end
  http -- register to --> ioregister
  ioregister -- generate --> ioconnector
  protocol -- register to --> ioconnector
  ioconnector -- generate --> routeregister

  route -- register to --> routeregister

@fed135 Is this what you had in mind?

[fed135]

@drawm This is the thing we developped at SSTK, right ?
If it is, then yes. And I've been working on a small framework that implements this and will come up with some docs/slides/articles soon.

[drawm]

Its based on the same idea yes!
Can't wait to see what your implementation :)