Skip to content
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

Book keeping #43

Merged
merged 3 commits into from
May 29, 2020
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
79 changes: 79 additions & 0 deletions meetings/2020-03-19.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,79 @@
# Node.js Foundation Web Server Frameworks Team Meeting 2020-03-19

## Links

* **Recording**:
* **GitHub Issue**: https://github.com/nodejs/web-server-frameworks/issues/36

## Present

* Ethan Arrowood (@Ethan-Arrowood)
* Jean Burellier (@sheplu)
* Gireesh Punathil (@gireeshpunathil)
* Glen R. Goodwin (@arei)
* Michael Dawson (@mhdawson)
* Tomas Della Vedova (@delvedor)
* Wes Todd (@wesleytodd)

## Agenda

* Review Governance [#1](https://github.com/nodejs/web-server-frameworks/issues/1)
* Ethan: are we ready to close. PR opened and landed to adjust. Believe we should
be ready
* Have agreed on 2 different times to make it easier for people from different timezones
to attend.
* Will close issue.

* docs: join instructions in README.md [#4] (https://github.com/nodejs/web-server-frameworks/pull/4)
* a requested change, but should be able to update today
* will accept all open join requests today as well
* Gireesh, + others we should continue to be open about letting people join easily.

* 'stream' vs 'request' API [#19](https://github.com/nodejs/web-server-frameworks/issues/19)
* Tomas added http2 support for Fastify using the compat api - did not use stream
* Wes moved request/response out of the main Express repo to better support HTTP2/3; very
soon wants to start more robust support
* Why aren’t we seeing http2 apps?
* Netflix is using it over GRPC
* Many are terminating at a NGINX layer
* Nginx didn’t support a reverse http2 unless in a paid platform so many devs couldn’t do
application layer things like push thus treating apps like http1
* Great example of GraphQL and HTTP3 would be really beneficial for folks
* What are the real benefits of http2?
* Check out auto-push packages:
https://github.com/google/node-h2-auto-push
https://github.com/google/node-fastify-auto-push
https://medium.com/the-node-js-collection/node-js-can-http-2-push-b491894e1bb1
* Communicate more on ‘how is http2 being used in the wild’
* Is HTTP3 going to have a compat layer? We should ask James
* 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?
* When do we stop supporting compat layers?

* Improved set header and set cookie
experience[#32](https://github.com/nodejs/web-server-frameworks/issues/32)
* One of the things problematic in today’s Express cookie module is if you call setHeader it overrides the previous header value
* Could this live in Node core?
* Rather than be specific on cookies, can we expand the header utilities in node core?
* Some breakaways: appendHeader issue, setCookieHeader discussion, cookie or header parsing
* is it too much to bring all header stuff into core? Is it better to focus on just cookies?
* jshttp has a lot of work on this already
* members apart of this group should start maintaining http in core
* members apart of this group can step up to help squash security issues in http related modules in core too
* We should put the callout that we are looking for contributors in this area
* each of the frameworks should look for volunteers to contribute to node.js security

* Discuss modules in CITGM [#35](https://github.com/nodejs/web-server-frameworks/issues/35)
* Ethan, recently saw on twitter library that would run unit tests for each of your npm
dependencies. Anybody remember the name? This one reads package.json and
clone and runes all of the unit tests.
* Wes, today you can submit PR for modules

## Upcoming Meetings

TBD in mind-late feb

* **Node.js Foundation Calendar**: https://nodejs.org/calendar

Click `+GoogleCalendar` at the bottom right to add to your own Google calendar.


81 changes: 81 additions & 0 deletions meetings/2020-04-30.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,81 @@
# Node.js Foundation Web Server Frameworks Team Meeting 2020-04-30

## Links

* **Recording**: https://youtu.be/6Wxa0Q0bFjU
* **GitHub Issue**: https://github.com/nodejs/web-server-frameworks/issues/40

## Present

* Michael Dawson (@mhdawson)
* Matteo Collina (@mcollina)
* Wes Todd (@wesleytodd)
* Ethan Arrowood (@ethan-arrowood)
* Tomas Della Vedova (@delvedor)
* Robert Nagy (@ronag)
* Chris Russell

## Agenda

* http: response does not emit error on premature close #41
* Change will affect anyone using raw http
* Want to make sure major frameworks are prepared for this change
* if this lands it would be a major change landing in Node 15
* This would make express core v4 not able to run on Node 15, which should be okay since v4 should be EOL by then
* Matteo’s concern: having to set multiple error handlers (one for request, one for response).
* It is an unfortunate coupling of those two.
* It can be left as is, but it can be brittle for generic streams
* @ronag will make a pr for this and we can continue discussion later
* Can we make this feature opt-in?
* Maybe only throw error if user is watching for it so we don’t crash peoples program

* Improved set header and set cookie experience #32
* Previously discussed is
* 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.
* Frameworks were asked to encourage their contributors to look into contributing to Node.js core
* Jshttp library has already done a lot of work on these things
* Breakaways include: appendHeader issue, setCookieHeader discussion, cookie or header parsing
* Original concern: adding multiple cookie headers is not a straight forward process in Node core.
* 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.
* What is the future of header handling in Node core?
* Remove setHeader?
* Can we refactor this issue into discussing better header management rather than just adding more methods to core
* setHeader works well is you are using Node core, but not great for frameworks
* Can we use MDN header api? (it might be slow)
* If we can make this fast but remain in spec that would be great improvement for Node core
* https://github.com/fastify/fastify/pull/813 https://github.com/fastify/fastify/search?q=writeHead&type=Commits
* If we were to deprecate this lots of documentation and tutorials need to be modified as well
* 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.
* Do we need something to replace it if we deprecate setHeader in node core?
* How does this apply to trailers?
* Action item: consider adding MDN Headers api to Node core. The MDN api knows about the Header quirks.
* Discuss modules in CITGM #35
* Previously discussed, nothing worth copying over to here.
* Express dependencies are not in canary so those would need to be added
* Would want to test multiple versions
* 'stream' vs 'request' API #19
* Previously discussed
* Why aren’t we seeing http2 apps?
* Many apps terminate at a NGINX layer due to it not being freely available
* Request for a GraphQL + http3 example
* Request for better documentation on the benefits of http2/3/etc.
* Request for better communication on existing http2 apps
* Is http3 going to have a compat layer? Do we need to help build one? (ask James)
* Public outreach to companies on using
* When do we stop supporting compat layers?
* Matteo has more info on compat layer & stream api.
* Error handling was an issue
* Lots of memory leaks
* Adding the compat layer was what enabled http2 to ship in the first place
* Implementation of http2 for end users is severely lacking thus there is no reason for frameworks to develop stream based http2 support
* Major blocker for http3 is because it requires a patched version of OpenSSL
* Should we put our effort into making compat layers better or making frameworks run on streams? Is either effort worth it right now?
* We should ask “why people aren’t using http2?”
* Broader question: what is the cost of maintaining http2 in Node core?
* https://github.com/nxtedition/node-http2-proxy
* https://github.com/fastify/fastify-http-proxy
* https://www.npmjs.com/package/http2-proxy

* docs: join instructions in README.md #4
* Previously discussed
* Complete open pr and add other users