Feat/use status backend server #21550
Conversation
qfrank
requested review from
ilmotta,
seanstrom,
flexsurfer,
briansztamfater,
smohamedjavid,
siddarthkay,
mohsen-ghafouri and
ulisesmac
Jenkins BuildsClick to see older builds (65)
|
qfrank
force-pushed
the
feat/status_backend_server
branch
4 times, most recently
from
0b2aa2c
to
6ae49a5
Compare
|
@qfrank, this is amazing, thanks a lot! Do you notice any performance difference when using status as a server? |
There was a problem hiding this comment.
@qfrank, I tried the PR, and it seems to work, but because status-go is still compiled for mobile, it's hard for me to tell if everything is working or if something is falling back to the "normal" status-go.
In other words, changes in status-go code still cause a full rebuild even when STATUS_BACKEND_ENABLED is 1 whenever make run-android runs (I simulated this by setting STATUS_GO_SRC_OVERRIDE, but it would be the same if switching branches when the revision in status-go-version.json is different). Are you planning on fixing this in a follow-up PR?
Also, status-backend is running correctly, but I don't see any logs in its STDOUT, only in the make run-android output. Is it because of what you said in the description? Update the Android log store location.
My configuration during runtime seems to be correct and status-backend is running well (root-data seems correct and has all db files, keystore, etc).
{:enabled? true,
:status-go-endpoint "http://127.0.0.1:9050/statusgo/",
:signal-endpoint "ws://127.0.0.1:9050/signals",
:root-data-dir "<path>/status-go/root-data"}As a suggestion, apart from the PR instructions, it would be great to have documentation in the source about how to use the status-backend. Another point worth mentioning in docs is that the developer should make sure the status-backend is checked out to a revision that's at least compatible with the revision in status-mobile/status-go-version.json.
qfrank
force-pushed
the
feat/status_backend_server
branch
from
6ae49a5
to
376a232
Compare
Not quite.
I'm sorry to hear this ... Because the status backend server is not mature enough. We can improve it later in separate PR. If you want see something output from STDOUT, you can change level to
Sounds great, I'll add it later @ilmotta |
not yet, WDYT of this performance regarding invocation log from I think it's okay for most cases. If we have special requirements, maybe we can invoke specific native functions that pretty stable through embed statusgo or try other optimization solution, this is another feature we can do |
qfrank
force-pushed
the
feat/status_backend_server
branch
2 times, most recently
from
f1654d5
to
4caa788
Compare
Thanks @qfrank. No worries, let's leave at that and we can improve in the future. One day we may get there! |
qfrank
force-pushed
the
feat/status_backend_server
branch
from
0b21ea1
to
073385b
Compare
There was a problem hiding this comment.
@qfrank I had the pleasure to review and follow instructions successfully! I could step debug, quickly restart the server, super cool 🌟 Big thanks for writing the documentation.
-
The problem with HTTPS and the image server is no big deal for me personally.
-
It would be nice if we could get logs in the status-backend process output (in this other PR it was working WIP: Status backend intergation #21517), but it's not a PR blocker in any way.
-
As I mentioned in a previous comment, the end goal one day would be to not build status-go as a lib if the flag is enabled
STATUS_BACKEND_SERVER_ENABLEDso that we can run clients 100% decoupled from status-go, but that seems harder and would require messing with the nix layer and some client code. Of course, not a PR blocker.
status-go may start to look more appealing and friendly ;)
Currently, it goes into geth.log as initLogging works. You can use |
qfrank
force-pushed
the
feat/status_backend_server
branch
from
d19fff3
to
4e863f0
Compare
qfrank
force-pushed
the
chore/use_v2_endpoints
branch
from
7e23b16
to
73db641
Compare
qfrank
force-pushed
the
feat/status_backend_server
branch
from
4e863f0
to
1840c42
Compare
status-im/status-go@3951129...399c3d5 * feat: use status backend server * chore: add env variable STATUS_BACKEND_SERVER_IMAGE_SERVER_URI_PREFIX * update doc * fix_: image_server lint issue
| @@ -0,0 +1,53 @@ | |||
| ## Solution to use Status Backend Server | |||
There was a problem hiding this comment.
@qfrank, I'm sorry for such a late after-merge comment. I think this doc would benefit from quick introduction - defining what is Status Backend Server, what purpose it serves and what are usecases for developers.
Finally, we can now use the status backend server in the local development environment with this pull request without having to wait for the painfully long rebuild time! I created this PR to facilitate review. Once it is reviewed, we can merge it and conduct a manual QA on PR 21450.
Pls see the doc for usage.