-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
feat(AppFramework): Add Route attribute #42801
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
Conversation
|
No idea why OpenAPI changes (seems to use the old version?), but the openapi-extractor PR needs to be merged first anyway. |
nickvergessen
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We discussed at another point recently that all future API work should be using OCS routes so APIs can also be used by mobile/desktop clients.
Could make this more clear by biasing the constant names.
Other than that, as mentioned I love the idea as it will reduce conflicts, amount of file and bring the 2 things that depend on each other closer together.
|
Since we use the Symfony router under the hood. Would there be an issue extending/using it's attribute as a base? We ship it already: https://github.com/nextcloud/3rdparty/blob/8a78b41c955bb3530a5c25f187e3dc96091dadd7/symfony/routing/Annotation/Route.php Ref https://symfony.com/doc/current/routing.html That could even allow us to remove more routing code in the future? |
I didn't know about this. Removing routing code sounds good, but this attribute also supports a lot of stuff that we don't support in our routing yet (and it has a slightly different signature than our current routing parameters e.g. verb vs methods). I don't think that is a good idea :/ |
|
(I only migrated core and one other app to ensure it works for both since they are handled a bit different in the router) |
|
Blackfire analysis:
Every comparison is primed with a simple curl to warm caches. |
|
@ChristophWurst thanks for the profiling. When I did my testing I found that even with 1k requests I got very different results every time. At 10k it was quite stable. To everyone: Do you think the performance hit is acceptable or not? |
2e69f6e to
45d52cc
Compare
julien-nc
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good and works fine.
The performance hit seems acceptable to me.
|
This branch is currently broken if navigate to the root of the instance. Any other URL will work fine. I'm looking into it already. |
45d52cc to
91bdf72
Compare
|
Hi everyone, so after a debugging session with @julien-nc we found the problem: @ChristophWurst @come-nc @nickvergessen @juliushaertl please review again, this is finally ready. |
63aa6b5 to
57d9218
Compare
|
CI failure is fixed, it was just another case of the casing problem with matching legacy routes. |
julien-nc
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
e3453b6 to
b84c1eb
Compare
Signed-off-by: provokateurin <[email protected]>
…outes Signed-off-by: provokateurin <[email protected]>
Signed-off-by: provokateurin <[email protected]>
Signed-off-by: provokateurin <[email protected]>
Signed-off-by: provokateurin <[email protected]>
b84c1eb to
2c51933
Compare
Summary
Depends on openapi-extractor: nextcloud/openapi-extractor#73
Documentation: nextcloud/documentation#11442
A new routing method that should make it easier for new developers. It avoids having to manually verify the connection between the layers of the routes and the controllers.
The changes to the openapi.json file are annoying but required because the order of the routes changed. You can verify there were no changes using http://play.jd-tool.io (with unordered set option). Since there is no diff we can also be sure I migrated all routes correctly.
I did some benchmarking and would consider the slight drop in performance to be acceptable. It is about 2-5ms which is not noticable and there are many other factors in a remote HTTP connection that cause way more delay (tests were done on localhost). I have some ideas which could be tried to improve the performance a bit (but there is no guarantee that they will).
Only the 99th percentile is really relevant as the longest request can also be a fluke (see in the baseline testing for the capabilities endpoint). All tests were done with 10k requests on the standalone PHP webserver with SQLite and without any caching configured.
The core test is to check for changes in parsing the routes and the test with Talk (which has not been migrated) is to check the impact on apps with many routes. The total number of enabled apps has no performance impact on this new mechanism.
Before:
Now:
Checklist