<div dir="ltr">Web apps naturally federate activities into separate threads - each one handling a request. You already have a lot isolation in effect off the bat - any HTTP request should be able to (directly) impact another.<div><br></div><div>The material benefit is that your app can handle a *lot* of concurrent access without becoming corrupt. You can even be sloppy and still probably get away with it. This is *not* true of say a Java app - if you don't pay very close attention to the way memory is allocated and accessed, a long running app like a web server will fall over eventually.</div><div><br></div><div>This btw is why you still see advocates of CGI style web apps (fork exec). They introduce substantial overhead by using separate OS processes but they're *stable* in the face of load, sloppiness, bugs, unexpected events. Give that web apps are trivial to scale horizontally, people who prefer their software to run without falling over will opt for the extra cost per HTTP request.<br><div><br></div><div>That part's easy - you're already getting it. A win!</div></div><div><br></div><div>As for the rest, you're also already getting it :) You have no choice here. Sorry. You cannot create the ball-of-twine that often emerges from a monolithic app managing a single shared heap. Another win!</div><div><br></div><div>As for the rest... just solve the problems that you have! You have expressed angst and wonder and hope. These are all good and important topics but they're not problems to your app.</div><div><br></div><div>What's the next thing you need to do for your app? Provide a specific problem and it will be easier to elaborate some options - and then pick the one that is the most sensible.</div><div><br></div><div>I think one of the reasons Erlangers don't talk a lot about architecture is that process oriented apps can evolve very happily without much forethought. That's true of systems. As much as we like to fancy ourselves as architects and designers, good systems evolve incrementally. If you have the right underlying abstractions to support evolution, you'll get that without trying. I believe Erlang provides those abstractions:</div><div><br></div><div>- Isolated processes</div><div>- Links (enable supervision and a cascading process death)</div><div>- OTP managed processes (servers/services and supervisors)</div><div>- OTP apps (system startup and upgrades)</div><div><br></div><div>Okay, that's all high level and more of the stuff you've heard and I know it doesn't answer your questions :)</div><div><br></div><div>Starting with your app, each HTTP request handler is running in a separate process. That's how they run concurrently. Each handler will want to do something: serve a page, read from a database, write to a database, etc. You ought to provide a nice API for each of the things these handlers do. The API will be implemented via functions that live in a module. You have no choice.</div><div><br></div><div>The decision then becomes how are these functions implemented. Do they just crank through sequential Erlang without sending or receiving a single message? That's your best bet if you can swing it - a nice side effect free function! A good example of that would be serving a web template. Using a great library like Erlydtl you'd just call your compiled template module - it will render the data and off it goes to the client. There's no gen_server here. It's just each HTTP request handler doing work alongside the other. Super scalable. Super simple.</div><div><br></div><div>But now accessing a database...</div><div><br></div><div>This depends on the database library you're using and whether or not its API supports concurrent access. I imagine most would - but via what? There'll be something that is shared here - a connection, a pool, a registered process. You should understand that that thing is and then consider how all your HTTP request handlers will access it. If you're sharing a single connection, for example, that can only manage a single transaction at a time, obviously you don't want each request piling onto the same transaction. In that case you'll be either serializing access to this connection (you'd use a gen_server for that - or an e2 service) or use multiple connections via a connection pool (which also requires serialized access, again via a gen_server/e2 service).</div><div><br></div><div>But really, if you get this wrong, you're going to run smack dab into a very concrete problem that you *must* solve to move forward. You don't really need to design this stuff. Once you run into a few cases of these problems, you're going recognize them and know how to fix them.</div><div><br></div><div>I *think* it comes down to this: do you need to serialize access to something? If yes, your API sits in front of a process, which implements the functionality safely in the server loop (no concurrent access). If no, your API implements the functionality directly.</div><div><br></div><div>More...</div><div><br></div><div>Use OTP (or e2) and run your processes under supervision.</div><div><br></div><div>If your processes are short lived, use a simple-one-for-one supervisor (e2 task supervisor + tasks) to start them.</div><div><br></div><div>Don't solve problems you don't have. In particular, don't add or use something unless you have to. That goes for OTP apps. Just use one. Don't implement functionality behind a gen_server unless you know why you're doing that (e.g. to strictly control access to something). Don't use a separate db for each customer unless you know why you need that. Etc.</div><div><br></div><div>I don't know, I'm running out of ideas here :)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 16, 2015 at 12:31 PM, Lloyd R. Prentice <span dir="ltr"><<a href="mailto:lloyd@writersglen.com" target="_blank">lloyd@writersglen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ah Professor Smith,<br>
<br>
Once again I must confess my ignorance in hope that you can bring clarity. I've been working happily with sequential Erlang now for several years--- most recently an ambitious Nitrogen app. And I've heard from the beginning the virtues of of distributed concurrent processes happily chattering among themselves.<br>
<br>
But where the rubber meets the road, e.g. as I design my current app, I just don't get how to transform these virtues from virtual to real.<br>
<br>
Conceptually, I understand spawned processes, message passing, and supervisors. I've read and reread the Erlang canon. I've built several gen-servers and have worked my way through your e2 tutorial. It all makes good sense.<br>
<br>
But as I consider these principles in context of the architectural design of my current app, it's not at all clear how to apply them.<br>
<br>
The goal of my webapp is to deliver a set of data-based "tools" to "users" (wouldn't it be nice if we had many of these elusive critters) where each user owns his/her own data.<br>
<br>
In my case, users are non-technical author-publishers where each has a personal page for accessing tools and managing data related to project, marketing, and business management.<br>
<br>
Best I can tell, Cowboy and Nitrogen deal with "connections" and "sessions" under the hood, so I don't have to worry about them. But I struggle with such questions as:<br>
<br>
-- Should each "tool" be implemented as a gen-server?<br>
-- Should the user interface and database be further factored as separate processes?<br>
-- Should each "tool" be developed as a separate Erlang application then integrated as dependencies of a higher-level portal? Or should they be developed as a set of modules in one application?<br>
-- Or maybe each tool should be a totally independent "microservice," whatever that means.<br>
<br>
In other words, my attentive studies of Erlang have left me with very few PRACTICAL architectural techniques and tools; that is an insufficient bridge between the PRINCIPLES of concurrent Erlang and the PRACTICE of building robust Erlang systems.<br>
<br>
I'd much appreciate any guidelines to help me thrash through my confusion.<br>
<br>
But more, I wonder if others struggle with the same issues? And if so, how can I work with wizards like you to shed light on this corner of Erlang technology?<br>
<br>
All the best,<br>
<br>
Lloyd<br>
<br>
Sent from my iPad<br>
<div class="HOEnZb"><div class="h5"><br>
> On Jan 16, 2015, at 10:03 AM, Garrett Smith <<a href="mailto:g@rre.tt">g@rre.tt</a>> wrote:<br>
><br>
> I don't think Erlang has an edge over any other language in terms of<br>
> scaling across multiple servers - not at all. Other functional<br>
> languages have access to network APIs the same way Erlang does.<br>
><br>
> I suppose it's less fiddly to send Erlang terms across the wire.<br>
> Erlang has some built in facilities for building distributed<br>
> applications. Erlang's been doing this sort of thing for a long time.<br>
> But other languages can do it - particularly with the many<br>
> multi-language messaging libraries and tools available today.<br>
><br>
> What Erlang is special for IMO is it concurrency model, which is<br>
> implemented in and enforced by the *VM* - there's no shared memory<br>
> across threads of execution. One thread cannot corrupt the memory used<br>
> by another. To communicate between threads of execution, threads must<br>
> pass and receive messages (copied data).<br>
><br>
> I use the word threads generically here - in Erlang they're called processes.<br>
><br>
> This changes everything. It's completely transformative of the way you<br>
> build software. But the real payoff is in your locally running program<br>
> and less so in the ability to "distribute".<br>
><br>
> Try building software using single threaded, isolated processes (no<br>
> shared memory). How do you do it? If you use Erlang, you're forced to<br>
> do it - there's no choice.<br>
><br>
> It's the same as the operating system level. How do you build a LAMP<br>
> stack? (sorry, I'm older then 24) You install independent components<br>
> (Apache, PHP (fork exec'd), MySQL). Then you configure them to work<br>
> together. Then you start them up in a particular order. It's<br>
> coordinated communication independent functions. If one blows up, the<br>
> others keep working.<br>
><br>
> Imagine every part of your program working like this and you have an<br>
> Erlang application - actually, an Erlang *system*.<br>
><br>
> To replicate this model at the OS level, you'd write dozens of small,<br>
> independent applications that communicated with each other over pipes<br>
> or sockets. The ZeroMQ community is familiar with this approach.<br>
><br>
> The payoff for this, as I see it, is flexibility and speed of<br>
> introducing new functionality and fixing bugs.<br>
><br>
> To illustrate at a higher level, imagine a smart phone today that<br>
> didn't provide isolation across applications. What would you expect<br>
> from it? I'd expect it to not work unless the applications were all<br>
> nearly perfect. That means it will either not work, or the app<br>
> ecosystem would be very limited. But today, smart phones all have<br>
> kernels and user space where apps are isolated from one another. So I<br>
> can install some random thing from an app store and have a pretty high<br>
> confidence that it's not going to ruin my phone. The result is *huge*<br>
> app ecosystems with phones that pretty much work (shockingly well for<br>
> what they're asked to do).<br>
><br>
> When you use Erlang, your program becomes this ecosystem of "apps"<br>
> that you can add to, modify, remove very freely without concern for<br>
> the whole system. Your program will be evolvable *and stable* in the<br>
> same way your phone is evolvable and stable. It's a scalable<br>
> programming model!<br>
><br>
> It's truly fantastic - and seldom mentioned. (Folks here have heard<br>
> this line from me before - this is my particular drum that I like to<br>
> beat on :)<br>
><br>
> Use Erlang!<br>
><br>
> Garrett<br>
><br>
> P.S. I routinely run into critical memory problems in Java apps that<br>
> host ecosystems of other "apps" (plugins). It's a completely<br>
> unsolvable problem when your language/VM encourages intractable memory<br>
> graphs across threads unless you are incredibly careful about what you<br>
> run. If you want to make a system pluggable in Java (in one JVM), be<br>
> prepared for it to stop working at some point. So your either limited<br>
> in what you can do (and how fast) or in the stability of your program.<br>
><br>
> On Fri, Jan 16, 2015 at 6:29 AM, Jesper Louis Andersen<br>
> <<a href="mailto:jesper.louis.andersen@gmail.com">jesper.louis.andersen@gmail.com</a>> wrote:<br>
>> I think your observation is correct.<br>
>><br>
>> An Erlang program works by having many small processes, all isolated from<br>
>> each other. The way to communicate between processes is to send a message,<br>
>> asynchronously. This in turn leads to the key observation: when you send<br>
>> messages, you don't care about *where* the other process is. It could be<br>
>> local or on a completely different machine. The syntax and the semantics are<br>
>> the same, and you would program the system much in the same way. The<br>
>> environment is thus very homogeneous, compared to other solutions where you<br>
>> need to communicate on two levels: one for local messaging and one for<br>
>> distributed messaging.<br>
>><br>
>> I also second Bob's observation: The design feature of being functional<br>
>> forces a lot of properties which are beneficial to programs where<br>
>> correctness matters more than squeezing out the last ounces of performance<br>
>> from a tight computational kernel. But there is more to it than that. A good<br>
>> example is the choice of standard data structures which have no pathological<br>
>> problems in corner cases. Or the deep continued focus on scaling to multiple<br>
>> cores rather than looking for efficient single-core performance.<br>
>><br>
>><br>
>>> On Thu Jan 15 2015 at 11:38:52 PM Bob Ippolito <<a href="mailto:bob@redivi.com">bob@redivi.com</a>> wrote:<br>
>>><br>
>>> I'd agree with that observation. Erlang is particularly well designed for<br>
>>> reliability and ease of maintenance/debugging. I wouldn't necessarily say<br>
>>> that these properties are due to the language, it's really the environments<br>
>>> that Erlang has been deployed in that shaped the VM and libraries in this<br>
>>> way. The tooling and libraries have at least a decade head start for this<br>
>>> kind of industrial usage over just about any other functional language.<br>
>>><br>
>>>> On Fri, Jan 16, 2015 at 9:01 AM, Ken Wayne <<a href="mailto:kwayne@eastbay.com">kwayne@eastbay.com</a>> wrote:<br>
>>>><br>
>>>> I've been investigating functional languages and the concepts that lead<br>
>>>> to increased speed, reliability, and decreased maintenance.  Erlang seems to<br>
>>>> have a distinct advantage over other functional languages when you need to<br>
>>>> scale across multiple servers because it's a natural part of the language.<br>
>>>> Can anyone confirm/deny or elaborate on the observation?<br>
>>>><br>
>>>> Without wax,<br>
>>>> Ken Wayne<br>
>>>> <a href="mailto:kwayne@eastbay.com">kwayne@eastbay.com</a><br>
>>>> Desk: 715.261.9412<br>
>>>> _______________________________________________<br>
>>>> erlang-questions mailing list<br>
>>>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>>>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
>>><br>
>>> _______________________________________________<br>
>>> erlang-questions mailing list<br>
>>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> erlang-questions mailing list<br>
>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>