Questions about Direct Access Feature

[dplewis]

Enables direct access to parse-server, when using the JS SDK from the current node runtime.

All API calls from the JS-SDK are router through route matching (but /functions/:functionName)

Enable that feature by setting PARSE_SERVER_ENABLE_EXPERIMENTAL_DIRECT_ACCESS=1

So if I understand this correctly:

client -> request to Cloud Code Function (Server) -> calling object.save() in Cloud Code -> send http request to Server.

Enabling this feature

client -> request to Cloud Code Function (Server) -> calling object.save() in Cloud Code -> no additional request sent because both JS SDK and Server are on the same node runtime

Enabling this feature would make requests faster since there is one less request, should this be mainstreamed?

Should there be tests run against this?

Add to parse-server config definitions?

We should add documentation to make more users aware of this feature

[acinader]

or we should just turn it on?

I've never tested it which i'll try and do real soon now....

I don't know what potential issue if any it may cause. if there's not breaking change to it, then we should just turn it on. I think that @flovilmart wanted it out there to figure out if there was a breakage issue iircc ...

BUT, adding it to the definitions and testing would be good either way.

[flovilmart]

Most of the Test break with this feature on. There can be bad side effects due to the statefulness of the JS SDK.

[acinader]

In which case, @dplewis your initial suggestion is spot on.

[flovilmart]

I mean the whole test suite is broken when using this feature

_{Sent with GitHawk}

[dplewis]

I haven’t used it yet and don’t know the limitations but would love too. At least start testing against different routing matches and see how responses are handled

[flovilmart]

Simple thing is to turn it on for the test suite, and see what breaks. In an ideal world, all tests should pass as it warrants all cloud code / integration tests are OK.

_{Sent with GitHawk}

[dplewis]

It’s a great feature that is known by few. Definitely could use feedback. I’ll test it out shortly.

[mtrezza]

@dplewis or @davimacedo do you know what the state of this feature is?

It's feature flagged, merged into master but a lot of test cases still fail, so not safe for production, is that correct?

[mman]

@mtrezza i have it in production for more than a year, since 2.8 IIRC, if I understand it correctly requests from cloud code go directly to the instance handling the original request as opposed going outside to the load balancer doing TLS and back inside again. Not checked the failing tests though...

[mtrezza]

@mman Thanks. Do you recall the reason why you took it into production? Did you do a performance comparison?

_{Sent with GitHawk}

[mman]

@mtrezza I think it was because I had a lot of performance and memory problems with the 2.x series, I do not remember exactly nowadays, I did not know much about the code then (not that it has change too much :))), but one of them was single schema cache, parse server would leak memory without it, and push notifications were slow so I opted in for direct access. I also used experimental feature to delete invalid tokens, but that one was removing for me valid tokens at times, but single schema cache and direct access remained in my deployment and everything seems working fine. Also, since upgrading to 4.x memory consumption and performance characteristics changed drastically, 4.x is much faster in serving requests (Note: I have skipped 3.x entirely as I needed to rewrite a lot of cloud code and it took me too much time).

[mtrezza]

@mman Thanks for the details.

Regarding the invalid push token cleanup, I saw a significant resource improvement after activating it, especially DB side, because each push would increase the installation push notifications count, which was unnecessary for invalid tokens, causing DB writes. You may want to read my analysis in #6052 and decide whether it is production ready in your setting. I should do a PR for it soon so we can remove the experimental flag.

_{Sent with GitHawk}

[davimacedo]

@mtrezza I have this feature activated for some of my apps with huge performance improvement in terms of memory and latency. I believed we should switch this option to be activated by default but you've just raised that some test cases are failing. Where did you see they failing? Would you mind to open a PR with this option set true by default so we can see them failing and work together to fix it?

[mtrezza]

@davimacedo I only inferred failing test cases from the conversion in #5550. It looks as if the experimental feature was merged despite failing cases to make it available and get more insight. Maybe @dplewis can clarify this.

Yes, let's team up and make this enabled by default, will open a PR and see if there are any failing test cases.

[mtrezza]

@davimacedo Can you please reopen this issue? I will start a new issue, as this issue was apparently about adding and documenting the feature flag.

[davimacedo]

Sure thing.

[davimacedo]

Ok. Closing again :)

[mtrezza]

@davimacedo Thanks. My apologies :)

[mman]

@mtrezza I'm following #6052 closely and am ready to give it another try :)