Elixir Phoenix框架详析：实战教程与核心细节

需积分: 10 201 浏览量更新于2024-07-18 1 收藏 8.25MB PDF 举报

《Programming Phoenix》是一本由Chris McCord撰写，与Elixir语言创始人Jose Valim和Bruce Tate合作的英文版书籍，专为深入理解并学习Phoenix框架而设计。这本书旨在为读者提供一个全面的指南，从基础知识起步，逐步引领读者构建功能丰富的应用，包括MVVM架构、实时的客户端-服务器通信以及对第三方服务的故障 tolerance。作者们以其丰富的经验和深厚的专业知识，确保了所有内容经过详尽测试且逻辑连贯，使学习者能够在实践中体验到Elixir与Phoenix的强大潜力。书中亮点之一是它关注细节，如如何将身份验证融入Web应用和实现频道功能，以及如何利用Erlang OTP进行层服务管理。书中包含了许多来自Elixir和Phoenix核心团队的宝贵见解和实用技巧，这些对于开发者在生产环境中有效运用Phoenix至关重要。读者不仅能掌握基本技能，还能了解到如何高效地编写高质量的Elixir Web应用程序。 Xavier Noria，Rails核心团队成员，高度评价这本书，认为它是开发者必不可少的资源，因为它填补了Elixir与Phoenix之间的空白，并解决了实际开发中的棘手问题。Eric Meadows-Jönsson，作为Elixir核心团队的一员，也认可这是一份有价值的介绍，强调了作者在语言和框架开发上的权威性，以及在生产环境中的指导作用。 Kosmas Chatzimichalis，一位软件工程师，更是推荐这本书为任何想要使用Elixir编写Web应用的人必读之作。书中内容深入浅出，引人入胜，促使读者不止于阅读，而是会不断放下书去实践所学，以提升自己的编程能力。综上，《Programming Phoenix》不仅是一本技术教程，更是一本实践指南，为Elixir开发者提供了清晰的学习路径和实战经验，是深入研究Phoenix框架的理想入门书籍。

Throughput is the total number of transactions, latency is the total waiting

time between transactions, and consistency is a statistical measurement of

the consistency of the response. Phoenix is the fastest framework in the

benchmark and among the most consistent. The slowest request won’t be

that much slower than the fastest. The reason is that Elixir’s lightweight

concurrency removes the need for stop-the-world garbage collectors. You can

see results for Plug, the Elixir library that serves as a foundation for Phoenix,

as well as results for two different versions of Phoenix. You can see that over

time, Phoenix performance is getting better, and the performance is in the

same ballpark with the lower-level Plug.

You’ll see several reasons for this blindingly fast performance:

• Erlang has a great model for concurrency. Facebook bought WhatsApp

for $21 billion. That application achieved two million concurrently running

connections on a single node.

• The router compiles down to the cat-quick pattern matching. You won’t

have to spend days on performance tuning before you even leave the

routing layer.

• Templates are precompiled. Phoenix doesn’t need to copy strings for each

rendered template. At the hardware level, you’ll see caching come into

play for these strings where it never did before.

• Functional languages do better on the web. Throughout this book, you’ll

learn why.

Performance with Phoenix isn’t an afterthought. Nor will you have to trade

beautiful, maintainable code to get it.

Concurrent

If you’re using an object-oriented web framework, chances are that you’re

watching the evolution of multicore architectures anxiously. You probably

already know that the existing imperative models won’t scale to handle the

types of concurrency we’ll need to run on hardware with thousands of cores.

The problem is that languages like Java and C# place the burden of managing

concurrency squarely on the shoulders of the programmer. Languages like

PHP and Ruby make threading difficult to the point where many developers

try to support only one web connection per operating-system process, or some

structure that is marginally better. In fact, many people that come to Phoenix

find us precisely because concurrency is so easy.

report erratum • discuss

Concurrent • 3

Consider

PhoenixDelayedJob

ElixirResque

—complex packages that exist only to

spin off reliable processes as a separate web task. You don’t need one. Don’t

get us wrong. In Ruby, such packages are well conceived and a critical part

of any well-crafted solution. In Elixir, those frameworks turn into primitives.

The Elixir programming model makes reasoning about concurrent systems

almost as easy as reasoning about single-threaded ones. When you have two

database fetches, you won’t have to artificially batch them together with a

stored procedure or a complex query. You can let them work at the same time:

company_task = Task.async(fn -> find_company(cid) end)

user_task = Task.async(fn -> find_user(uid) end)

cart_task = Task.async(fn -> find_cart(cart_id) end)

company = Task.await(company_task)

user = Task.await(user_task)

cart = Task.await(cart_task)

...

You don’t have to wait for the combined time for three database requests.

Your code will take as long as the single longest database request. You’ll be

able to use more of your database’s available power, and other types of

work—like web requests or long exports—will complete much more quickly.

In aggregate, your code will spend less time waiting and more time working.

Here’s the kicker. This code is more reliable. Elixir is based on the libraries

that form the backbone of the most reliable systems in the world. You can

start concurrent tasks and services that are fully supervised. When one

crashes, Elixir can restart it in the last known good state, along with any

tainted related service.

Reliability and performance don’t need to be mutually exclusive.

Beautiful Code

Elixir is perhaps the first functional language to support Lisp-style macros

with a more natural syntax. This feature, like a template for code, is not always

the right tool for everyday users, but macros are invaluable for extending the

Elixir language to add the common features all web servers need to support.

For example, web servers need to map routes onto functions that do the job:

pipeline :browser do

plug :accepts, ["html"]

plug :fetch_session

plug :protect_from_forgery

end

Chapter 1. Introducing Phoenix • 4

report erratum • discuss

pipeline :api do

plug :accepts, ["json"]

end

scope "/", MyApp do

pipe_through :browser

get "/users", UserController, :index

...

end

scope "/api/", MyApp do

pipe_through :api

...

end

You’ll see this code a little later. You don’t have to understand exactly what

it does. For now, know that the first group of functions will run for all

browser-based applications, and the second group of functions will run for

all JSON-based applications. The third and fourth blocks define which URLs

will go to which controller.

You’ve likely seen code like this before. Here’s the point. You don’t have to

sacrifice beautiful code to use a functional language. Your code organization

can be even better. In Phoenix, you won’t have to read through dozens of

skip_before_filter

commands to know how your code works. You’ll just build a

pipeline

for each group of routes that work the same way.

You can find an embarrassing number of frameworks that break this kind of

code down into something that is horribly inefficient. Consultancies have

made millions on performance tuning by doing nothing more than tuning

route tables. This Phoenix example reduces your router to pattern matching

that’s further optimized by the virtual machine, becoming extremely fast.

We’ve built a layer that ties together Elixir’s pattern matching with the macro

syntax to provide an excellent routing layer, and one that fits the Phoenix

framework well.

You’ll find many more examples like this one, such as Ecto’s elegant query

syntax or how we express controllers as a pipeline of functions that compose

well and run quickly. In each case, you’re left with code that’s easier to read,

write, and understand.

We’re not here to tell you that macros are the solution to all problems, or that

you should use a DSL when a function call should do. We’ll use macros when

they can dramatically simplify your daily tasks, making them easier to

understand and produce. When we do build a DSL, you can bet that we’ve

done our best to make it fast and intelligent.

report erratum • discuss

Beautiful Code • 5

Simple Abstractions

One continuous problem with web frameworks is that they tend to bloat over

time, sometimes fatally. If the underlying abstractions for extending the

framework are wrong, each new feature will increase complexity until the

framework collapses under its own weight. Sometimes, the problem is that

the web framework doesn’t include enough, and the abstractions for extending

the framework aren’t right.

This problem is particularly acute with object-oriented languages. Inheritance

is simply not a rich enough abstraction to represent the entire ecosystem of

a web platform. Inheritance works best when a single feature extends a

framework across a single dimension. Unfortunately, many ambitious features

span several different dimensions.

Think about authentication, a feature that will impact every layer in your

system. Database models must be aware, because authentication schemes

require a set of fields to be present, and passwords must be hashed before

being saved. Controllers are not immune, because signed-in users must be

treated differently from those who are not. View layers, too, must be aware,

because the contents of a user interface can change based on whether a user

is signed in. Each of those areas must then be customized by the programmer.

Effortlessly Extensible

The Phoenix framework gives you the right set of abstractions for extension.

Your applications will break down into individual functions. Rather than rely

on other mechanisms like inheritance that hide intentions, you’ll roll up your

functions into explicit lists called pipelines, where each function feeds into

the next. It’s like building a shopping list for your requests.

In this book, you’ll write your own authentication code, based on secure open

standards. You’ll see how easy it is to tune behavior to your needs and extend

it when you need to.

The Phoenix abstractions, in their current incarnation, are new, but each has

withstood the test of time. When it’s time to extend Phoenix—whether you’re

plugging in your own session store or doing something as comprehensive as

attaching third-party applications like a Twitter wrapper—you’ll have the

right abstractions available to ensure that the ideas can scale as well as they

did when you wrote the first line of code.

Chapter 1. Introducing Phoenix • 6

report erratum • discuss

Interactive

Chris started the Phoenix project after working to build real-time events into

his Ruby on Rails applications. As he started to implement the solution, he

had a threading API called Event Machine and noticed that his threads would

occasionally die. He then found himself implementing code to detect dead

threads.

Over time, the whole architecture began to frustrate him. He was convinced

that he could make it work, but he didn’t think he could ever make it beautiful

or reliable.

If you’re building interactive applications on a traditional web stack, you’re

probably working harder than you need to. There’s a reason for that. In the

years before web programming was popular, client-server applications were

simple. A client process or two communicated to its own process on the

server. Programmers had a difficult time making applications scale. Each

application connection required its own resources: an operating-system pro-

cess, a network connection, a database connection, and its own memory.

Hardware didn’t have enough resources to do that work efficiently, and lan-

guages couldn’t support many processes, so scalability was limited.

Scaling by Forgetting

Traditional web servers solve the scalability problem by treating each tiny

piece of a user interaction as an identical request. The application doesn’t

save state at all. It simply looks up the user and simultaneously looks up the

context of the conversation in a user session. Presto. All scalability problems

go away because there’s only one type of connection.

But there’s a cost. The developer must keep track of the state for each request,

and that burden can be particularly arduous for newer, more interactive

applications with intimate, long-running rich interactions. As a developer,

until now, you’ve been forced to make a choice between applications that

intentionally forget important details to scale and applications that try to

remember too much and break under load.

Processes and Channels

With Elixir, you can have both performance and productivity, because it

supports a feature called lightweight processes. In this book, when you read

the word process, you should think about Elixir lightweight processes rather

than operating-system processes. You can create hundreds of thousands of

processes without breaking a sweat. Lightweight processes also mean

report erratum • discuss

Interactive • 7

剩余290页未读，继续阅读

杂毛小道

粉丝: 1
资源: 3

Elixir Phoenix框架详析：实战教程与核心细节

自己编写的80386虚拟机NXVM

Programming Windows中英文版

Phoenix.pdf

对字符串"I like java programing"取字符串"java programing"、"java"及"programing"。用StringTokenizer类实现

b64513 pmc programing manual fanuc 百度文库

windows shell programing pdf

the c programing language

Programing Flow with PEC

qt5 c++ gui programing cookbook

rockwell packml 编程规范 power programing

最新资源