Hello people
I built an overlay application with the following technologies:
NodeJS (backend), mongoDB, with Docker, my frontend I used the javascript vanilla (manipulating the DOM), html and css, I have doubts in the process of releasing versions and other things.
-
[FrontEnd] My overlay application is a real-time feedback system with an interactive map (map is similar to google map, with marke, 7 zoom levels and feedback panels).
-
[FrontEnd] Requests Ajax to post voting, get all votes and receive new votes through socket.io.
-
[BackEnd] business logic, authentication, conversion of data to the database and other things.
Now my doubt:
I do not know how to let the cost of my application be self-sustaining, my idea and get a server in heroku, my application does not have as a monetization to pay at least the cost of the server, do you have any idea for this?
Sorry for my translator in English, I’m waiting for some help, I’m always here and in github, thanks for the help 
This is a difficult question to answer with any precision without having all of the context. My answer will hence be somewhat generic.
First off, I am assuming you are referring to operational expenditure (opex) and not capital expenditure (capex); that is, the cost of operating a backend. If this assumption is not valid, the rest of this post will likely not be relevant.
Adoption and architecture are the two primary contributors to operational costs for an Extension. A developer clearly has control over architecture, but has limited control over adoption. I say limited here, as there are things that influence this that are directly in a developer’s control, whilst there are quite a few things that they cannot control. Implementing a non-scaling architecture can cause operational costs to inflate. In general, be very mindful of data flows between frontends and your backend. For example, if your Extension frontend heartbeats a backend, think of the consequences of several large channels going live with your Extension. Immediately hundreds of thousands, or millions of viewers, and hence connections…
To simplify things, we are taking a multi-pronged approach:
- Providing different paths for monetising Extensions; and
- Providing building blocks that abstract the need to implement as much scaling logic
Personally, I would love to get to a place where developers are able to make a living creating Extensions, and for a decent number of use cases, allow Extensions to be created that do not require a developer hosted backend.
1 Like
Well there’s your “problem” you are using something that will “cost” you money. And heroku itself is probably expensive for this use case.
I run an extension with no monetisation routes, nor do I ask it’s users to cover my running costs, it runs on my personal server spare capacity 
I have spare server space on my personal webserver so I use that to run that particular extension. I never expect to make anything on that extension.
1 Like
I ran into the same issue…
My very little hobby extension “Top Clip” reached such an incredible high (and totally unforeseen) adoption rate, that my light REST API (3 endpoints) is actually called ~500k times a day…
My suggestion: Go with free credit from a cloud provider. During the free credit duration, build your monetized extension (the more value it offers to streamers & viewers, the more revenue it will create!). Release the extension. In a perfect world you’d still run on the cloud provider’s free credit while the first revenue of your monetized extension arrives 
1 Like
Hello everyone,(BarryCarlyon, rbartlet, mBeierl) thanks for the answers, I thought about some possibilities, maybe reduce some features or limit the interaction in some way to a group of users (subscribers).
part of the application flow is following in some images, with description
1°: 1st: the first load appears only the button with the red tag with the polls closed, the toastr alert some after 5 seconds
2nd: the second load appears only the button with the green tag with the polls open, the alert toastr disappears after 7 seconds, it only opens the poll if the streamer sends a warning on the socket io
3 ° Once the polls have been opened, simply click on the button to show the map and all votes already counted
4 ° There is a socket listening to each new vote well succeeded to update the votes
Do you all think that this flow is heavy for a twtich application?
One point we all agree on is to use a free cloud service for testing at first, thanks for the help
Are you using Twitch pubsub to deliver data from your backend to your frontend? If not, you should consider doing so.
Depending on how many messages you expect your frontend to send to your backend, I am not convinced that websockets are the correct technology. If you expect to have your frontend send multiple messages without requiring setup/teardown of the socket, this could be worthwhile.
Be careful of scaling a node backend. Ensure that your requests are just persisting data, and returning, with another consumer handling aggregation.
Ask yourself questions like: will my backend support 500k viewers voting at once? How about 1million?
1 Like
I read about pubsub, can you use your resources like this ?:
- a private messaging channel where I receive the voting data.
- at the end of the vote I do only one post pro backend to the main account
- retrieve data in the chat channel to refresh the map
Does this concept work or was it done for another purpose?
Thanks again for the help.
Pubsub is a fan-out messaging solution. Using it, you can send a single message from your backend to all connected frontends.
You could use pubsub to deliver results at the end of a vote.
1 Like
Solved, the best way to get your application at a low cost is to creatively use the features that twitch makes available to developers, thanks to everyone who helped me.
