-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1st party integration with user protocols #21
Comments
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.
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! |
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).
I wonder if we could make something similar but with the protocol decoupled from the web library.
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? |
@drawm This is the thing we developped at SSTK, right ? |
Its based on the same idea yes! |
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.
The text was updated successfully, but these errors were encountered: