Page URL
https://docs.near.org/api/rpc/introduction
Feedback Type
General Improvement Suggestion
Current Experience
The RPC endpoints are updated manually
Your Suggestion
Utilize the nearcore attribute macros to generate OpenAPI specifications that auto-generate the UI and interactions.
Using something like https://redocly.com, we can generate request/response types according to the code in nearcore:
^ from https://github.com/fastnear/docs?tab=readme-ov-file#generating-rpc-specs-from-nearcore
For the FastNear docs we're using Docusaurus that feeds parameters into an iframe that loads from an inexpensive Redocly plan. (We could certainly code the contents in the UI ourselves if we wish, too.)
So the process is to take a release of nearcore, point the Redocly-based docs repo toward it, and it'll flesh out the latest types and endpoints. It also gives a "Try It" modal where end users can point and click to try these endpoints, allowing them to stay in the docs if they wish.
Use Case
As a user, I want to be sure that the RPC documentation section is aligned with the latest nearcore release, without the need for manual changes and pull requests. Also the ability to have basic interaction with parameters to try it live.
Impact Level
🟢 Low : Nice to have enhancement
Additional Context
The Redocly repo: https://github.com/fastnear/docs?tab=readme-ov-file#generating-rpc-specs-from-nearcore
The Docusaurus repo: https://github.com/fastnear/builder-docs
Wanting to share because we got it working nicely around NEARCon recently, and want to knowledge share. I see no urgency in having the primary NEAR docs change in this way, but happy to decide if this should be in these docs, help link to our (rather affordable) Redocly paid plan. My goal is not to have several documentation sites, but to flesh out this nearcore » web UI flow.
Maybe for now we can just keep it on the FastNear docs while we consider it, not offended if it's not an idea we want to take on, I know there are a lot of issues to address. Mainly happy it's working, and since NEAR One has these nice schemars macros, it takes no modification of nearcore and only reads it to generate the specs.
Page URL
https://docs.near.org/api/rpc/introduction
Feedback Type
General Improvement Suggestion
Current Experience
The RPC endpoints are updated manually
Your Suggestion
Utilize the
nearcoreattribute macros to generate OpenAPI specifications that auto-generate the UI and interactions.Using something like https://redocly.com, we can generate request/response types according to the code in
nearcore:^ from https://github.com/fastnear/docs?tab=readme-ov-file#generating-rpc-specs-from-nearcore
For the FastNear docs we're using Docusaurus that feeds parameters into an iframe that loads from an inexpensive Redocly plan. (We could certainly code the contents in the UI ourselves if we wish, too.)
So the process is to take a release of
nearcore, point the Redocly-baseddocsrepo toward it, and it'll flesh out the latest types and endpoints. It also gives a "Try It" modal where end users can point and click to try these endpoints, allowing them to stay in the docs if they wish.Use Case
As a user, I want to be sure that the RPC documentation section is aligned with the latest
nearcorerelease, without the need for manual changes and pull requests. Also the ability to have basic interaction with parameters to try it live.Impact Level
🟢 Low : Nice to have enhancement
Additional Context
The Redocly repo: https://github.com/fastnear/docs?tab=readme-ov-file#generating-rpc-specs-from-nearcore
The Docusaurus repo: https://github.com/fastnear/builder-docs
Wanting to share because we got it working nicely around NEARCon recently, and want to knowledge share. I see no urgency in having the primary NEAR docs change in this way, but happy to decide if this should be in these docs, help link to our (rather affordable) Redocly paid plan. My goal is not to have several documentation sites, but to flesh out this
nearcore» web UI flow.Maybe for now we can just keep it on the FastNear docs while we consider it, not offended if it's not an idea we want to take on, I know there are a lot of issues to address. Mainly happy it's working, and since NEAR One has these nice
schemarsmacros, it takes no modification ofnearcoreand only reads it to generate the specs.