idea: HDP cli as server optional

[rkdud007]

Context

As for right now, as thread stop with one request call to cli, InMemoryProvider is useless. There is not much of possibility for provide proof in memory that requested in this short amont of seconds and get reset.

Idea

What if make cli optionally able to spawn dedicated server in localhost and get requests with same thread — that way could leverage caching & or later persistent db and it fetching speed would be hugely faster

Ideally we could have a command to run server

hdp run-server 

and it start in localhost::8080 for dedicated server.

And for use run command that we originally have, it would be calling api in this case

Consideration

We have HDP-Server which export api interface. This might make conflict on responsibility.
-> another thought on this is, we could split HDP-Server for business purpose / and server on top of HDP cli for open-source purpose, as everyone could run and spawn HDP full logic on local

But If want to delicate this Caching logic to Server, we should implement logic around HDP Runner. Which also mean need to save result of proof to DB or Inmemory.
I believe work load around implement this in either HDP cli and HDP-Server would be not much difference, but As HDP cli takes on fetching proof, would like approach of make Provider support Fetching and also Caching so that it can deliver robust speed

Conclusion

Adding server on top of HDP cli doesn't mean just adding interface. I belive it could make sense to have this as HDP Core that support 1) cli for dev purpose 2) server for run the HDP flow 3) Have dedicated DB and Providers to optimize fetching 4) Connected to many backend as options for zkVMs

[marcellobardus]

How about going for smth simpler like a file cache.json?

[marcellobardus]

Maybe before going for caching i would check how fast we can get by having a locally synced node.
So we do not have to call infura/alchemy.

[rkdud007]

https://users.rust-lang.org/t/crates-to-use-for-worker-processes/61074/2