alaadahmed
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?
Trending in Discussions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming











Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
chrismccord
absolutely yes
BartOtten
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.
stevensonmt
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.
wanton7
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.
derek-zhou
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)
alaadahmed
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#
wanton7
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.
BartOtten
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.
chrismccord
Just like phoenix channels (or genservers) consume only the memory you carry in your state, same story w/ LiveView. Check the docs for
temporary_assignsto only hold onto the LiveView state you want to truly be stateful.wanton7
I haven’t used them but shouldn’t browser Notification API & Push API work for desktop and phone notifications?