GraphQL vs REST for Elixir Devs
HTML-код
- Опубликовано: 12 июн 2024
- In this episode of Software Sophistication:
- Is LiveView a stable ecosystem?
- What is the best approach for GraphQL vs other APIs, like REST, when you have LiveView code?
- What’s the best way to integrate the Ash Framework with Phoenix?
- Is there a way to implement dynamic events with no JS in LiveView?
🔥 I’ve built an expert team at Or Equals that will revitalize your codebase. Use our experience in Elixir and Phoenix LiveView consulting so you can get back to focusing on the business. Schedule a meeting with me, and let’s chat 👉 orequals.com
💻 Pragmatic Studio’s course is the most efficient way to learn Elixir/Phoenix LiveView. Use the course that I use to teach all my apprentices:
➤ Phoenix Liveview Course: pragmaticstudio.com/courses/p...
➤ Elixir Course: pragmaticstudio.com/courses/e...
00:00 Preview
00:14 Intro
00:41 Our Guest: Micah Woods
02:54 What has kept Micah interested in Elixir
07:35 Is there a way to implement dynamic events with no JS
10:51 Is LiveView a stable library ecosystem?
13:38 The best approach for GraphQL and other APIS in Elixir
29:03 How to integrate the Ash Framework with Phoenix
33:35 Outro
#liveview #phoenix #elixir #software #softwaredevelopment 
Наука
Using Ash Framework, you get a consistent Elixir API alongside a GraphQL or JSON:API (or both). This means when it comes time to add an API you haven't designed yourself into a corner.
From the man himself 💪
@zach_daniel I recently got a RUclips comment asking for a demonstration of marrying LiveView on top of Ash. Maybe we can collab on a video for this?
@@liveviewmastery Lets do it 🔥
Really liking these in depth takes on "no javascript" or experiences where Micah was burned with javascript having breaking changes. Some of this resonated with myself who writes a lot of javascript. People float these phrases like "no javascript" or "javascript is bad" with no follow up. Good to get more of the context, some of it I agree and some of it not so much. But it is good to hear the full take. :)
Yes sir! Yes sir!
The problem is that, liveview is good since less Javascript but it also makes using Javascript difficult. Eventually we wound use both, then peoples tend to use single languages for full stack .
Great talk
Thanks for the video, really nice discussion.
At 17:54 "You end up bulding an api which is very specific to your UI" - I have faced this time an again.
In my experience I have been mostly happy with graphql, the only pain point I see is having to learn and implement the additional graphql layer on the backend but for me the benefits of graphql has outweighed the initial pain of setting it up.
IMHO Graphql solves lot of issues we face with REST like I no longer need to build apis specific to the UI, the front end can just query the data it wants and there is no wasted data sent over the wire, there is also typed schema and free API docs that we get for free out of the box with graphql, it also handles API versioning well. Until live view native is a bit mature and being used by more people I wound'nt risk building my mobile app using it.
Thanks again for the videos and answering my questions, keep up the good work 👍
Excellent points, Arpan. Thank you
My response to 16:16, "For a public api, to know what the public wants" - why not just wait for the support ticket? 🤣
graph ql, "the big hairy monster"