I am currently a student completing an internship, and I have been tasked with updating an existing Spring Boot application. Initially, I understood this to involve a complete rewrite of the system. However, I later learned that the team intends to retain the existing REST API backend.
Given this, I’m unsure why Phoenix was specifically chosen for this project. Has anyone experience with a similar project. also they want to have live view functionality and realtime updates is it even possible. do you guys have any suggesions for me.
Certainly sounds like an odd choice. One of the main benefits of LiveView is that you don’t need a web API just to talk to your own backend. Of course, there could be details you are leaving out in which maybe this could make sense? You can do it, but then you have a websocket connection and constantly firing off other HTTP calls. Also, the realtime stuff all happens on the backend so not sure how they are thinking that will work—you’d basically make an HTTP request which would notify the client which would then make a websocket request which would then notify other clients? I don’t know, I’ve never even considered this before. Makes much more sense to use a client-side framework in this case. But again, if there are more details you can share maybe there is some way this makes sense?
First of all, thank you for your thoughtful response.
I haven’t started my internship yet, so my knowledge is still limited, but I do know that it involves a track-and-trace platform. The company has a primary backend built in Java, along with multiple frontend applications. As I mentioned, they plan to keep the backend while rewriting their main Spring-based frontend using Phoenix.
I agree that using the Phoenix framework for this kind of project is a bit of an unusual choice, but I don’t think I have any say in the decision.
The main reason I’m looking for other projects is that I’m particularly interested in the real-time update functionality. I’m wondering how others have approached this—would I need to rely on polling, which feels unnecessary when the goal is to use WebSockets for the frontend? If you know of any examples or best practices for integrating Phoenix LiveView with a separate backend API, I’d love to hear about them.
I’ll be starting next week, so I hope to gather more details and share a follow-up post then.
I don’t see why not. I don’t think the approach is bad for migrating technologies but I’d look for what are the constraints…
You should use the rest api through the Elixir app or you can connect to the database?
Is the LiveView part just for displaying data or you can modify it through the UI?
What are the risks of duplicating backend logic in both elixir and java app?
How the LiveView app gonna e notified by changes made through the API?
Then just do it. Everything is possible; you have all the pieces in Elixir/Phoenix:
Liveview for real time UI update
Req for a nice HTTP API client
start_async in liveview to decouple the UI update from backend API call
Polling, or SSE, or another websocket from your Phoenix middleware to the backend. Everything you can do with javascript in a browser can be done in Elixir on the server-side, with fewer restrictions.
Ofcourse i will make it work it the end, or atleast i hope so.
I was exited when i heard they planed on using Phoenix. but the way they want to use it seems a bit weird. or i don’t have the full picture yet.
I should have probably mentioned it in the post. but as far as details go i don’t have the full picture yet as i will start next week. but the idea of duplicating the backend logic is an idea i will definitely suggest.
It is an interesting choice, for sure. There’s definitely nothing wrong with Phoenix, but the ecosystem still could use some support in regards to supporting REST APIs. For example, thanks to open_api_spex, you can get an OpenAPI spec generated from your Phoenix REST API, but it’s a very manual process (you have to define everything manually to create your spec).
I feel like the Ash Framework would be a good candidate for this, since it can automatically generate an OpenAPI spec from the code, which would prevent the inherent decoupling of using the manual way. But using the Ash Framework is a commitment unto itself, and IIRC it requires you to use JSON:API as well.
But yeah, there are better choices (from a DX perspective at least) for a REST API at the moment. Even Django DRF or django-ninja can get you automatic coupling between your endpoints and the generated OpenAPI spec (not to mention all the other possible candidates, FastAPI, etc. My experience in other languages is mostly limited to Python.).
