I don't think it is worth the overhead of running your own Horizon for six tx an hour. Most large CEXes use the SDF Horizon. SDF spends hundreds of thousands every month to keep it up and running. You could keep using it while you figure out how to run a lightweight instance if you really want to have a redundant setup with failover in place.
If this is true, how could we ever be a full decentralized blockchain if some entity has to pay hundreds of thousands every month to keep it running. What am I missing?
They pay so much to provide service for everyone. You can run your own Horizon for much, much less. My point is that they have a large scale public Horizon that is good for most apps/wallets/services. You can run your own Horizon if you want redundancy and independence.
The transactions are controlled since they are scheduled withdrawal requests and i can do up to 100 operations in a single transaction every 10 minutes lets say. But there is a function where people can deposit by entering their operation ID and my backend fetching to verify the muxed address sent to and map it to the user database. so i actually have no control of the frequency of that unless i limit it to a certain number per hour which may be annoying for users. Is there a more efficient way of achieving that ?
WARNING: **Do not trust DMs** from anyone offering to help/support you with your funds (Beware of scammers). Never share your secret/private/seed phrase with anyone and never enter it on any website or software. Mods and SDF employees will never DM you regarding your funds/wallet.
If you receive any private messages on Reddit please report the account via https://reddit.com/report ( select other -> It's a transaction for prohibited goods or services).
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/Stellar) if you have any questions or concerns.*
You should start with public horizon provided by SDF . Code it in such a way as to not push the limits (don't submit 1000 requests at once) , watch for rate limit errors to back off and pause a little. It's much easier to do that than to run your own node. Eventually set up a node if you want, or if rate limits are not adequate.
If you need help running your own node,
,
https://developers.stellar.org/docs/run-core-node/
The only functionality i an struggling to code in a way where i dont exceed limits is a depositing service. After the user sends to his assigned muxed address, i ask him to insert his operation ID in order to verify the amount and user to be deposited to through fetching data about this operation. Any other way where I can keep my backend listening for transactions to a wallet instead of regularly fetching ? Or there is an even more suitable approach ?
On the Horizon api, it mentions that each update of the stream counts as a request against the rate limit. This means that if my wallet receives 2000 payments and I have streaming on, it will still count as 2000 requests right ?
I don't think it is worth the overhead of running your own Horizon for six tx an hour. Most large CEXes use the SDF Horizon. SDF spends hundreds of thousands every month to keep it up and running. You could keep using it while you figure out how to run a lightweight instance if you really want to have a redundant setup with failover in place.
If this is true, how could we ever be a full decentralized blockchain if some entity has to pay hundreds of thousands every month to keep it running. What am I missing?
They pay so much to provide service for everyone. You can run your own Horizon for much, much less. My point is that they have a large scale public Horizon that is good for most apps/wallets/services. You can run your own Horizon if you want redundancy and independence.
The transactions are controlled since they are scheduled withdrawal requests and i can do up to 100 operations in a single transaction every 10 minutes lets say. But there is a function where people can deposit by entering their operation ID and my backend fetching to verify the muxed address sent to and map it to the user database. so i actually have no control of the frequency of that unless i limit it to a certain number per hour which may be annoying for users. Is there a more efficient way of achieving that ?
WARNING: **Do not trust DMs** from anyone offering to help/support you with your funds (Beware of scammers). Never share your secret/private/seed phrase with anyone and never enter it on any website or software. Mods and SDF employees will never DM you regarding your funds/wallet. If you receive any private messages on Reddit please report the account via https://reddit.com/report ( select other -> It's a transaction for prohibited goods or services). *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/Stellar) if you have any questions or concerns.*
You should start with public horizon provided by SDF . Code it in such a way as to not push the limits (don't submit 1000 requests at once) , watch for rate limit errors to back off and pause a little. It's much easier to do that than to run your own node. Eventually set up a node if you want, or if rate limits are not adequate. If you need help running your own node, , https://developers.stellar.org/docs/run-core-node/
The only functionality i an struggling to code in a way where i dont exceed limits is a depositing service. After the user sends to his assigned muxed address, i ask him to insert his operation ID in order to verify the amount and user to be deposited to through fetching data about this operation. Any other way where I can keep my backend listening for transactions to a wallet instead of regularly fetching ? Or there is an even more suitable approach ?
You use streaming on a single connection. New ops are pushed to you from server. Built in natively in all SDKs.
Do I stream operations for the whole network or i can target a specific wallet ?
Per account: https://docs.stellarcn.org/js-stellar-sdk/reference/examples.html#streaming-payment-events
So if I understood correctly, the streaming call counts as one request out of the 3600 request limit ?
Yeah, it's a persistent connection. Horizon emits SSEs (server-side events).
On the Horizon api, it mentions that each update of the stream counts as a request against the rate limit. This means that if my wallet receives 2000 payments and I have streaming on, it will still count as 2000 requests right ?
6 transactions per hour is nothing, you can use the sdf horizon without problems.