This scenario is handled by the Dynamic Supervisor.ĭynamic supervisors also help in isolating when one of the component real-time interactive applications crashes. In these instances, we'll need a supervisor who can start the children on demand. When our app first starts up, however, the supervised children may not be known (for instance, a web app that starts a new process to handle a user connecting to our site). When the application first launches, supervisors usually start with a list of children to work with. Supervisors ensure that those processes are restarted if needed, restoring their initial states. By letting the processes crash instead of attempting to handle all possible exceptions within them, the “Fail Fast"- approach transfers responsibility to the process supervisor. Supervisors are essentially GenServers that have the capability to start, monitor, and restart processes. Instead, they restart the affected parts while the rest of the system keeps operating. By creating isolated processes, the idea is not to let them modify each other's state but can communicate with one another using messages.Įlixir applications do not shut down the whole system when one of their components fails. Processes ensure isolation, which is crucial to fault-tolerance - limiting the impact of runtime errors that ultimately occur. Everything in Erlang is a lightweight process that communicates by sending and receiving messages. Erlang was designed for this exact purpose. Upon establishing connection to the application, a new is created on the Erlang Virtual Machine so that each request is completely independent of the others. By running the processes in parallel allows achieving scalability- the ability to address a load increase by adding more hardware power that the system automatically takes advantage of.Īs part of the Phoenix application, every HTTP request (basically every browser tab open) joining a Phoenix Channel utilizes this capability. Scalabilityīy creating a dedicated process for each task, all available CPU cores can be taken into advantage thereby achieving maximum parallelization. The process provides the basis for building scalable, fault-tolerant, distributed systems. BEAM employs processes as the primary unit of concurrency. Phoenix inherits its characteristics from Elixir, which in turn derived them from Erlang, thanks to the primitives of the BEAM virtual machine and OTP's architectural patterns. When it comes to making a system highly available, two main considerations are fault-tolerance and scalability. One of the most important aspects of developing real-time applications is to ensure that they are highly available. How Phoenix achieves fault-tolerance and scalability? |> put_temporary_flash(:info, "Entered the lobby") # Example usage of plugs by looking at the router.ex of a phoenix application The Channel server process subscribes to the joined channel topic on the local PubSub. A client connecting to a channel topic will trigger the join callback function through which a new Process is launched. The Channel module is a GenServer implementation with join callback functions that enable sockets to connect to channel topics. It allows millions of connected clients to communicate in soft real-time.Ĭhris McCord, Creator of the Phoenix framework was able to achieve 2 million websocket connections on a single computer with Phoenix Channels, but by splitting traffic across numerous nodes, it may perform even better. The Phoenix library's cardinal component is channels. The incoming client data is routed to channels via transports. Once connected to a socket, incoming and outgoing events are routed to channels. It is the responsibility of the sockets to tie transports and channels together. The Phoenix framework has in-built WebSocket functionality, which may be used with the Socket and Channel modules. Real-time web applications often use the WebSocket protocol to relay information from the server to the client, either directly or indirectly via a framework (such as Socket.io). Phoenix is designed to use WebSockets by default rather than long-polling, but it comes with support for both. It is the place where a socket is defined on the /socket URI and notifies our app that all connection requests will be handled by the UserSocket module. Websocket: [connect_info : [session: application endpoint serves as the beginning point where our socket endpoint is defined. # all these connection requests via UserSocket module # Declaring a socket at "/socket" URI and instruct our app to process
0 Comments
Leave a Reply. |