-
Notifications
You must be signed in to change notification settings - Fork 71
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
Heimdall-rs integration initial version #63
Comments
I already have a backend ready but it definitely is not an optimized one :D The way you use it is: This is the SimpleStream contract by buildguidl |
Ohhh this is great !! I think then lets get the frontend working with this api endpoint what do you think ? If we hit any limit with fly.dev hosting we can think of some better ways also cc @carletex if has some different idea 🙌 |
Maybe we can use it while we develop, but eventually, I think we should deploy our own BG Heimdall instance |
My current backend is not optimized at all but it works fine for testing purposes. I made gpt write the code for it and it is a huge image right now. |
This is great Port!
Do you mean that the docker image is too big? Maybe we could use alpine instead of ubuntu for a smaller image. In any case, I think it'd be great if we use Regarding UI... I was thinking about something like: 2a. If the contract is verified => just do as usual, going to the contarct page 2b. If the contract is NOT verified => Show an intermediate screen: "The contract 0x65a...5605 is not verified". Two options -> 2. Use heimdall (experimental) => Go to the contract page. What do you all think? |
Yes, the docker image is too big and I am having trouble optimizing it since I don't know how to handle dockerfiles and it currently is deployed to fly.io. Let me try to optimize it one more time, with the best of my knowledge, then since the source is available on gh, we can fork and then deploy as BG. I will let you know when I finish it. Also the UI idea you have is very similar to what I have in mind. So I think it is great. It makes using abi.ninja easy for people who are not web3 native, which is something we are definitely after. |
I have changed the way heimdall backend works, here is the current address: As for the optimizations, since this is literally a whole ubuntu system that calls commands, I failed to optimize it. The img size is 1.95 gb. |
Thanks @portdeveloper ! We can use that URL for testing & building the functionality and then we can decide.
I'm not an expert in Docker, but I know that there are some «slim» images like Alpine or debian:slim. It could be an option if you want to try. But if you don't enjoy doing so, like this is fine :D |
Even with a slim image i can get it down like 100-200 mb, which is not worth it I guess. So until we have problems with this I think we can keep it as a 1.95 GB image lol |
Completed at #71 |
Description :
Since we are done with migration from SE-1 => SE-2, I think we should start thinking about heimdall-rs integration basically to allow people to interact with the abi of unverified address.
Some initial steps on top of my head :
1. We need an heimdall-rs backend1. Maybe we can create a dirheimdall
insidepackages
basically a yarn workspace similar to how we havepackages/nextjs
&packages/hardhat
EDIT: The above does not apply since seems backend needs to in rust
To keep things simple for initial version maybe we can create new tab "Heimdall" on abi.ninja Home page
Figure out deployment of heimdall-rs backend
Lol not completely sure if I am on right track but maybe @portdeveloper has more context on this 🙌
Let's try to keep the initial version minimal and get basic things working we can always iterate nicely once we have a nice basic setup
The text was updated successfully, but these errors were encountered: