Date/Time

Or in your local time:

• https://www.timeanddate.com/worldclock/?iso=2020-05-28T17:00:00

Agenda

Extracted from web-server-frameworks-agenda labelled issues and pull requests from nodejs/web-server-frameworks prior to the meeting.

• meeting: discuss gaps in autogenerated meeting #46
• http: IncomingMessage does not emit error on premature close #41
• Discuss modules in CITGM #35
• Improved set header and set cookie experience #32
• 'stream' vs 'request' API #19

Invited

@nodejs/web-server-frameworks

Links

• Minutes: https://docs.google.com/document/d/19ONqNt6UUkjpyNipxEztUUl4RHh5cK8VJpX2bK0QZps/edit?usp=sharing

Joining the meeting

• link for participants: https://zoom.us/j/94317794411
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

This is related to a comment I left on a gist that was posted somewhere here; I'm interested in the ability to return a ServerResponse object, instead of using a created one. I have a library, http-transform, that allows you to do this (more-or-less, see below).

An upside to this is it lets you use pipe(), a downside is you don't know the capabilities of the receiving end (if it's HTTP/1.1, HTTP/2, etc). However, that responses use completely generic HTTP semantics instead of encoding-specific semantics could itself be seen as an upshot in some cases.

This is likely a poor way to do all Node.js HTTP responses, but it seems to me a framework should be able to do things this way.

I'm looking to discuss some of the limitations of Node.js that make this difficult, like in the http and stream modules. Is this a good topic for discussion?

Creating this issue as a remind to myself to complete some of the necessary book keeping for our previous 2 two meetings.

#40
#36

The main task is to review the discussions of each meeting, update relevant issues, and start closing out some of the open issues in the repo.

I do have time to work on this before our next meeting so this will be completed by then.

Follow up issue from OpenJS World collab summit discussion.

This issue will track the work on planning the technical work for the future http modules discussed during our collab summit.

I'll leave it to @jasnell to kick us off 😄

I would like to have a discussion with @ronag or @mcollina about the future of HTTP client and Undici (which just moved to Node.js) with us and how it aligns with the future HTTP technical plans we have been discussing.

Date/Time

Or in your local time:

• https://www.timeanddate.com/worldclock/?iso=2020-04-16T13:00:00

Agenda

Extracted from web-server-frameworks-agenda labelled issues and pull requests from nodejs/web-server-frameworks prior to the meeting.

• Discuss modules in CITGM #35
• Improved set header and set cookie experience #32
• 'stream' vs 'request' API #19
• docs: join instructions in README.md #4

Invited

@nodejs/web-server-frameworks

Links

• Minutes:

Joining the meeting

• link for participants: https://zoom.us/j/951032369
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

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.

Date/Time

Or in your local time:

• https://www.timeanddate.com/worldclock/?iso=2020-07-30T17:00:00

Agenda

Extracted from web-server-frameworks-agenda labelled issues and pull requests from nodejs/web-server-frameworks prior to the meeting.

• Future of HTTP Technical Plan #55
• Future of HTTP Organization Plan #54

Invited

@nodejs/web-server-frameworks

Links

• Minutes:

Joining the meeting

• link for participants: https://zoom.us/j/94317794411
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

Date/Time

Or in your local time:

• https://www.timeanddate.com/worldclock/?iso=2020-09-17T17:00:00

Agenda

Extracted from web-server-frameworks-agenda labelled issues and pull requests from nodejs/web-server-frameworks prior to the meeting.

• discuss the future of HTTP client and Undici #66
• Future of HTTP Technical Plan #55
• Future of HTTP Organization Plan #54

Invited

@nodejs/web-server-frameworks

Links

• Minutes:

Joining the meeting

• link for participants: https://zoom.us/j/94317794411
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

On the Express TC meeting we discussed testing for our dependencies, especially for v5 and were thinking we need a better way to integrate groups of modules to CITGM. What do other frameworks do for this?

If possible I would like to be added. Thank you

Date/Time

Or in your local time:

• https://www.timeanddate.com/worldclock/?iso=2020-04-30T17:00:00

Agenda

Extracted from web-server-frameworks-agenda labelled issues and pull requests from nodejs/web-server-frameworks prior to the meeting.

• http: response does not emit error on premature close #41
• Improved set header and set cookie experience #32
• Discuss modules in CITGM #35
• 'stream' vs 'request' API #19
• docs: join instructions in README.md #4

Invited

@nodejs/web-server-frameworks

Links

• Minutes: https://docs.google.com/document/d/1JAXtu-DHZYv1Hod1Eq6BqqD85bG_UvTdCwU3V3P0vCc/edit?usp=sharing

Joining the meeting

• link for participants: https://zoom.us/j/94317794411
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

In a recent thread on the cookie module it became clear that the core setHeader api is not very optimal for some use cases. The main issue is that it does not support progressively adding multiple headers of the same name. The set-cookie header is the most clear example of this because applications often set multiple cookies in one response.

I think there is opportunity to pull some of the behaviors of cookie and cookies into the setHeader method. If we were able to "append header" it would help with the progressive addition of set-cookie headers.

But I wanted to also field the idea of moving a full cookie parsing implementation into node. Is there a clear reason why this is a bad idea? I recognize that small core is a feature, but the ease of a using doing res.setCookie('token', '...') seems to be pretty compelling IMO.

I would like to propose an agenda item for the first meeting wherein the team defines the scope of what we are trying to accomplish and what constitutes a web-server-framework. We have a fine starting place as outlined within the goals, but a more specific scope will help us further narrow the work and expectations of our community.

As a starting place I offer the following questions that I feel should be considered...

1. What is the team specifically trying to accomplish?
2. What qualities define a web server-framework?
3. What are some of the known issues that web-server-frameworks have that could be addressed or advocated by this team?
4. What is the definition of success for this team?

Thoughts and discussion welcome.

The first step for scheduling the meeting will be picking a day. Can everyone reference their schedule and the following calendars when voting?

The poll: https://doodle.com/poll/aknz3yhemgy5mis3

Note: you can vote yes with a single click and "yes, if necessary" by clicking twice. Vote for as many days as you are available for.

Existing Node.js and OpenJS Foundation calendars:

• Node.js Calendar
• OpenJS Foundation Calendar

cc: @nodejs/web-server-frameworks

To continue our discussion from the meeting today, we want to have an API design for the "mid-teir" which frameworks can build on top. To get started on this, we need to setup a deep dive discussion. Topics for that agenda:

1. What is our design philosophy (small core, usable end user api, etc)?
2. Do we prioritize compatibility with similar web standard apis?
3. What is our balance between performance and developer expirence?

Once we have established that, I think we can start digging into more specifics like:

1. Should we offer a cookie setter/getter api?
2. Should we have a send like file server?
3. Do we expose stream apis, hooks, etc?

The question I have is, do we want to use the regularly scheduled meeting for this? Thursday, August 6⋅6:00 – 7:00am PST?

Date/Time

Or in your local time:

• https://www.timeanddate.com/worldclock/?iso=2020-06-25T17:00:00

Agenda

Extracted from web-server-frameworks-agenda labelled issues and pull requests from nodejs/web-server-frameworks prior to the meeting.

• Discuss modules in CITGM #35
• Improved set header and set cookie experience #32

Invited

@nodejs/web-server-frameworks

Links

• Minutes:

Joining the meeting

• link for participants: https://zoom.us/j/94317794411
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

Any community member or contributor can ask that something be added to the next meeting's agenda by logging a GitHub Issue. Any Collaborator, Team member or the moderator can add the item to the agenda by adding the web-server-frameworks-agenda tag to the issue.

👋 I would like to join

Date/Time

Or in your local time:

• https://www.timeanddate.com/worldclock/?iso=2020-08-06T13:00:00

Agenda

Extracted from web-server-frameworks-agenda labelled issues and pull requests from nodejs/web-server-frameworks prior to the meeting.

• Future of HTTP Technical Plan #55
• Future of HTTP Organization Plan #54

Invited

@nodejs/web-server-frameworks

Links

• Minutes:

Joining the meeting

• link for participants: https://zoom.us/j/94317794411
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

Follow up issue from OpenJS World collab summit discussion.

This issue will track the work on planning the organization that will potentially manage http related modules.

Hi, I am hubvue. I developing a Node.js framework. I would like to be a part of this team.

Date/Time

Or in your local time:

• https://www.timeanddate.com/worldclock/?iso=2020-10-01T17:00:00

Agenda

Extracted from web-server-frameworks-agenda labelled issues and pull requests from nodejs/web-server-frameworks prior to the meeting.

• Future of HTTP High Level API Design #60
• Future of HTTP Technical Plan #55
• Future of HTTP Organization Plan #54

Invited

@nodejs/web-server-frameworks

Links

• Minutes:

Joining the meeting

• link for participants: https://zoom.us/j/94317794411
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

I put together some basic governance to work off of. It includes:

• how to add new members
• frequency of meetings and where meetings take place
  • policy for adding agenda items included
• consensus seeking process
• pull-request review practices
  • fast-track policy included

This is based on how we've done things in other teams, but you might not all like how it's laid out. So consider this issue a way of making it clear that y'all can change this as much or as little as you like.

I would like to organize a session on the OpenJS Collaborator Summit about HTTP & HTTP2 & HTTP3 evolution in Node.js and invite both framework maintainers and Node.js collaborators to share their perspective.

Will that be of interest? Or do we think we could cover this during normal calls?

cc @nodejs/http as well.

Date/Time

Or in your local time:

• https://www.timeanddate.com/worldclock/?iso=2020-07-09T13:00:00

Agenda

Extracted from web-server-frameworks-agenda labelled issues and pull requests from nodejs/web-server-frameworks prior to the meeting.

• Future of HTTP Organization Plan #54
• Future of HTTP Technical Plan #55
• Discuss modules in CITGM #35
• Improved set header and set cookie experience #32

Invited

@nodejs/web-server-frameworks

Links

• Minutes: https://docs.google.com/document/d/1RCbqM-tTi_B7CyIQT17Wc9r6T6-xKimQW_EI84cq1Ng/edit?usp=sharing

Joining the meeting

• link for participants: https://zoom.us/j/94317794411
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

Date/Time

Or in your local time:

• https://www.timeanddate.com/worldclock/?iso=2020-10-15T17:00:00

Agenda

Extracted from web-server-frameworks-agenda labelled issues and pull requests from nodejs/web-server-frameworks prior to the meeting.

• URL's on incoming requests #71
• discuss the future of HTTP client and Undici #66
• Future of HTTP High Level API Design #60
• Future of HTTP Technical Plan #55
• Future of HTTP Organization Plan #54

Invited

@nodejs/web-server-frameworks

Links

• Minutes: https://hackmd.io/@nottherealwes/ByIV-ZIvD

Joining the meeting

• link for participants: https://zoom.us/j/94317794411
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

Initial context: nodejs/node#12682

I think the new api's should use URL as the basis for req.url (or whatever equivalent we expose). As you can see from the thread above, there is some question about how today these are relative urls and the new spec does not support that. My thought, and what I think we need to discuss, is that the "base" should be derived from the incoming request headers and fall back to the server address.

If we come to an agreement on this I am happy to write up a more detailed description. Agenda added so we can discuss in the next meeting as well.

It's a common use case to need access to the request data, (ex: headers) further down the user code, or to want to store stateful information that is scoped to a specific request. - this is a concept present in other languages (like PHP), or is a use of thread caching in Java, for example.

There are multiple ways to do this right now, either via the domains API, continuation-local-storage or cls-hooked. Unfortunately, these are either deprecated or introduce weird behaviors, memory leaks and a significant performance overhead.

I'm opening this to debate that this is an obstacle that API developers simply have to deal with, or if there's room for improvement in Node/ Web frameworks.

Hi! This is Ajay. I would like to be a part of this team.

I've automated the process of updating the member list using ncu-team sync (included with node-core-utils). There are still 12 members who have to accept the invite before they will be included in the list, and the list will need to be manually updated.

This issue to to make sure that doesn't get missed (and that those 12 7 don't feel left out ❤️)

edit: more accepted I've update count

While HTTP APIs are very popular today, REST, Hypermedia and HATEOAS - while offering many great opportunities for API developers and consumers - never got broadly adopted.

Having build Hypermedia/HATEOAS APIs in .NET and Node.js with several customers one of the biggest issues I experienced was that there was no common way to create Hypermedia across frameworks/libraries even on the same platform.

Having native support for common Hypermedia formats like Siren, Ion, HAL, CJ and HTTP Problem Details should make it easier for developers to build truly Restful APIs and gain benefits with almost no efforts.

Phil Sturgeon recently has written an great sum up what web frameworks should support today to build great APIs.

A while a go I've implemented a modular set of libraries to create HTTP Problem Details (RFC 7807) which consists of two HTTP framework agnostic libraries:

• http-problem-details: create HTTP-Problem documents according to RFC 7807
• http-problem-details-mapper: map Errors to HTTP Problem documents by convention

For use with e.g. express, there exists express-http-problem-details - another library, which is a express middleware that handles errors in requests and returns HTTP Problem documents created using the convention defined in http-problem-details-mapper.

I think there should be common support for creation of Hypermedia Documents based on Hypermedia factors so that folks who invent their own Hypermedia type could easily build support for every web framework.

Time

UTC Fri 24-Jan-2020 15:00 (03:00 PM):

Or in your local time:

• https://www.timeanddate.com/worldclock/converter.html?iso=20200124T150000&p1=1440&p2=179&p3=137&p4=136&p5=195&p6=37&p7=123&p8=44&p9=33&p10=235&p11=248&p12=240

Links

• Minutes Google Doc: https://docs.google.com/document/d/1jsD8nDUyRvk4FrghWRHBptOvoXX4CDdlOC2vsigzGFs/edit?usp=sharing

Agenda

https://github.com/nodejs/web-server-frameworks/issues?q=is%3Aissue+is%3Aopen+label%3Aweb-server-frameworks-agenda

• Review Governance #1
• Joining #4
• Define Scope #18

Invited

• @nodejs/web-server-frameworks
• Pending invites: https://github.com/nodejs/web-server-frameworks/issues?q=is%3Aissue+is%3Aopen+label%3Amembership-request

Observers/Guests

Joining the meeting

• link for participants: https://zoom.us/j/827095725
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

When/if regular meetings are scheduled through the calendar they can be auto-generated with a PR to https://github.com/nodejs/create-node-meeting-artifacts

I find the current design of having a req and res API a bit unfortunate.

Currently they act as if they would be decoupled. However, this is not the case and it becomes very obvious during destroy().

Consider the following:

const req = http.request(...)
src.pipe(req)
req.on('finish', () => {
  req.on('close', common.mustCall());
  req.on('error', common.mustNotCall());

  // ... later

  // I would expect this to `autoDestroy` here.
  req.res.destroy(new Error('kaboom')); // This error is propagated to the request object, even though it was successful i.e. 'finish'?
}):

And vice versa: destroying the request after it has "completed" would destroy the response.

This has recently become a bit more obvious to me given recent issues with pipeline which has to have special cases for these objects due to this coupling.

What is the route we would prefer here:

1. Just leave it as is.
2. Try to decouple the two objects, i.e. when the request has 'finish':ed it decouples it self from the socket/response and destroys itself, as a normal stream, and the response lives its own life.
3. Try to convert the Request object in a Duplex where it would just emit itself on 'response' as a compat.

Currently the API is some kind of hybrid of 2 and 3, i.e. it behaves as if the two objects were a single Duplex instance, but they look like two separate streams.

This is an issue that got stuck in the Node repo due to concerns of breaking the ecosystem. Thought it might be worth a quick look in this group to see whether we find a solution we haven't considered yet?

The problem here is that instead of emitting an ECONNRESET 'error' on the IncomingMessage object we emit 'aborted' which is surprising when the object is sent in a function that expects a regular stream.

function myStreamProcessor(stream, cb) {
  // Stream logic that will deadlock if stream 
  // is an `IncomingMessage` since it does not listen to `'aborted'`
  stream
    .on('error, cb)
    .on('data', /* do something */)
    .on('end', cb)
}

The current workaround, which is probably good enough for most cases, is to encourage usage of pipeline which properly handles/normalizes this issue.

This is not a totally uncommon issue, e.g. I saw it recently at https://github.com/szmarczak/http-timer (3,233,355 weekly downloads) where an 'aborted' listener is missing and instead an 'error' listener is registered.

nodejs/node#28172 (issue)
nodejs/node#28677 (closed proposal PR)

I would recommend a read through of the comments for PR above to understand existing concerns.

Hi folks,

I would like to align on the recurring meeting days and time.

Should we have 2 alternating times (6am PST and 10am PST), like the package maintenance WG?

I specifically mentioned 6am and 10am PST because our previous meeting was 6am and 10am was the most voted time on the Doodle. Not sure if 6am works well for everyone in California.

Should we have another vote?

Is it working well? What's the experience? Do we have any significant issues to address?

Date/Time

Or in your local time:

• https://www.timeanddate.com/worldclock/?iso=2020-08-20T17:00:00

Agenda

Extracted from web-server-frameworks-agenda labelled issues and pull requests from nodejs/web-server-frameworks prior to the meeting.

• Future of HTTP Technical Plan #55
• Future of HTTP Organization Plan #54

Invited

@nodejs/web-server-frameworks

Links

• Minutes:

Joining the meeting

• link for participants: https://zoom.us/j/94317794411
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

Hi, I would like to join the team.

Date/Time

Or in your local time:

• https://www.timeanddate.com/worldclock/?iso=2020-06-11T13:00:00

Agenda

Extracted from web-server-frameworks-agenda labelled issues and pull requests from nodejs/web-server-frameworks prior to the meeting.

• Discuss modules in CITGM #35
• Improved set header and set cookie experience #32

Invited

@nodejs/web-server-frameworks

Links

• Minutes:

Joining the meeting

• link for participants: https://zoom.us/j/94317794411
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

Date/Time

Or in your local time:

• https://www.timeanddate.com/worldclock/?iso=2020-06-25T17:00:00

Agenda

Extracted from web-server-frameworks-agenda labelled issues and pull requests from nodejs/web-server-frameworks prior to the meeting.

• Discuss modules in CITGM #35
• Improved set header and set cookie experience #32

Invited

@nodejs/web-server-frameworks

Links

• Minutes:

Joining the meeting

• link for participants: https://zoom.us/j/94317794411
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

I think @jeffijoe (Jeff Hansen) must be added(if he interested) as good package https://github.com/jeffijoe/awilix.

Most important problem on Node.js development part is dependency management before web frameworks.

I think better to lookup https://www.php-fig.org/ for experience for most common use cases of development of all frameworks lead developers in Node.js way of course.

Date/Time

Or in your local time:

• https://www.timeanddate.com/worldclock/?iso=2020-05-14T13:00:00

Agenda

Extracted from web-server-frameworks-agenda labelled issues and pull requests from nodejs/web-server-frameworks prior to the meeting.

• http: IncomingMessage does not emit error on premature close #41
• Discuss modules in CITGM #35
• Improved set header and set cookie experience #32
• 'stream' vs 'request' API #19
• docs: join instructions in README.md #4

Invited

@nodejs/web-server-frameworks

Links

• Minutes:

Joining the meeting

• link for participants: https://zoom.us/j/951032369
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

Date/Time

Or in your local time:

• https://www.timeanddate.com/worldclock/?iso=2020-09-03T17:00:00

Agenda

Extracted from web-server-frameworks-agenda labelled issues and pull requests from nodejs/web-server-frameworks prior to the meeting.

• Future of HTTP Technical Plan #55
• Future of HTTP Organization Plan #54

Invited

@nodejs/web-server-frameworks

Links

• Minutes:

Joining the meeting

• link for participants: https://zoom.us/j/94317794411
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

Time

UTC Thu 19-Mar-2020 13:00 (01:00 PM):

Links

• Minutes Google Doc: https://docs.google.com/document/d/15wUnqWuTk7krNPgpRdcAhgJuaBTmLWzFQE6Y0TxYccE/edit?usp=sharing

Agenda

web-server-frameworks-agenda

• Improved set header and set cookie experience #32
• 'stream' vs 'request' API #19
• docs: join instructions in README.md #4
• Review Governance #1
• Disucss modules in CITGM #35

Invited

• @nodejs/web-server-frameworks
• Pending invites: https://github.com/nodejs/web-server-frameworks/issues?q=is%3Aissue+is%3Aopen+label%3Amembership-request

Observers/Guests

Joining the meeting

• link for participants: https://zoom.us/j/951032369
• For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

The next steps on #55 is to understand the underlying apis we will build on top of. Anyone who is interested in this effort, please react below with the time which works best for you.

👍 Friday Sept 11th @ 2pm ET (11pm PT)
🎉 Friday Sept 11th @ 3pm ET (12pm PT)
❤️ Monday Sept 14th @ 12pm ET (8am PT)

This is super informal, and to not put too much pressure on @jasnell I hope only folks deeply invested in helping with this effort will join. If James is alright maybe we can record the session for layer viewing.

cc: @nodejs/web-server-frameworks

NOTE: This is a proposal for discussion. The goal here is to help the team have a conversation around if this is something we would ever want. If the team decides yes, then we could move forward with making it part of the goals and charter and discuss more broadly in the community what this would change.

Would it be productive to pull many low level http related packages under the ownership and governance of Node core? Today the most popular ones live in the jshttp org which is managed by the Express team. Due to this relationship it is common for good additions to be held up or declined because of compatibility issues with Express apis. I am also aware that most of the other popular frameworks have re-implemented some of these for this reason.

I think a better long term model could be for a group like ours to maintain these under the governance of node core. This would mean support sustainability, group ownership of technical direction and added legitimacy and visibility to the packages. The biggest downside I see is migrating the ecosystem is difficult, but I am sure there are other issues to address.

Things to discuss:

• Should this even be considered as a part of the scope for the team?
• We could request a charter from Node to manage these
• How would we pull the existing packages into this? Fork, move repos, re-implement?
• What prior art is there on a node team or wg managing specific packages?

In http2 we got a new API for handling requests where instead of emitting a 'request' event with a request and response object we emit 'stream' with a stream object.

• Is the ecosystem interested into moving towards this API?
• What are the advantages/disadvantages?
• How can we help with this transition? Would a forwards compat layer be possible/helpful/make sense?

Hey,

Thanks for the initiative ! I would be happy to be part of it :).

I've mostly used https://hapi.dev btw.

Franck