├── .github └── ISSUE_TEMPLATE │ └── meeting.md ├── CODE_OF_CONDUCT.md ├── GOVERNANCE.md ├── LICENSE.md ├── README.md └── meetings ├── 2020-01-24.md ├── 2020-03-19.md ├── 2020-04-30.md ├── 2023-12-28.md ├── 2024-01-16.md ├── 2024-03-26.md └── 2024-05-07.md /.github/ISSUE_TEMPLATE/meeting.md: -------------------------------------------------------------------------------- 1 | ## Date/Time 2 | 3 | | Timezone | Date/Time | 4 | |----------|-----------| 5 | <%= [ 6 | 'America/Los_Angeles', 7 | 'America/Denver', 8 | 'America/Chicago', 9 | 'America/New_York', 10 | 'Europe/London', 11 | 'Europe/Amsterdam', 12 | 'Europe/Moscow', 13 | 'Asia/Kolkata', 14 | 'Asia/Shanghai', 15 | 'Asia/Tokyo', 16 | 'Australia/Sydney' 17 | ].map((zone) => { 18 | return `| ${zone} | ${date.setZone(zone).toFormat('EEE dd-MMM-yyyy HH:mm (hh:mm a)')} |` 19 | }).join('\n') %> 20 | 21 | Or in your local time: 22 | * https://www.timeanddate.com/worldclock/?iso=<%= date.toFormat("yyyy-MM-dd'T'HH:mm:ss") %> 23 | 24 | ## Agenda 25 | 26 | Extracted from **<%= agendaLabel %>** labelled issues and pull requests from **<%= owner %>/<%= repo %>** prior to the meeting. 27 | 28 | <%= agendaIssues.map((i) => { 29 | return `* ${i.title} [#${i.number}](${i.html_url})` 30 | }).join('\n') %> 31 | 32 | ## Invited 33 | 34 | @nodejs/web-server-frameworks 35 | 36 | ## Links 37 | 38 | * Minutes: 39 | 40 | ### Joining the meeting 41 | 42 | * link for participants: https://zoom.us/j/94317794411 43 | * For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live 44 | * youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled 45 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | Code of Conduct 2 | 3 | The Node.js project and its initiatives are committed to upholding the Node.js Code of Conduct. 4 | 5 | The Node.js Code of Conduct document can be found at 6 | https://github.com/nodejs/admin/blob/master/CODE_OF_CONDUCT.md 7 | -------------------------------------------------------------------------------- /GOVERNANCE.md: -------------------------------------------------------------------------------- 1 | # Web-Server Frameworks Team 2 | 3 | For the current list of Team members, see the project 4 | [README.md](./README.md). 5 | 6 | ## Members 7 | 8 | The [nodejs/web-server-frameworks](https://github.com/nodejs/web-server-frameworks) GitHub 9 | repository is maintained by the Team and additional Members who are 10 | added on an ongoing basis. 11 | 12 | ## Team Membership 13 | 14 | Team Membership is not time-limited. There is no fixed size of the Team. 15 | 16 | There is no specific set of requirements or qualifications for Team Membership beyond these rules. 17 | 18 | Prospective members should request membership though a PR labelled `membership-request` which adds them to the 19 | [Team membership list](https://github.com/nodejs/web-server-frameworks/blob/master/README.md#web-server-frameworks-team-members). 20 | The PR will be merged in accordance with the [pull request consensus process](#Pull-Requests). 21 | 22 | Team membership will be revisited every 6 months. A PR will be open moving members 23 | without any activity in the past 6 months to a Past Collaborators list. Members 24 | can comment on the PR to keep themselves in the members list. 25 | The PR will be merged in 7 days in accordance with the [pull request consensus process](#Pull-Requests). 26 | 27 | Past collaborators may rejoin the Team using the same process specified 28 | above for prospective members. 29 | 30 | ## Team Meetings 31 | 32 | The Team meets bi-weekly on Zoom.us. A designated moderator 33 | approved by the Team runs the meeting. Each meeting should be 34 | published to YouTube. 35 | 36 | Items are added to the Team agenda that are considered contentious or 37 | are modifications of governance, contribution policy, Team membership, 38 | or release process. 39 | 40 | The intention of the agenda is not to approve or review all patches; 41 | that should happen continuously on GitHub and be handled by the larger 42 | group of Collaborators. 43 | 44 | Any community member or contributor can ask that something be added to 45 | the next meeting's agenda by logging a GitHub Issue. Any Collaborator, 46 | Team member or the moderator can add the item to the agenda by adding 47 | the ***web-server-frameworks-agenda*** tag to the issue. 48 | 49 | Prior to each Team meeting the moderator will share the agenda with 50 | members of the Team. Team members can add any items they like to the 51 | agenda at the beginning of each meeting. The moderator and the Team 52 | cannot veto or remove items. 53 | 54 | The Team may invite persons or representatives from certain projects to 55 | participate in a non-voting capacity. 56 | 57 | Decisions made in meetings must go through the [pull request consensus process](#Pull-Requests). 58 | One of the members present in the meeting will be responsible for opening the PR, 59 | if one doesn't exist already. 60 | 61 | The moderator is responsible for summarizing the discussion of each 62 | agenda item and sends it as a pull request after the meeting. 63 | 64 | ## Consensus Seeking Process 65 | 66 | The Team follows a 67 | [Consensus Seeking](http://en.wikipedia.org/wiki/Consensus-seeking_decision-making) 68 | decision-making model. 69 | 70 | When an agenda item has appeared to reach a consensus, the moderator 71 | will ask "Does anyone object?" as a final call for dissent from the 72 | consensus. 73 | 74 | If an agenda item cannot reach a consensus, a Team member can call for 75 | the item to be decided by a vote or to table the issue to the next 76 | meeting. In both cases the decision must be seconded by a majority of the Team 77 | or else the discussion will continue. Simple majority wins. Only Active 78 | Members participate in a vote. 79 | 80 | ## Pull Requests 81 | 82 | Pull requests that do not change the governance of the team or remove members can 83 | be merged into this repository provided the following conditions have been met: 84 | 85 | * There are no outstanding objections 86 | * There are two approvals by team members 87 | * The PR has been open for at least 48 hours 88 | 89 | Pull requests that change governance of the team or remove members must meet the following conditions 90 | in addition to the ones listed for regular PRs. 91 | 92 | * The PR has been open for at least 7 days. 93 | 94 | If consensus cannot be reached, a pull request may still be landed after a vote 95 | by the members to override outstanding objections. 96 | 97 | ### Fast-Tracking PRs 98 | 99 | Special exception is made for pull requests seeking to make any of the following 100 | changes to this repository: 101 | 102 | - Errata fixes. 103 | - Editorial changes. 104 | - Meeting minutes. 105 | - Updates to the team lists. 106 | - Doc Fixes. 107 | 108 | To propose fast-tracking a pull request, apply the ***fast-track*** label. Then add a comment that members may upvote. 109 | 110 | If someone disagrees with the fast-tracking request, remove the label. Do not fast-track the pull request in that case. 111 | 112 | The pull request may be fast-tracked if two members approve the fast-tracking request. To land, the pull request itself still needs two member approvals. 113 | 114 | Members may request fast-tracking of pull requests they did not author. In that case only, the request itself is also one fast-track approval. Upvote the comment anyway to avoid any doubt. 115 | 116 | 117 | ## Developer's Certificate of Origin 1.1 118 | 119 | By making a contribution to this project, I certify that: 120 | 121 | * (a) The contribution was created in whole or in part by me and I 122 | have the right to submit it under the open source license 123 | indicated in the file; or 124 | 125 | * (b) The contribution is based upon previous work that, to the best 126 | of my knowledge, is covered under an appropriate open source 127 | license and I have the right under that license to submit that 128 | work with modifications, whether created in whole or in part 129 | by me, under the same open source license (unless I am 130 | permitted to submit under a different license), as indicated 131 | in the file; or 132 | 133 | * (c) The contribution was provided directly to me by some other 134 | person who certified (a), (b) or (c) and I have not modified 135 | it. 136 | 137 | * (d) I understand and agree that this project and the contribution 138 | are public and that a record of the contribution (including all 139 | personal information I submit with it, including my sign-off) is 140 | maintained indefinitely and may be redistributed consistent with 141 | this project or the open source license(s) involved. 142 | 143 | 144 | 145 | 146 | [nodejs-modules]: https://github.com/nodejs/modules 147 | [nodejs-core]: https://github.com/nodejs/node 148 | [nodejs-ecmascript-modules]: https://github.com/nodejs/ecmascript-modules 149 | [modules-team-purpose]: ./README.md#purpose 150 | [modules-team-plan]: ./doc/plan-for-new-modules-implementation.md 151 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | MIT License (MIT) 2 | ===================== 3 | 4 | Copyright (c) Node.js web-server-frameworks collaborators 5 | ----------------------------------- 6 | 7 | *Node.js web-server-frameworks listed at * 8 | 9 | Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: 10 | 11 | The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. 12 | 13 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 14 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Web-Server Frameworks Team 2 | 3 | ## Purpose 4 | 5 | The Web-Server Frameworks Team is a place for Node.js framework authors and users to collaborate on the 6 | future direction and feature set of the frameworks and related Node.js core APIs. The main goal of the 7 | team is to improve collaboration across the ecosystem and foster a better dialog between all parties involved. 8 | 9 | ### Goals 10 | 11 | Topics which this team discussed or challenges this team decides to take on should fall under one of the goals of the team: 12 | 13 | - Improve Node.js core api support for frameworks 14 | - Provide feedback and collaboration on Node.js core features and proposals 15 | - Improve collaboration among framework authors 16 | - Provide support for frameworks when security issues or bugs arise 17 | - Be a resource for Node.js security concerns in APIs which touch web frameworks (ex. HTTP1/2/3) 18 | - Collaborate with other Node.js WGs and teams where it makes sense 19 | 20 | Things which should not be done in this repo: 21 | 22 | - Framework wars 23 | - Promotion of specific tools/resource/etc. without a clear topic for collaboration/discussion 24 | - Putting down projects, authors or solutions to a problem 25 | - Determine what is/is not a framework 26 | - Maintain a list of frameworks, framework authors or maintainers 27 | 28 | ## Joining 29 | 30 | We encourage participation from members across the Node.js and JavaScript 31 | ecosystem. Feel free to join scheduled meetings and participate 32 | in the issues within this repository. 33 | 34 | ## How to Join 35 | 36 | Please refer to the [Team Membership](./GOVERNANCE.md#team-membership) section of the Governance document for information on how to join this working group. 37 | 38 | ## Web-Server Frameworks Team Members 39 | 40 | 41 | 42 | - [@Ethan-Arrowood](https://github.com/Ethan-Arrowood) - Ethan Arrowood 43 | - [@jasnell](https://github.com/jasnell) - James M Snell 44 | - [@fed135](https://github.com/fed135) - Frederic Charette 45 | - [@marco-ippolito](https://github.com/marco-ippolito) - Marco Ippolito 46 | - [@mcollina](https://github.com/mcollina) - Matteo Collina 47 | - [@mhdawson](https://github.com/mhdawson) - Michael Dawson 48 | - [@ronag](https://github.com/ronag) - Robert Nagy 49 | - [@sheplu](https://github.com/sheplu) - Jean Burellier 50 | - [@ShogunPanda](https://github.com/ShogunPanda) - Paolo Insogna 51 | - [@wesleytodd](https://github.com/wesleytodd) - Wes Todd 52 | - [@mertcanaltin](https://github.com/mertcanaltin) - Mert Can Altin 53 | - [@metcoder95](https://github.com/metcoder95) - Carlos Fuentes 54 | 55 | 56 | -------------------------------------------------------------------------------- /meetings/2020-01-24.md: -------------------------------------------------------------------------------- 1 | # Node.js Foundation Web Server Frameworks Team Meeting 2020-01-24 2 | 3 | ## Links 4 | 5 | * **Recording**: https://youtu.be/diOA1OWQfmM 6 | * **GitHub Issue**: https://github.com/nodejs/web-server-frameworks/issues/26 7 | * **Minutes Google Doc**: https://docs.google.com/document/d/1jsD8nDUyRvk4FrghWRHBptOvoXX4CDdlOC2vsigzGFs/edit?usp=sharing 8 | 9 | ## Present 10 | 11 | * Peter Marton (@hekike), Restify 12 | * Michael Dawson (@mhdawson) 13 | * Frederic Charette (@fed135) 14 | * Damon Perron Laurin 15 | * Robert Nagy (@ronag) 16 | * Jean Burellier (@sheplu) 17 | * Doug Wilson, Express 18 | * Ethan Arrowood (@Ethan-Arrowood) 19 | * Glen Goodwin (@arei) 20 | * Guilherme Hermeto 21 | * Jozef Flakus (@JozefFlakus) 22 | * Raymond Feng 23 | * Miroslav Bajtos (@bajtos), LoopBack 24 | * Tomas Della Vedova (@delvedor), Fastify 25 | * Gireesh Punathil (@gireeshpunathil) 26 | * Wes Todd, Express (@wesleytodd) 27 | 28 | ## Agenda 29 | 30 | * 1. Review Governance https://github.com/nodejs/web-server-frameworks/issues/1 31 | * Consensus needs 50% of the members 32 | * Gui: Can we have consensus on the GitHub issue or does it require a meeting? 33 | * Michael: In my opinion GH is okay. Key is transparency, for example, if a PR is open for like 48 hours it can be merged. In my opinion, we shouldn’t aim for 50% consensus, more we should look if everyone is okay and nobody speaks up against it. 34 | * Lot’s of people on the list today, probably 50% won’t shop up every time 35 | * Robert: So basically consensus on GH and discuss on this meeting? 36 | * Michael: yes, IMHO 37 | * Gui: what is the process for diagnostics WG? 38 | * Peter: transparency over rules (basically what Michael described) 39 | * Peter: is there any Foundation guideline? It looks inefficient to figure this out per every WG 40 | * Michael: default template: https://github.com/nodejs/TSC/blob/master/BasePolicies/Governance.md, if there is objection -> vote 41 | * Robert: how is the “default one” different from the one in the repo? 42 | * Gui: I think current one says the meeting requires 50% on the meetings 43 | * Michael: I think yes that’s what we should remove because 50% yes doesn’t mean we should ignore other 50%’s opinion 44 | * Ethan: how about proposing change on GH and let’s discuss it on next meeting 45 | * Glen: we could use labels to highlight what needs a consensus (suggest “seeking consensus”) 46 | * Michael: any volunteer to submit that PR? 47 | * Gui: I can do it 48 | * Wess: we don’t need to vote if we are not making critical change. At package maintenance group we propose best practices we are not takin control. I feel that will be the case here as well. 49 | * Jozef: what is the avg. attendee number for WGs? I see it’s 50% for this one today. 50 | * Michael: my experience is that it starts with more people than it gets less. Also, timezones cuts numbers. Not everyone can make ti every meeting. Roughly 25-50% 51 | * Wes: that’s why I believe consensus should happen on GH issues 52 | * Wes: I’ll make more comments offline... 53 | 54 | 55 | * 2. Joining https://github.com/nodejs/web-server-frameworks/pull/4 56 | * Wess: Myles proposed to vote about new members. I think we can be a little bit less process heavy about it. 57 | * Michael: after a couple of meeting attendance we can add them to the GH team 58 | * Wess: if we are not adding them to the Gh team, they are not getting the @ notification like meetings 59 | * Gui: maybe the meeting is the attendance? 60 | * Wess: some people are active but don’t like meetings 61 | * Michael: let’s just once the PR approved, let’s just add them to the team 62 | * Wess: we can just purge the list when people are inactive 63 | * Michael: we can just open an issue asking people if they plan to be active with a reasonable timeline and clean up the list based on responses 64 | * Gui: should we add it to the governance? 65 | * Michael: yes 66 | * Action Item: Gui can do it 67 | 68 | 69 | * Define Scope https://github.com/nodejs/web-server-frameworks/issues/18 70 | * Ethan: I see couple of questions here. 71 | * Glen: (paraphrased) My goal in introducing this agenda item was to foster a little more discussion around the purpose and scope of this team and what we are trying to accomplish. As Wes noted in the issue, we don’t specifically want to outline every feature that qualifies what is or isn’t a framework, but a more generalized review of the objectives/goals for the team. 72 | * Wes: Couple of ideas: see https://github.com/nodejs/web-server-frameworks/blob/master/README.md#goals 73 | * We should create a label for every goal 74 | * Michael: in this repo or node core? 75 | * this repo 76 | * Michael: I could see the usefulness of a web framework label in node core 77 | * Any difference as using GH team as reviewer or pinging? 78 | * Michael: you can search labels 79 | * Michael: there was a conversation earlier about diagnostics - web frameworks integration. Would it be included? 80 | * Hmm, this is the inverse, more like core integration for web frameworks 81 | * Goal wording will be modified to include it 82 | * Next goal: Improve collaboration among framework authors 83 | * Glen: reaching out to framework owners could be a way to go 84 | * Wes: I tried, and everyone responses, but not everyone participated 85 | * Gui: we should aim for collaboration from the community but that shouldn’t be the goal 86 | * Ethan next goal 87 | * Wes: wee see fragmentations with the rise of new frameworks 88 | * Wes: I’d like to see collaboration on best practices, different implementations are healthy and we need them, but not a competition 89 | * Ethan: should we take low-level modules into this WGs? I believe not because we would bring imbalance to the field and force other modules to use them. It could be a blocker for innovation. 90 | * Notes stopped at 4PM UTC…. 91 | 92 | (Resuming notes roughly) 93 | * Discussing what are non goals of the team 94 | * Major point is gatekeeping 95 | * Refrain from lists of frameworks or language that implies lists 96 | * Idea discussed about how to indicate team member details (i.e. whos a maintainer, reasons for being apart of the group) 97 | * Make a members.md instead of including this in the README (Wes will follow up on a member list with more details than name and github handle) 98 | * Concluding agenda 99 | * Discussing next meetings, future meetings, general schedule 100 | * Wes: 2 meetings times, what do we see the best methodology for the biggest turn out here? 101 | * Guil: We should uses consensus through github issue/pr for this matter due to meeting time being over 102 | * Wes: will follow up with scheduling issue. How do we get more people to respond to doodle? 103 | * Guil: give everyone 48hours 104 | * Michael: for this matter we should give longer time. Maybe a week 105 | * Michael: Use an excel spreadsheet like TSC does so we can have a more comprehensive list 106 | * Wes: Agrees, will work on this for the next meeting time planning. Will take this on and follow up. Goal for next meeting is February. 107 | * 108 | 109 | ## Q&A, Other 110 | 111 | ## Upcoming Meetings 112 | 113 | TBD in mind-late feb 114 | 115 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 116 | 117 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 118 | 119 | 120 | -------------------------------------------------------------------------------- /meetings/2020-03-19.md: -------------------------------------------------------------------------------- 1 | # Node.js Foundation Web Server Frameworks Team Meeting 2020-03-19 2 | 3 | ## Links 4 | 5 | * **Recording**: 6 | * **GitHub Issue**: https://github.com/nodejs/web-server-frameworks/issues/36 7 | 8 | ## Present 9 | 10 | * Ethan Arrowood (@Ethan-Arrowood) 11 | * Jean Burellier (@sheplu) 12 | * Gireesh Punathil (@gireeshpunathil) 13 | * Glen R. Goodwin (@arei) 14 | * Michael Dawson (@mhdawson) 15 | * Tomas Della Vedova (@delvedor) 16 | * Wes Todd (@wesleytodd) 17 | 18 | ## Agenda 19 | 20 | * Review Governance [#1](https://github.com/nodejs/web-server-frameworks/issues/1) 21 | * Ethan: are we ready to close. PR opened and landed to adjust. Believe we should 22 | be ready 23 | * Have agreed on 2 different times to make it easier for people from different timezones 24 | to attend. 25 | * Will close issue. 26 | 27 | * docs: join instructions in README.md [#4] (https://github.com/nodejs/web-server-frameworks/pull/4) 28 | * a requested change, but should be able to update today 29 | * will accept all open join requests today as well 30 | * Gireesh, + others we should continue to be open about letting people join easily. 31 | 32 | * 'stream' vs 'request' API [#19](https://github.com/nodejs/web-server-frameworks/issues/19) 33 | * Tomas added http2 support for Fastify using the compat api - did not use stream 34 | * Wes moved request/response out of the main Express repo to better support HTTP2/3; very 35 | soon wants to start more robust support 36 | * Why aren’t we seeing http2 apps? 37 | * Netflix is using it over GRPC 38 | * Many are terminating at a NGINX layer 39 | * Nginx didn’t support a reverse http2 unless in a paid platform so many devs couldn’t do 40 | application layer things like push thus treating apps like http1 41 | * Great example of GraphQL and HTTP3 would be really beneficial for folks 42 | * What are the real benefits of http2? 43 | * Check out auto-push packages: 44 | https://github.com/google/node-h2-auto-push 45 | https://github.com/google/node-fastify-auto-push 46 | https://medium.com/the-node-js-collection/node-js-can-http-2-push-b491894e1bb1 47 | * Communicate more on ‘how is http2 being used in the wild’ 48 | * Is HTTP3 going to have a compat layer? We should ask James 49 | * Action items: Reach out to folks at Cloudflare and Google. Reach out to James. What does HTTP3 look like for the framework layer; do we need to develop a compat layer? 50 | * When do we stop supporting compat layers? 51 | 52 | * Improved set header and set cookie 53 | experience[#32](https://github.com/nodejs/web-server-frameworks/issues/32) 54 | * One of the things problematic in today’s Express cookie module is if you call setHeader it overrides the previous header value 55 | * Could this live in Node core? 56 | * Rather than be specific on cookies, can we expand the header utilities in node core? 57 | * Some breakaways: appendHeader issue, setCookieHeader discussion, cookie or header parsing 58 | * is it too much to bring all header stuff into core? Is it better to focus on just cookies? 59 | * jshttp has a lot of work on this already 60 | * members apart of this group should start maintaining http in core 61 | * members apart of this group can step up to help squash security issues in http related modules in core too 62 | * We should put the callout that we are looking for contributors in this area 63 | * each of the frameworks should look for volunteers to contribute to node.js security 64 | 65 | * Discuss modules in CITGM [#35](https://github.com/nodejs/web-server-frameworks/issues/35) 66 | * Ethan, recently saw on twitter library that would run unit tests for each of your npm 67 | dependencies. Anybody remember the name? This one reads package.json and 68 | clone and runes all of the unit tests. 69 | * Wes, today you can submit PR for modules 70 | 71 | ## Upcoming Meetings 72 | 73 | TBD in mind-late feb 74 | 75 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 76 | 77 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 78 | 79 | 80 | -------------------------------------------------------------------------------- /meetings/2020-04-30.md: -------------------------------------------------------------------------------- 1 | # Node.js Foundation Web Server Frameworks Team Meeting 2020-04-30 2 | 3 | ## Links 4 | 5 | * **Recording**: https://youtu.be/6Wxa0Q0bFjU 6 | * **GitHub Issue**: https://github.com/nodejs/web-server-frameworks/issues/40 7 | 8 | ## Present 9 | 10 | * Michael Dawson (@mhdawson) 11 | * Matteo Collina (@mcollina) 12 | * Wes Todd (@wesleytodd) 13 | * Ethan Arrowood (@ethan-arrowood) 14 | * Tomas Della Vedova (@delvedor) 15 | * Robert Nagy (@ronag) 16 | * Chris Russell 17 | 18 | ## Agenda 19 | 20 | * http: response does not emit error on premature close #41 21 | * Change will affect anyone using raw http 22 | * Want to make sure major frameworks are prepared for this change 23 | * if this lands it would be a major change landing in Node 15 24 | * This would make express core v4 not able to run on Node 15, which should be okay since v4 should be EOL by then 25 | * Matteo’s concern: having to set multiple error handlers (one for request, one for response). 26 | * It is an unfortunate coupling of those two. 27 | * It can be left as is, but it can be brittle for generic streams 28 | * @ronag will make a pr for this and we can continue discussion later 29 | * Can we make this feature opt-in? 30 | * Maybe only throw error if user is watching for it so we don’t crash peoples program 31 | 32 | * Improved set header and set cookie experience #32 33 | * Previously discussed is 34 | * how to better support headers and cookies in Node core. It was discussed that we should not create more work for the core team if we aren’t going to commit to contributing ourselves. That said, we also need to step up in helping on the already existing http related security issues before we start generating more of them. 35 | * Frameworks were asked to encourage their contributors to look into contributing to Node.js core 36 | * Jshttp library has already done a lot of work on these things 37 | * Breakaways include: appendHeader issue, setCookieHeader discussion, cookie or header parsing 38 | * Original concern: adding multiple cookie headers is not a straight forward process in Node core. 39 | * Matteo’s experience: use writeHead. setHeader in http is a mess. Hard to change core. The only way to make something fast was to side step the core implementation and utilize writeHead. 40 | * What is the future of header handling in Node core? 41 | * Remove setHeader? 42 | * Can we refactor this issue into discussing better header management rather than just adding more methods to core 43 | * setHeader works well is you are using Node core, but not great for frameworks 44 | * Can we use MDN header api? (it might be slow) 45 | * If we can make this fast but remain in spec that would be great improvement for Node core 46 | * https://github.com/fastify/fastify/pull/813 https://github.com/fastify/fastify/search?q=writeHead&type=Commits 47 | * If we were to deprecate this lots of documentation and tutorials need to be modified as well 48 | * Headers are very complicated and have lots of nuances that make it hard to handle _perfectly_ so it may be very hard to implement in core correctly. 49 | * Do we need something to replace it if we deprecate setHeader in node core? 50 | * How does this apply to trailers? 51 | * Action item: consider adding MDN Headers api to Node core. The MDN api knows about the Header quirks. 52 | * Discuss modules in CITGM #35 53 | * Previously discussed, nothing worth copying over to here. 54 | * Express dependencies are not in canary so those would need to be added 55 | * Would want to test multiple versions 56 | * 'stream' vs 'request' API #19 57 | * Previously discussed 58 | * Why aren’t we seeing http2 apps? 59 | * Many apps terminate at a NGINX layer due to it not being freely available 60 | * Request for a GraphQL + http3 example 61 | * Request for better documentation on the benefits of http2/3/etc. 62 | * Request for better communication on existing http2 apps 63 | * Is http3 going to have a compat layer? Do we need to help build one? (ask James) 64 | * Public outreach to companies on using 65 | * When do we stop supporting compat layers? 66 | * Matteo has more info on compat layer & stream api. 67 | * Error handling was an issue 68 | * Lots of memory leaks 69 | * Adding the compat layer was what enabled http2 to ship in the first place 70 | * Implementation of http2 for end users is severely lacking thus there is no reason for frameworks to develop stream based http2 support 71 | * Major blocker for http3 is because it requires a patched version of OpenSSL 72 | * Should we put our effort into making compat layers better or making frameworks run on streams? Is either effort worth it right now? 73 | * We should ask “why people aren’t using http2?” 74 | * Broader question: what is the cost of maintaining http2 in Node core? 75 | * https://github.com/nxtedition/node-http2-proxy 76 | * https://github.com/fastify/fastify-http-proxy 77 | * https://www.npmjs.com/package/http2-proxy 78 | 79 | * docs: join instructions in README.md #4 80 | * Previously discussed 81 | * Complete open pr and add other users 82 | -------------------------------------------------------------------------------- /meetings/2023-12-28.md: -------------------------------------------------------------------------------- 1 | # Node.js Web Server Framework team Meeting 2023-18-12 2 | 3 | ## Links 4 | 5 | * **Recording**: 6 | * **GitHub Issue**: https://github.com/nodejs/web-server-frameworks/issues/92 7 | 8 | ## Present 9 | 10 | * Wes Todd - @wesleytodd 11 | * Rafael Gonzaga - @RafaelGSS 12 | * Jean Burellier - @sheplu 13 | * Ethan Arrowood - @Ethan-Arrowood 14 | * Marco ippolito - @marco-ippolito 15 | * Paolo Insogna - @ShogunPanda 16 | 17 | ## Agenda 18 | 19 | * Are we satisfied with continuing to be a “team” and running fairly loose? 20 | * What are our top priorities for 2024? 21 | * Milo 22 | * WinterCG Socket API Spec 23 | * Spec: https://github.com/wintercg/proposal-sockets-api 24 | * Node.js implementation: https://github.com/Ethan-Arrowood/socket 25 | * Will be in draft mode until WinterCG becomes apart of an actual standards body (ECMA is under current proposal): https://github.com/wintercg/admin/issues/58 26 | * Create `nodejs/socket` repository for Node.js implementation of Cloudflare's Socket API · Issue #826 27 | 28 | ## Announcements 29 | 30 | N/A 31 | 32 | ### nodejs/web-server-framework 33 | 34 | - Jean: Global presentation on the history + discussion during NodeconfEU 35 | - WG started to focus on Http server, not other part of the stack 36 | - Paolo: also we discussed other topics like the full http stack (dns, network, …) 37 | - Marco + Paolo: Maybe start working on the new socket API (presented by james during NodeConfEU) 38 | - Wes: global reflection about the name of the Working group. Do we want to rename to englobe a lot more than just HTTP ? 39 | - Ethan: Group started before Undici and some other projects. Primitives needed (and need) to be fixed. Depending on people we can decide on the scope. 40 | - Better parser 41 | - Better low level solution to build on top 42 | - Paolo: most of the groups overlap (between net, http…) 43 | - Wes: Team or WG next year? What would be the difference, different spaces ? 44 | - Ethan: Large scope and we should see what we want to be responsible for. Just including HTTP (http1, http2, quic, http3…) is already a really large scope 45 | - Marco: To not talk about the full ecosystem, do we want to focus on “only” the server part ? 46 | - Paolo: WG or team does not really matter. If we can define the interfaces, then all groups can work in parallel 47 | - Marco: we should restrict the scope 48 | - Wes: Parallel but with a priority list 49 | - James: What are the baseline problems that need to be addressed where the current core is falling short? 50 | - Ethan: can we have a better / faster parser? -> Milo 51 | - Where do we think there is an issue with HTTP core? -> HTTP Parser 52 | - Wes: Plan from 2 years ago 53 | - Low lever part of nodejs 54 | - High level part of nodejs 55 | - Improve the framework users base by adding specific functions to core. 56 | - Cookies 57 | - We should be able / need to document link between changes and update to track what can be updated in parallel 58 | - Paolo: Milo is feature complet 59 | - Following bilbao, capable to be used in webassembly and tried to implement it to undici 60 | - Working on more performance and then being capable of shipping ! 61 | - Nodejs tests suite is already OK 62 | - Milo would be bringing another language to Node.js so other modules could also be ported? 63 | - Wes: Could we have a standalone library part of Node.js that would provide only the core feature needed to be an HTTP server ? with less dependencies than express or fastify. 64 | - Exploratory work as we may have to tests all changes 65 | - James: I agree with what Wes is saying about the “vendor” modules. If this group is wanting to somehow improve all of these low level apis (and I classify http as low level), then it shouldn’t try to update in-place the current ones. They are never going to go away. So the goal should be `node:http` and `node:https` still exists, but eventually `node:` gets added and becomes the way forward 66 | - Rafael: We should do some research and scientific approach to build a foundation and know where we should investigate - not just on “random” part of the project. 67 | - With current and accurate benchmarks we can establish a baseline and be able to really compare 68 | - Wes: the group should focus on developer / user experience but also can be used on some performance - we need to balance both 69 | - Compatibility around http 1 / 2 /3 70 | - What do the consumers of Node.js want? 71 | Work with other teams (Next-10 for community feedback) 72 | - Jean: A good parallelisation would be between user experience and performance 73 | - UX: http stack as this is the main use case for nodejs 74 | - Performance for “core hidden modules” like dns, net… 75 | - Paolo: New way of working with Node.js and framework, for example request / response is used most of the time on serverless technology (lambda, workers…) 76 | - Involve WinterCG 77 | - James: I made the “feel at home with req and res” argument early on with Fastify, and I think my position has changed. If there is a more ergonomic API possibility, use this opportunity to implement it 78 | - Marco: Socket is at the core of the http stack, starting from Socket api is a good way to go bottom up 79 | - Ethan: Update on the WinterCG, TC process … and how we can work together 80 | - Wes: From the start we tightly couple the lowest part of the stack to the user level.We should decouple between the levels 81 | - Low level for performance and standard 82 | - High level to handle the experience across all user interactions 83 | - Paolo: Following a discussion during NodeConfEu, users don’t need to know about HTTP version, this would be automatically setup depending of the request 84 | - Wes: API session design 85 | 86 | 87 | ## Q&A, Other 88 | 89 | ## Upcoming Meetings 90 | 91 | * **Node.js Project Calendar**: 92 | 93 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 94 | 95 | 96 | 97 | -------------------------------------------------------------------------------- /meetings/2024-01-16.md: -------------------------------------------------------------------------------- 1 | # Node.js Web Server Frameworks Team Meeting 2024-01-16 2 | 3 | ## Links 4 | 5 | * **Recording**: https://www.youtube.com/watch?v=eLSt_Sggnjs 6 | * **GitHub Issue**: 7 | 8 | ## Present 9 | 10 | * Jean Burellier @sheplu 11 | * Rafael Gonzaga @RafaelGSS 12 | * Paolo Insogna @ShogunPanda 13 | * Marco Ippolito @marco-ippolito 14 | 15 | ## Agenda 16 | 17 | ## Announcements 18 | 19 | * Extracted from **web-server-frameworks-agenda** labeled issues and pull requests from the **nodejs org** prior to the meeting. 20 | 21 | ### nodejs/web-server-frameworks 22 | Last meeting https://github.com/nodejs/web-server-frameworks/pull/94/files 23 | 24 | * What is the scope of the WG -> discussion in an issue Jean Burellier 25 | * Paolo: One of the topics last time was to provide a universal layer for HTTP (including HTTP 1/2/3…) 26 | * Paolo: Is the group only around HTTP for Web or do we also want to include other part of the “web” (smtp? What should we support or not) 27 | * Marco: we should stay open and broad. Some technologies like cookies are not specific to HTTP. Scope should be between networking to web frameworks 28 | * Jean: Maybe we have some hierarchy about the part we want to focus on, from webstreams or http as they would influence all of them 29 | * Paolo: Standard request / response 30 | * Marco: Web URL parsing to become standard (Paolo: maybe ping yagiz) 31 | * All: we need to find a good name that would show and be easy to understand what the group is doing (Client / Server Group) 32 | * Marco: delay discussion on an issue - not just low level network but not framework focussed 33 | * Do we want to include specific part of the projects (internal or external but close) like: 34 | * lmhttp 35 | * Jean: do we want to include in the group some core / mandatory part of the project to help with the support ? 36 | * Cluster 37 | * Compression 38 | * brotli or other tools 39 | * net module 40 | * Close should stay “contained” for the start of the team, and what would be our core objectives and what people want to work on -> Open an issue 41 | 42 | * Splitting work between low level and high level 43 | * Low level: 44 | * High level: 45 | * But first start by researching specific part of the project to create the definition and see what would be the matter / how do we want to operate 46 | 47 | * Standardization 48 | * Work with WinterCG and other standardization groups 49 | * improve developer experience between the full ecosystem 50 | * provide some module not part / included by node but maintained by this group 51 | * collaboration with other runtimes 52 | 53 | * Cookies 54 | - ​​https://github.com/whatwg/html/issues/9935 55 | 56 | ## Q&A, Other 57 | 58 | ## Upcoming Meetings 59 | 60 | * **Node.js Project Calendar**: 61 | 62 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 63 | -------------------------------------------------------------------------------- /meetings/2024-03-26.md: -------------------------------------------------------------------------------- 1 | # Node.js Web Server Frameworks Meeting 2024-03-26 2 | 3 | ## Links 4 | 5 | * **Recording**: 6 | * **GitHub Issue**: $GITHUB_ISSUE$ 7 | 8 | ## Present 9 | 10 | * Web Server Frameworks team: @nodejs/web-server-frameworks 11 | * Marco Ippolito: @marco-ippolito 12 | * Paolo Insogna: @ShogunPanda 13 | * Wes Todd (@wesleytodd) 14 | 15 | ## Agenda 16 | 17 | ## Announcements 18 | 19 | * Extracted from **web-server-frameworks-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. 20 | 21 | ### nodejs/web-server-frameworks 22 | 23 | * Review and update documented http strategy [#102](https://github.com/nodejs/web-server-frameworks/issues/102) 24 | Will be discussed at the next collaborator summit 25 | * URL's on incoming requests [#71](https://github.com/nodejs/web-server-frameworks/issues/71) 26 | Consensus is that it’s probably not worth implementing `req.url` due to insecurity and possible vulnerabilities, we should document how to do it manually, and possibly implement it in the next http stack. 27 | * Future of HTTP High Level API Design [#60](https://github.com/nodejs/web-server-frameworks/issues/60) 28 | Marco is working on the next http stack, created his own repo and will link it to the next-http one. 29 | 30 | ## Q&A, Other 31 | 32 | ## Upcoming Meetings 33 | 34 | * **Node.js Project Calendar**: 35 | 36 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 37 | -------------------------------------------------------------------------------- /meetings/2024-05-07.md: -------------------------------------------------------------------------------- 1 | # Node.js Web Server Frameworks Meeting 2024-05-07 2 | 3 | ## Links 4 | 5 | * **Recording**: 6 | * **GitHub Issue**: $GITHUB_ISSUE$ 7 | 8 | ## Present 9 | 10 | * Web Server Frameworks team: @nodejs/web-server-frameworks 11 | * Stephen Belanger: @qard 12 | * Frederic Charette @fed135 13 | * Marco Ippolito: @marco-ippolito 14 | 15 | ## Agenda 16 | 17 | ## Announcements 18 | 19 | * Extracted from **web-server-frameworks-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. 20 | 21 | ### nodejs/web-server-frameworks 22 | 23 | * Future of HTTP High Level API Design [#60](https://github.com/nodejs/web-server-frameworks/issues/60) 24 | * Discussion going forward 25 | * Frederic talked about how the problem of supporting multiple http versions at the same time 26 | * Team agreed that as a initial implementation we should only support one at the time without the possibility to upgrade, but still leaving it as a future goal 27 | 28 | ## Q&A, Other 29 | 30 | ## Upcoming Meetings 31 | 32 | * **Node.js Project Calendar**: 33 | 34 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 35 | --------------------------------------------------------------------------------