Phoenix LiveView - what if you have a requirement to have a Public API?

I understand the appeal of using LiveView and not having to deal with the JS complexity. But, what if you have a requirement to have a Public API? In this case I tend to believe that it’s better to leave Phoenix as just an API layer and then implement the frontend with JS and the API would be ready for consumption from any app.

What is the canonical way to solve this problem with Phoenix? Or what you guys are doing it?

A Public API many times differ from what you actually need to render your frontend.

If you go the LiveView route, your app is free to evolve independent of the APIs you expose publicly.

They can, of course, share business logic.

4 Likes

Whats consuming the API? Something you own or something clients will use?

I have an app that has LiveView for the web UI and then an API consumed by mobile applications.

It’s easy enough to just throw AI at creating & keeping the API updated (for me anyways).

If you want an API following a convention such as JSON:API, I would recommend to use Ash to define your structs and domains.

You’ll then be able to fully generate a compliant API, without the boilerplate around it, and you’ll even win the SwaggerUI which is a must have for every public API. If using Ash, you’ll also have pagination for your lists with 2 more code lines.

No need to review the AI generated code, as is it logically generated code. That is the decision I took, and it feels right to me now.

Ash is DI: Deterministic Intelligence :grin:

3 Likes