Find the best API Endpoint for your EOS DApp
The vital part of any DApp is an interaction with HTTP API endpoint of the EOS node.
So, if you want to develop a DApp built on EOS blockchain and don’t want to run your own node with HTTP API endpoint, because it’s pretty complex task and needs a lot of resources. You can try to use some services like eosinfra or dfuse, that provide you ready to use API, but at some point these services won’t be cheap.
The core of EOS blockchain is Block Producers that you voted for, but they are not the only ones on the network that offers public API endpoints, a lot of others BP Candidates offer them too, so why not use them?
My idea is to gather a list of all BP registered on EOS blockchain and find out all their API endpoints for further testing.
I wrote some script for this task, but i’m not ready to show it (if you’re interested, i’ll clean it and post someday =)), so i’ll just show you the results of gathering:
Now we need to find out endpoints with lowest latency, so we can have better performance (if BP have good node), but pinging hosts isn’t an option, because some endpoints are hiding behind CDN or load balancers.
API is dynamic service and caching it is bad idea, so we need to measure HTTP request-response time to find out closest (in terms of network) hosts.
For this task I will use get-closer (that I’ve written for such tasks).
Logic of the test is pretty simple, just measure HTTP request time and compare it with others.
For HTTP you can just run:
$ get-closer http -f https://gist.githubusercontent.com/akme/89a4e596587cb605b530bd825994a0db/raw/db790fa2ffc1f9aef63a6b4b83b16a6badc71276/eos.http.txtAnd you will get results like this:
For HTTPS:
$ get-closer http --ssl -f https://gist.github.com/akme/fe1e2797aeac06480a1e287445109bc0Results: https://gist.github.com/akme/73c6826436968bb34a6edf2468da7d86
Conclusion
It’s pretty raw idea, but I’m interested in your feedback. What do you think about choosing endpoint based on measurements like this?
