Huge ecommerce backend migration - is Phoenix the right choice?

Phoenix Forum Questions / Help
1

Hi guys,
Currently we manage a high traffic and highly customized ecommerce built with laravel. Now we are migrating all the frontend to VueJS + Nuxt for SSR. The next step maybe is to migrate the laravel backend.
One of my favourite candidate is phoenix but I’m afraid of doing a wrong decision. As I read a lot of times elixir/erlang was built with concurrency and real time in mind, but I think that an e-commerce doen’t need any of this features. The principal reason for the backend migration is the bootstrap overhead of php’s frameworks that must be done on any single request. Currenly we have 800ms page load average (not bad with all the mindblowing business logic that has this inside). The question is: is phoenix a good idea for our use case?

Thanks in advance, the elixir community is great!

4 Likes
2

I would say Elixir is definitely a good candidate for this kind of app - in fact, out of all the sites I visits, it’s the e-commerce shops where I wish they were using Elixir or Phoenix on the most… there’s nothing worse than a sluggish e-shop.

I think part of the reason why platforms like Amazon are so successful, is because they are fast and designed very intuitively - together that is a winning combination for e-commerce outlets imo.

5 Likes
3

I was a PHP 7(more performant) developer that was mainly building APIs with Laravel for big retailers in UK, thus I can definetely tell you that PHP is not the right tool for the job for an high traffic e-commerce.

We could cope with the high traffic by literal burning money in AWS auto-scaling, but the performance was always sluggish.

And if you need to have up to date prices from a third part supplier in you product list page or product detail page, then concurrency and parallelism in Elixir will shine.

Then you have the fault tolerance of the BEAM, and its Let it Crash philosophy, but you need to properly understand how to use it.

So YES you should go with Elixir and Phoenix, but please get into the functional programming mindset and leave behind the OOP way, otherwise you are not taking full advantage of the power you have in your hands.

I recommend you to read @pragdave book or its video course, because they are excellent to get you into the FP mindset.

Happy migration :slight_smile:

7 Likes
4

In terms of hosting bills and technical excellence, Elixir is very definitely the right choice. One of the very best out there in fact.

Beware though: a lot of things people take for granted in frameworks like Laravel and Rails are missing in Phoenix. You’ll have to pick an authentication framework and muscle through customising it for your own needs (Pow is really good though!). Same for other features.

You will be much more in control but if you are looking for an easy-to-use and deploy almost-ready-made solution then you will be disappointed. Have that in mind.

(I do this disclaimer because for some bizarre reason I noticed many e-commerce programmers requiring most of their work be already done and that they want to mostly just re-arrange LEGO bricks until their customer is satisfied. Maybe it’s because of stuff like Magento, no idea.)

8 Likes
5

As I read a lot of times elixir/erlang was built with concurrency and real time in mind, but I think that an e-commerce doen’t need any of this features.

I just wanted to add a bit of background to the point about concurrency: any web application needs it, by default they are all about doing a lot of different things at the same time while keeping each isolated. PHP, as the current e-commerce “king” is very single threaded though, the web server part is external to PHP applications so nginx (or apache) would handle request concurrency and isolation (mostly by having a worker process per CPU core), but that’s as far as it goes.

If we look at how the mainstream solutions work, we will see that they actually need more in terms of concurrency then PHP can offer, Magento needs cronjob to be able to perform some tasks Redirecting… and so does Laravel Task Scheduling - Laravel 5.8 - The PHP Framework For Web Artisans

The Elixir alternative would be just starting another process or setting up a GenServer as part of the application.

So basically there are things that PHP apps do by adding a crobjob that would run every minute. The “main” app uses this functionality by serializing a task (like a method call with an object and state) and saving it to the DB, then in the cron handler it would be unserialized and executed (possibly by loading another copy of the application in memory).

This whole thing will be hard to debug, scale etc. so it’s only good as long as it “just works”, not so nice in case of really big projects. With that in mind I do not believe that the hyped features of Erlang / Elixir are only needed for some “realtime features”, it’s more about us not knowing we need them till we learn to use them :slight_smile: My opinion: as long as you don’t want to use a ready made system (like Magento) - Elixir is a good choice.

3 Likes
6

Let’s be honest - how much of that 800ms is spent in the database? 99% of the time that’s the culprit for slow websites in any domain. If you’re really spending most of that 800ms in your application, then you’re not going to see much of a difference unless you drop drop down to something like Rust, Go, or go to the JVM. Elixir will be faster than PHP usually, but not by a big margin. Those other languages will all be noticeably faster than Elixir.

I love Elixir, and that’s really the best reason to use it. If your team likes Elixir and they feel productive in it, then use it. If they love the tooling and community like I do, then use Elixir.

9 Likes
7

From where did you get this impression?

1 Like
8

Most of what you said is true but let’s not forget that most runtimes will crumble under pressure or introduce abnormal lags under load.

The BEAM languages maintain a steady tempo even under stress and that’s one of their main selling points.

It’s not all only about taste and liking. I personally like 2-3 languages more than Elixir but they are yet to impress with something even roughly resembling the OTP. So I’m sticking to Elixir.

1 Like
9

Yes, one major difference is how the BEAM handles load. Slowing all requests down slightly versus crashing is a much better failure mode.

However, with modern auto-scaling architectures and platforms, this has become less of a problem. 5 years ago I would have said you needed Elixir to properly handle high throughput systems with the potential for large spikes, but today there are ways to handle this at the platform and architecture level, so that’s less of a unique selling point.

I still think the ease of the BEAM handling it is way nicer, though, and for ecommerce specifically (where a big sale might lead to a large spike in traffic), this could be a nice selling point versus the kinds of web servers that crash under load.

6 Likes
10

PHP7 is pretty fast. I have several friends who have done substantial benchmarks. Nothing much published about this on the internet yet. You can take my word for it, or not, but I don’t have data on hand to support it. I’ve seen the data, though, and they’re pretty close. PHP6 was slow, but even Ruby (which is often thought of as a very slow language) isn’t an order of magnitude slower than Elixir, and depending on what exactly you’re doing, Ruby can even be faster!

Basically, when it comes to programming language speed, there are three categories:

  1. C, C++, Go, Rust, Crystal, etc.

  2. Everything on the JVM (that sweet, sweet JIT makes all the difference there)

  3. Pretty much everything else

Now the BEAM is usually going to be the fastest for most web apps for languages in that third category because of some optimizations specific to the platform (I’m looking at you, IO Lists!), but it’s still in that ballpark.

Lucky for us, we’re usually talking about differences in the single milliseconds for many web apps and APIs. It’s only truly computationally intensive stuff (like what they’re doing at Simple Bet and Discord) where dropping down to Rust or something makes any difference to the user. For benchmarks someone can say “Rust is 10x faster than Elixir!”, but a user can’t notice the difference between 3ms and 30ms of response time. It’s only when we’re talking about 20ms vs 200ms that this even starts coming into the conversation, and that’s super rare in web apps.

Again, it’s probably the database. I’ve been a consultant for 8 years now, and it’s always the database.

7 Likes
11

Yes and no.

Yes: because indeed things like K8s and Docker Swarm are catching up.

No: (1) because they are catching up at a snail’s pace, and (2) because working with something 20% as reliable as the OTP requires a huge and inescapable vendor lock-in. :confused: Not to mention big hosting costs.

And I agree: with Elixir, you don’t have to over-provision servers in anticipation of holiday shopping sprees. That’s IMO reason enough to pick it for e-commerce alone.

4 Likes
12

So I know how PHP7 is fast, because I was working with it:

And I continue to say is not as fast as Elixir, and mile-seconds count under load, but PHP will crumble under load.

Regarding scaling you said:

But has I said, that’s is viable only for who is willing to literally burn money,

Regarding databases I can agree that they can take the most chunk of time in a request, but once more PHP as overhead in the ORM layer, that Ecto doesn’t seem to have, plus in some situations you can take advantage of Elixir to execute parallel queries to a database.

So while PHP 7 is fast for non high traffic situations, is far from being the right tool for high traffic situations.

1 Like
13

Crystal is exceptionally non-parallel though. It’s concurrent sure, in the vein of nodejs or Python with GIL threads, but it is exceptionally non-parallel last I checked?

2 Likes
14

ORMs in many of these “slower” languages are often a performance hit, but that’s not the language’s fault. If performance is a concern, you can drop the ORM. For example, right now I’m working with a Python app that’s not using any ORM because they didn’t want to pay that performance cost. The tradeoff is complexity in the application, but they felt that was warranted.

AWS bills for these languages are usually not that bad for the servers (they’re usually high for the databases - it’s always the database!). I’m working on a team that has a Java service and an Erlang service, both of which have traffic in the 1000s of requests per second, and the AWS bill for the Java app is only €335/month (roughly 2x) more than the Erlang app. We even did load testing on these apps today and found that with this current setup, we could be handling roughly 10,000 RPS without even hitting 80% CPU usage, so the server isn’t much of a cost carrier here.

Even for slower languages that need 10x the servers, it’s not that bad in reality. This is another one of those situations where €600/month is 10x(!) more than €60/month, but to a business that €540/month difference is just a rounding error in their monthly cost. For example, the total AWS bill for the company I’m working for right now is over €1,300,000/month.

If your company is extremely price sensitive, sure, Elixir will help. But for most companies, payroll costs are usually several orders of magnitude more than hosting costs. Cloud servers are dirt cheap these days.

3 Likes
15

They’re getting there. Big steps in Crystal landed recently: https://crystal-lang.org/2019/09/06/parallelism-in-crystal.html

16

Hmm, those don’t look like very good results so far, it still looks like there’s a GIL around the GC and GC operations like specifying roots (they state it’s a multi-threaded GIL, but I remember the boehm collector ‘barely’ being multi-threaded, and it required a lot of locks or spinning to accomplish). The GC and GIL were the two big reasons it wasn’t able to be parallel yet, and so far it seems like the benchmark is only really doing parallel IO, which isn’t crystal work but kernel work?

1 Like
17

This full journey about a complete e-commerce application built with elixir/phoenix might be of interest to you, if you decide ultimately to go with elixir.

3 Likes
18

You made me remember of this forum post Freshcom API - an open source eCommerce project using Phoenix

2 Likes
19

That’s not the only available library, but we don’t have details about any companies using them in production.

3 Likes
20

Rant with random thoughts incoming. No particular argument against you, just got some neurons fired by the comments here and I felt like sharing the thoughts behind them. :slight_smile:

Yes they are. But we’re going to be in 2020 soon. The IT area has to start becoming truly useful and more generally applicable. Rust’s Tokio scheduler has been improved with up to 10x performance recently. Languages like Crystal, while intriguing, will inevitably become fringe curiosities in a few years if the only thing they bring to the table is a faster Ruby-like compiled language. The LLVM / IR compilers and runtimes aren’t the ultimate art in the area but they are still times faster than Crystal in real workflows no matter what a biased benchmark like TechEmpower shows – their only valuable test is the so-called Fortunes where they include various activities done in a web app; and even that doesn’t match the patterns of real web apps usage that much. (But still, it’s a respectable benchmark; much more than their others anyway.)

People praise Python left and right but without a good solid concurrency and parallelism story akin to the OTP – and in a world where only the CPU cores will increase and the frequency will likely never go beyond 10GHz per core – it will always remain just a glue for scientific or deep learning libraries and nothing much else. This, I would argue, has happened several years ago and will only continue. Serious people with tough projects reach for other languages and runtimes. Almost the same applies to PHP (a lot of old inertia and code that people don’t want to rewrite) and Ruby (quick and convenient scripting with a slow web framework tacked on top).

I am not talking about myself here but for many other people – and they are sick and tired of IT being so grossly inefficient and coming with a ton of gotchas no matter what technology you choose. It’s an eye-opener to communicate more with people outside IT. I believe that, as a consultant, you (@devonestes) are very well aware of that.

There’s such a thing as the best tool for the job and the business reality of quick buck in exchange for a tech debt is not going anywhere until capitalism itself ceases to exist. That will be a fact of life for a while still.

But when you can use such a resilient runtime like the OTP while reaching for languages that become better every month – like Rust, and maybe Zig, Nim and OCaml in the near future – when you need the full muscle of your hardware, then a lot of other languages and tech start to look inadequate and kind of superfluous in the grand scheme of things.

As I’ve shared before in this forum, as I am [hopefully] maturing as a human being and not only as a programmer, I want to achieve more while sitting on my computers – while spending less time on them. Languages like Crystal, F#, Haskell and a ton of others can teach you interesting things for sure but I wouldn’t reach for them for real production work. Same reason while I eventually rejected Racket even though I fell in love with it – it’s an amazing language in every way but… no really good transparent concurrency/parallelism like the OTP!

The only thing that truly gives Erlang/Elixir a run for their money in this department is Rust’s actix / actix-web frameworks. And even they have ways to go still. Everybody has ways to go until they catch up with the OTP, sadly. I’d kill for an OCaml with OTP, for example…

Eventually, Elixir might become a fringe curiosity language as well. I wouldn’t kick and scream about it. For now though, it’s a very solid contender even if it lags behind Rust’s actix by a factor of 13x performance in the Fortunes section of TechEmpower (and likely 100x or more behind on true muscle power). A lot of people out there like reliability and future-proofing more and not a Ferrari that can crash into a wall after it takes three turns.

/end random rant

6 Likes