Real-time Phoenix (Pragprog)

Learning Resources Books
,
124

Thank for your worth book.
I’ve ordered this book, but just a tiny wonder that why there is not listed my country Vietnam at “Country where recipient is located” at Checkout process on https://pragprog.com/.
I also got this issue last time when buy the ebook Programming Phoenix 1.4.

Could you please escalate this issue to someone else at pragprog?

125

I’ve escalated this in the past and it’s almost certainly due to fraud prevention. The best way to proceed is to send them an email at support@pragprog.com. They may give you instructions relevant to your situation.

1 Like
126

Thanks for this info. Just purchased a copy of Programming Phoenix 1.4- great discount!

1 Like
127

I hope it’s OK to post this here.

Book is on sale for 9.32 usd at amazon. I was able to order for 7.72 usd + tax with prime. Price appears to change depending on account and if logged in or not.

https://www.amazon.com/gp/product/1680507192/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

1 Like
128

Yea, it’s a great day to purchase the physical copy! Really can’t beat that price lol. I promise it’s not reflective of the content.

I picked one up to give away at future events at that price. I was going to get more but Amazon has locked it to 1 per customer.

4 Likes
129

Holiday update! I thought Black Friday was going to be the best deal around, but it looks like the 23rd will be a one-day 50% off sale on the ebook, from Pragmatic website.

Edit: it’s only 8AM-1PM ET

3 Likes
130

Will this book be updated for Phoenix 1.6?
@sb8244 @pragprog

1 Like
131

The amount of changes between when Real-time Phoenix came out and now are exceptionally low. Basically some changes to pubsub definition that the Phoenix docs handle well.

LiveView has seen a lot of change, but there’s a new book coming out on that.

5 Likes
132

A new Real-Time Phoenix Edition 2 or just a complete new book about Phoenix LiveView?

I am now going through your book and loving it, currently on Chapter 6.

133

I guess it is this book, from the same publisher…

2 Likes
134

To expose the HTTP Push API here:

https://hexdocs.pm/push_ex/push_api.html#content

i.e. POST /api/push

I’m not 100% clear what I need to do to expose it. Should I make a PushEx.Endpoint module and add it to Application? Both the “main” MyAppWeb.Endpoint and the PushEx.Endpoint should be running simultaneously? Should the other endpoint contain websockets? I’m also going through the Real-time Phoenix book and I’m wondering if I make some websockets from the book that happen to overlap the ones in PushEx things might go hay-wire or something …

135

I have waffled on how to best support PushEx in an existing app over time. My initial gut reaction is that I don’t think it’s a good idea because your app servers will deploy more frequently than PushEx servers, which may result in missed messages. This is why it’s not supported today.

I may explore this in the future, but I’m not aware of a seamless way to integrate a complete Phoenix app into an existing app. You would need to copy the router and relevant endpoint code into your app, but there are most likely more steps. I don’t think you want 2 Endpoint modules in this case.

I can’t put time into this now, but if anyone wants to tackle it, I’d be happy to upstream.

1 Like
136

Thanks for the clarification. So going by what you’ve said, in theory I could make at least one(or a cluster if need be) of PushEx-based web apps(each of which have a single Endpoint) that effectively feed into my “main” web app(the main web app is clustered along with them but has a Server role, as described in Real-time Phoenix)?

I suppose I could not use Pushex at all and just manually create the sockets that you make in the book but it really would be nice to use that HTTP Push API.

Pardon me if I presuppose some of the fundamentals incorrectly. Im a neophyte at both websockets and clustering. I don’t even know if clustering a number of nodes within a single digital ocean droplet will benefit me.

137

This is correct. They would be different clusters (not in same deployment) and would have no relationship other than the HTTP push API exposed by PushEx.

Your backend sends HTTP requests to /api/push. Your frontend connects to PushEx channels/topics and receives the data through it.

I highly recommend this deployment style if you are wanting things to work out-of-the-box.

The biggest benefit of clustering is the resilience of the system. The most basic example is doing a rolling deployment. With a cluster, you can deploy one server, the next, etc. in a chain. In that case, your app would remain up and available. The users would receive a disconnection but it’s not the end of the world.

If you don’t have clustering and deploy to your one server, you will have guaranteed downtime. It’s worth stating that clustering for a WebSocket app like PushEx is a must if there are multiple servers. The Real-Time Phoenix book goes into this in the deployment section (ending chapters). If server A receives a push API call in its controller, it needs to PubSub.broadcast to other servers. That requires either direct clustering or Phoenix’s redis module that simulates clustering.

The reason I built PushEx is because there’s a bit more to a production system than just the API setup. I made sure to include everything that we used at Salesloft (past employer that I built PushEx for) to give high resilience and operational insight.

138

Aha thank you, this statement has really helped me materialize in my mind what sort of topology will be required to implement my app.

1 Like
139

In development, I’ve managed to implement a feature where if the user is authenticated, they can sync their data to other mobile devices via phoenix websockets. The backend architecture doesn’t use clustering(yet) but I’m wondering if I’m doing this in a long-term maintainable way. Currently I do:

  • the server takes a REST call(which then enqueues on a GenStage queue)
  • the data is inserted on the GenStage queue
  • the event is broadcast on a Phoenix Channel, with the name user:<user-id> along with the json payload that was just inserted to the db. Any other devices connected via websocket will get the update and sync the data in their local embedded db

Now that I have this POC, and I compare it to your design in Real-time Phoenix, am I doing this in the least maintainable way possible? Would it be better to:

  • client connects via channel to “edge” node, and pushes the new data to the edge node via channel
  • that edge node is connected via libcluster/gossip with the “main”(db-hosting) server and broadcasts the insert
  • the main server then enqueues it onto GenStage
  • once it’s inserted to the db, the main server broadcasts the insert for the edge node to receive
  • the edge node pushes it to the connected clients

Seeing it sync the way it is now it is very cool(and almost appears miraculous) but I don’t want to settle on a design that requires me a lot of downtime when I need to update the db schema down the line. I delayed clustering because I got bit by this OTP issue:

140

One thing that I like about the first (simpler) design is that the time-to-db and hops-to-db is minimized.

In the proposed alternative, the data has to hop from client->edge->main before it’s persisted. In general, the more jumps there are, the more chances there are for something to go wrong.

1 Like
141

Appreciate the feedback, found it heartening(and saved me from some ‘analysis paralysis’ – thank you.

1 Like
142

@sb8244 - looking forward to reading. would you give a reading guide for 2023?

143

Can you expand on your question? Do you mean a general reading guide of books relevant in 2023?

If so, most of what’s out there is still relevant. It depends a lot on what tech you want to use for your app (LiveView vs Absinthe/React for example). Pragmatic books on a specific topic have not disappointed me. But I also have been focused on starting a company so have been in a bubble.