-
Notifications
You must be signed in to change notification settings - Fork 10
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
Standardize on Web APIs (Request
/ Response
/ URL
/ etc)
#948
Closed
3 tasks
Tracked by
#1034
thescientist13 opened this issue
Jun 29, 2022
Discussed in
#867
· 0 comments
· Fixed by #1045, #1047 or #1034
Closed
3 tasks
Tracked by
#1034
Standardize on Web APIs (Request
/ Response
/ URL
/ etc)
#948
thescientist13 opened this issue
Jun 29, 2022
Discussed in
#867
· 0 comments
· Fixed by #1045, #1047 or #1034
Labels
alpha.1
discussion
tied to an ongoing discussion or meeting notes
Plugins
Greenwood Plugins
RFC
Proposal and changes to workflows, architecture, APIs, etc
v0.28.0
Milestone
Comments
thescientist13
added
v1.0.0
RFC
Proposal and changes to workflows, architecture, APIs, etc
and removed
v1.0.0
labels
Jun 29, 2022
thescientist13
added
the
discussion
tied to an ongoing discussion or meeting notes
label
Jun 29, 2022
This was referenced Aug 28, 2022
thescientist13
changed the title
Standard Request / Response / Server
Standard Request / Response signatures for Resource Plugin lifecycles
Sep 8, 2022
thescientist13
changed the title
Standard Request / Response signatures for Resource Plugin lifecycles
Standardize on Sep 8, 2022
Request
/ Response
APIs (Resource Plugin lifecycles)
thescientist13
changed the title
Standardize on
Standardize on Sep 8, 2022
Request
/ Response
APIs (Resource Plugin lifecycles)Request
/ Response
API (Resource Plugin lifecycles)
thescientist13
moved this to 🔖 Ready
in [Greenwood] Phase 9 - Standards and Conventions
Oct 29, 2022
thescientist13
moved this to 🔖 Ready
in [Greenwood] Phase 9 - Standards and Conventions
Oct 29, 2022
This was referenced Dec 3, 2022
thescientist13
moved this from 🔖 Ready
to 🏗 In progress
in [Greenwood] Phase 9 - Standards and Conventions
Dec 16, 2022
thescientist13
changed the title
Standardize on
Standardize on Web APIs (Dec 24, 2022
Request
/ Response
API (Resource Plugin lifecycles)Request
/ Response
/ URL
)
thescientist13
changed the title
Standardize on Web APIs (
Standardize on Web APIs (Dec 24, 2022
Request
/ Response
/ URL
)Request
/ Response
/ URL
/ etc)
This was referenced Jan 2, 2023
This was referenced Jan 15, 2023
thescientist13
moved this from 🏗 In progress
to 👀 In review
in [Greenwood] Phase 9 - Standards and Conventions
Jan 27, 2023
3 tasks
This was
linked to
pull requests
Feb 4, 2023
This was referenced Feb 4, 2023
Merged
22 tasks
github-project-automation
bot
moved this from 👀 In review
to ✅ Done
in [Greenwood] Phase 9 - Standards and Conventions
Feb 8, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
alpha.1
discussion
tied to an ongoing discussion or meeting notes
Plugins
Greenwood Plugins
RFC
Proposal and changes to workflows, architecture, APIs, etc
v0.28.0
Discussed in #867
Originally posted by thescientist13 January 13, 2022
I would have to do a little more research into Koa, but the Fastify project is looking super interesting and is actively lead / maintained by one the TSC members of NodeJS. As Greenwood moves towards #708 / #576 , it would be good to evaluate the server solution we are using, as it was originally only considered under the basis of being a dev server, is now going to be put into production situations, and so performance and speed will play a more important role in user experience.
In addition, we should really standardize our
Request
/Response
objects.Should also evaluate native
fetch
from Node and also keep an eye on WINTER CG.So this change would definitely impact plugin resources the most (not necessarily in a bad way) and coming out of #974 , it became clear that
ResourceInterface
may need to be deprecated:ResourceInterface
likeshouldResolve
while convenient, has cause hard to trace issues where plugins were running in lifecycles automatically and thus manipulating the req / res unknowingly. You can see in this PR where i had to explicitly opt-out. In actuality, it was more of an Abstract Class rather than an interface, so it was even badly named. I think I would prefer to just get rid of it, but I thinkcontentType
andextension
could still be useful maybe?Request
vs theResponse
and what the order of operations are done by Greenwood when taking the response from resource plugin and setting up the next resource plugin so it can operate on it. Should it be assumed thatRequest
params are immutable, andResponse
objects are mutable?Basically, we should be doing more of:
URL
top to bottom internally (instead ofpath
)Request
/Response
everywhere, at very minimum for plugins / resourcesShould also hopefully address #949
The text was updated successfully, but these errors were encountered: