my future app: A Interactive Quiz
now I won’t quote anything related to technology or programming language in my speech.
I’ll just explain important aspects about what I want in my future app.
at least once a week i will launch just a question (only one question) in mobile smartphone of my clients. the same question will be sent to everyone. the right answer will be in one or two words. When I post the question, my server has to be ready to handle a very large amount of responses based on the question. (initially on my server I would like to serve no more than 5,000 clients trying to answer the question). I am a single java programmer. I don’t know anything about Erlang or Elixir. what should i learn to develop this mobile app ? Sorry about my english language knowledge (it’s basic).
my future app: A Interactive Quiz
Well, to develop the mobile app you should learn mobile technologies like React Native, Flutter, Swift, Kotlin, etc.
But what you’re looking for is the server part I assume. Learn Elixir and OTP concepts. Maybe you don’t need Phoenix framework for this, or maybe you do. But it depends on your case. Start somewhere. Start by learning the language, get the basis. All the concepts are pretty related . I cannot tell you to study something and other things not. You’re gonna like it, that’s all I can say
I needed this approach ?
Load balancing refers to efficiently distributing incoming network traffic across a group of backend servers, also known as a server farm or server pool .
i need to know what techniques i will use to handle concurrent incoming traffic. I will give a gift to those who responded faster in my app (the correct answer).
Load balancing is, for now, an advanced topic. Leave it be, you have other things to cover first.
Concurrent / parallel incoming traffic is already solved for you if you use naked Plug or full-blown Phoenix. What’s your question there exactly? As much as your hosting allows, all incoming connections are concurrent, they are not served one by one serially.
@dimitarvp my big question is a hypothetical case:
5k clients answer in the same time, and server do not crash. As only answered more quickly and correctly interests me, there is a way from the server ignore the other answers without needing handle it ?? it would be a transparent process for the client. so I think the incoming balance would be smaller and more easily handled by the server
One thing I would recommend is: Start simple, then grow.
It sounds like you have a good vision of where you want to end up at. But that’s a huge step and only few can just go from 0 to 100 in one go.
Instead, I think, you should start with baby steps and take one goal at a time. That makes you feel and see progress and keeps the stuff you have to learn as small as possible.
In your situation: Maybe don’t worry about the concurrent client updates at the start? Build a simple server that has an API to “send in a quiz answer”? Then go and build a client for this simple API (a website, a bash script, a CLI, whatever you feel like) and make them work together?
Then proceed to add all the features you envision to have: Notify your client of a new quiz. Notify the winner. Handle lots of clients (if you even need special handling for that), etc. …
Elixir makes it easy to get started and it will definitely allow you to grow your system to LOTS of requests. Just get started with simple tasks and see how easily Elixir takes you through the whole thing = ) The things you should learn for that are the “standard Elixir things”. There is a great guide to get started on the official website: Introduction - The Elixir programming language - especially the second part about OTP should be really important for you.
The theory here in the BEAM VM land is that you don’t need anything special for that. The BEAM VM (Erlang, Elixir) remain responsive under load.
Are you acquainted with various load-testing tools like
siege? You can create a simple API project and try and hammer it hard with them and see the statistics they’ll give you (average time per request, worst request etc.)