Hello everybody,
I will start to work on a relatively big project “E-learning platform”, it is some kind of school that provide online school service. The platform consists of many users (Student, Teacher, Visor, Supervisor, Admin, Manager) and many other services included like (Reports, Messages between different users, Complains in the form of tickets to support, staff directory, notifications, notes board and many more). As I said it is big project, I used Phoenix LiveView and I am comfortable using it but I am not sure if it will fit here as I can’t imagine such such work only on websockets between all of these different users and server. Each user has his/her own portal of the dashboard. Is it feasible to use LiveView for such project, or better to use separate frontend (react, nextjs) and link it to phoenix api with graphql? what about Surface?
Define: many
Without knowing all the requirements it should be hard for anyone here to know if it is suitable. The amount of users is only a fraction of the requirements.
I think for this project LiveView might not be suitable. I can imagine the customer will request an app for the students so they can receive notifications. When you go the Graphql/API way that won’t be much extra work; when you only have unstructured output you probably have to add the API besides the LiveView.
My comment is mostly to sell clarification for myself as I’m certainly not experienced enough with liveview to be offering advice. From the requirements you laid out it seems liveview would work fine. My understanding is that rapid UI updates or latency sensitive interactions are really the things liveview would struggle with.
Surface uses LiveView and it’s a component based library build top of LiveView.
If app only needs to run in browser and you don’t need offline support it should work fine. My experience with LiveView in a personal project is that LiveView saved me huge amount of development time because I didn’t need to create an API that I needed to secure. Also syncing things between different users views was lot easier with LiveView.
I cringe every time when a user requests a mobile app. For the 99% of all cases, users don’t really want mobile apps, a web app is good enough. It is the platforms that want the users to use mobile apps, to keep them hooked, or worse, to steal their privacy.
Notifications can be done with plain old emails, or slack/discord webhooks if you really need the realtime delivery (most people don’t)
I meant by many users (roles) and concurrent connections that could reach to few thousands in few months after deployment. I know LiveView and Phoenix in general has no problem in handling such amount of connections, but I speak about feasibility if this is the right way to build such platform. I like so much LiveView but the way it works (socket assigns → big assigns can lead to connection problems, websocket) make me think about performance when few thousands users (students, teachers, visors) connected to the platform each one do his/her own work on it. Such project I must know ahead of time what technology to choose because it is very difficult to go back in the mid road.
I used phoenix liveview in this project (side project) and it was very very good really and the realtime feature is a killing feature for the platform I am about to work on
www.devincave.com/admin for anyone want to have a look can use email: alaadahmed@gmail.com and password: Linuxawy83#
My understanding is way how LiveView has been created it should be horizontally scalable. What I mean is that reconnects can go to different server instance and everything should just work. About those big assigns, would data that you need send to browser be any smaller without LiveView? You could also use debouncing for some view so you don’t update them too frequently. You could also make data smaller in different means, example I don’t personally like real-time updates that causes layout changes like moving a button into different place when some view is updated. Instead I would like to see there are updates and then I would click to update the view.
As long as you pay yourself, that is not an issue. However, most developers are being paid by their customers 
Using email for notifications clutters mailboxes. It is abusing the medium. Granted, if it’s one notification every week it’s no big deal but schools tend to be busy workplaces. Using Slack or Discord is for other reasons not feasible for many schools / universities.
Just like phoenix channels (or genservers) consume only the memory you carry in your state, same story w/ LiveView. Check the docs for temporary_assigns to only hold onto the LiveView state you want to truly be stateful.
I haven’t used them but shouldn’t browser Notification API & Push API work for desktop and phone notifications?
The nice thing about using LiveView (thanks to Elixir/Erlang underneath) is that it can scale very easily on a single machine. And it’s definitely possible to have several thousand concurrent connections on one machine with LiveView. So there might be no need to scale horizontally and increase complexity like that 
I would however recommend you do some actual load testing before deploying at scale
I think a PWA can do push notifications
Or you can use a push notification platform that brings its own generic app.
Still, there are reasons for the customer that makes an App mandatory. This seems to be the only reason for me not to go with LV. I don’t see why it should be a problem to have different roles of users. If anything LV is at the advantage here, the more complex the frontend is: the better not to write it in JS.
Obviously, if you have many concurrent users, the server has to keep up, but that is (relatively) easy with LV (and the tech behind it).
yes, good related reading for the topic. Phoenix Blog Post: Failing Big with Elixir and LiveView - A Post-Mortem 
I’m quite sure some companies have made hybrid mobile apps by using web view and just showing normal web site inside that app. Web site then communicates with the app to send notifications etc. Experience might not be as fluid as native app but I think it’s something to consider as well.
It mostly depend on what HW you will use for production. We have project which run on single paid Web Dyno. We even didn’t notice that we had huge peak of users. It was like 600 000 per day and regular traffic was at that time less than 100. There are multiple LV collaboration forms and dashboards.
Yes, but it depends what you show on dashboard. What dashboard do? Just show information and it’s still same dashboard even when you have 10 000 connected users. Sorry, not when you show their names who is online on that dashboard ;). Let’s try think about regular flow. User open url → full page html is generated with a lot dashboard data → user see dashboard → user click on filters or next page in table → full page html is generated wit a lot of dashboard data
LV flow: User open url → full page html is generated with LV connection → LV send dashboard data → user click to filter → LV send only changed data in some table/whatever.
So from this point of view LV is even cheaper for traffic. If you have static dashboard without realtime data you don’t need LV for static page.
Ok, so you have LV with dashboard, state contain user struct, all entries, etc… everything works good. But 10 000 users are online. So 10 000x LV state. Yes, that can be issue, it can consume memory. So if you have machine with 8 GB memory I think you don’t have to care. If you have 512 MB Web server, that can be problem. It can be fixed with small refactoring and what Chris wrote temporary_assigns.
So I think we have to know more about what content you will show and store in state if you want to have proper answer for it.
I wrote article this topic last week. There is small discussion which can give you ideas which problem you can have in future with a lot of data https://quatermain32.medium.com/where-to-not-use-phoenix-liveview-7fb5ffb8318b
You know that I wrote this topic here after I read your article!!
It is Linode Server (4GB Ram, 2 Dedicated CPUs, 80GB SSD)
Actually I use always temporary_assigns but sometimes it make unexpected behavior when I use it for listing with pagination
In brief: It is platform that will integrate zoom for live courses, google form form quiz and full calendar for student schedules. Also will use neo4j as database. Students will have their portal to manage their courses or subjects that they bought, check for incoming messages from their teacher or visors, send messages, check their notes board in case of any notes posted by teacher, download materials for their subject, check if there is assign homework for them, upload it, solve exams or quiz that assigned for them, make review about teacher, submit ticket for any complain or issues. This only Student portal, you can imagine also Teacher portal, Visor and Supervisor, Manager/Admin. There is a report mechanism or module that can be used by Supervisors or Manager to collect information about any Teacher / Student, there is evaluation for students and teacher. This is too much to write here but I think you get the idea
oh, so maybe I was the evil on your shoulder, sorry 
So there are a lot of questions which have to be answered, for example:
- what content will you show?
- do you need api for mobile app?
- do you have budget(time,money,…) for custom FrontEnd work?
From my point of view if
- regular data about user, not dashboard with 1000 data set per user per dashboard
- no, maybe in far future
- no, no time, no budget
Go for LV
4 GB memory and 2 CPUs will be for app or for DB and web server too? It’s not enough for all of it even when you will use graphql and FE JS Framework when you will have 10 000 users.
It is not for development, but deployment sure we can bump up the specs to as much as we need to
I think you mean production. Ok so I think HW performance doesn’t have to be issue. You won’t be able to make messy code of course. Like load all entries, users, data, whole DB into LV state
