I would like to know that is there any online source for learning Phoenix Framework for building E-Commerce Store? Any advantage on building E-Commerce store with Phoenix compare to ROR?
There are a lot of variables if you like ROR more then Phoenix and store will not have very high traffic and you do not need real time features, there is nothing wrong with using ROR.
4 Likes
6 Likes
I’m very interested in this as well. As a guy who is stuck maintaining a legacy Spree project and is actively learning Elixir for around 2 months now, I very much would like to use – or if it comes to it, create! – a Spree connector or drop-in replacement in Elixir so I can finally move that monster into a healthier ecosystem than a Rails project with 50+ gems which needs 40 seconds to even launch on Heroku (and that’s without the cache warming post-release deployment hook).
@niccolox Thanks for the links. I subscribed to NectarCommerce and when I get some free time, I’ll definitely be checking them out, and maybe help them as well.
In the meantime, does anyone know of any tool in Elixir that can consume (and optionally migrate) a Spree database to NectarCommerce database, or any other Elixir e-commerce framework for that matter?
1 Like
There was at one point a group of people with some Spree experience looking to expand into Elixir, but it has died. I was one of them – at work I manage a fork of code from solidus/spree and would love to go to elixir, but the business case is not there for me.
this one seems to mostly work
imho an elixir phoenix ecommerce app should be something new and different to spree or woocommerce or magento or whatever
I experimented with both spree and woo and I was kind of underwhelmed… they work just fine, its just tired imho
I dont know quite what yet, but if you look at the chat app ecommerce stuff for facebook messenger and the super streamline ecommerce node style UX out there …
well, its just feels like websockets and or elm should be driving this more
just my blue sky ideas
1 Like
I don’t have a business case myself for this as well. But as a senior programmer I don’t want to just pat myself on the back when learning Elixir professionally; I am not satisfied even with moderate difficulty tutorials. I want real and sellable project to work on.
I’d like to make a real education out of converting a legacy Spree project into a NectarCommerce (or another some such framework). I’d be more than willing to share the process in a series of blog posts or even create a tool to migrate a Spree-powered DB to Nectar-powered DB.
The difficulty with this is that Spree definitely has more features than Nectar and as such, my initial intention looks impossible. I’d have to both actively contribute to Nectar and gradually migrate my legacy Spree app almost at the same time. Not sure I’ll have the time or energy for that.
Are there any lessons learned from that initial effort you’d be willing to share?
There is whole bunch of people in this thread who are interested in the idea but do not have enough time to make it happen maybe if we take count it will turn out that collectively we actually do have enough time and resources.
There’s not much to share. Some people wanted a pretty direct clone, which I was against. I envision some sort of OTP umbrella app which provides a default inventory_app, catalog_app, and ordering_app which, while they have some hook points for customizability, also offer complete replacement options.
1 Like
Oh, I definitely would be against a clone myself. Elixir and Erlang/OTP bring unique opportunities to the table and we should absolutely and 100% utilize them.
I have a few ideas for several scripts which would try and validate compatibility with a Spree DB but nothing beyond that. I’d be interested in a drop-in replacement for Spree but only in functionality; not in implementation details, not even in philosophy. But it’s best not to talk a lot without actually having the time and energy to commit to such an enterprise properly.
As it is, I don’t even know where to start if I were to start right now. 
I am currently managing a magento base ecommerce site. I am looking for an ecommerce solution by using Elixir Phoenix. Hopefully there will be book/tutorial on building an Ecommerce/Shopping cart.
By the way, are you still managing Spree ecommerce site? If yes, how is it?
It is feature rich. It has most of what you would ever need in an e-commerce shop project.
That being said, it’s slow, brittle and easy to break when you try to extend things, and very big. I mean, don’t get me wrong: it is extendable but requires a lot of attention to not fall on its head. It’s an awful idea to invest in Spree for a long-term maintenance project. So I am also looking at alternatives. For now it’s only but a dream since I am very busy and I am working with the now-ancient Spree 2.2.
Seems like the projects mentioned here are no longer being maintained, or just lacking recent activity. I’m too looking for a Ecommerce platform for my next pet project. What did people end up with, and how’s your experience? 
1 Like
It was mentioned once before, but if it’s a pet project then I think there’s a lot to gain by picking apart Peach. It’s based on this talk which I found compelling, and there’s also a few insightful blog posts that help to further explain some of the design choices.
I came away with a better understanding of agents and OTP in general after incorporating some of the ideas into a side project.
1 Like
Any news on this topic. I am considering to built my own from scratch using Phoenix especially since I don’t need to care now about on-line payments (Payments by transfers or credit card over phone).
2 Likes
Great to find interested people alike in this thread. I currently have built my own and am adding more features to it everyday. I can share my experience - I initially tried the umbrella architecture and quickly burnt my finger with it. Startup time became too long, there were simply lot of models, and duplicate layouts and some patchwork simply because for my use case it wasn’t appropriate and I tried to break down everything in a possibly wrong way using DDD. I consulted the community many times when building this too. For example, I had apps broken down into Accounts, CMS, Ecommerce, Finance, Marketing and so forth. But then, E-Commerce needed to use the same entity “Page” inside of CMS. Marketing had to use the entity “User” from Accounts. This lead to cross-app queries which broke my DDD design. This is what I meant by patch work.
3 months in and I almost gave up. Finally, I decided to scrap everything and write a single large monolith instead. I was pleasantly surprised that this was the appropriate way I should have taken earlier because I didn’t have to worry about cross-app queries and also the app itself was pretty much faster. However, I hit a roadblock when trying to integrate Payments. I incorporated an incompetent gateway called PayPal whose sandbox was full of bugs. They wasted a month’s worth of development time. So, I eventually decided to stop using them and switch to Stripe to accept Payments.
Before building my own solution, which I understand requires lot of effort to develop AND maintain to keep it free of security issues and so forth, I evaluated a lot of existing solutions along the way, including Spree from the Ruby land and Woocommerce from PHP land. Woocommerce has one of the most fucked up design choices made ever and I was surprised no one even complained about it. For example, you have PHP functions that will render HTML for you and sometimes that’s the only way to output some information such as a cart table. If you want to add a class name to that table, you would pass it to the function as a parameter. So, in cases where you could just do something like <%= variable_name %> in EEX, you would have to do something like <?php function some_fucked_up_function("my_class_name", "td_class_name", [td_attributes]..., ...., ....); ?>. But, you get what I mean. I wasted so many hours into it as well and the even worse part is there are companies out there who rely on this level of obfuscation to win businesses from customers who are locked in into their eco-system. Anyway, let me end the rant there.
So, I decided it’s faster and simpler to build your own system with Phoenix than use something off the shelf and struggle customizing it. This is actually true for any software simply because of the differences in the philosophies of the software author and yourself. So, you will end up eventually adapting the system to fit into your philosophy that will cost you a lot of time. So yeah, I used Phoenix. Couldn’t be happier.
Stuff I use for my app:
- Authentication - Phauxth. Written by the man behind
comeonin,bcrypt_elixirand a dozen more. Easily the best library out there if you’re looking for a straightforwarddevisealternative from Ruby land, this is it. I’ve been using this library from it’s early releases and the author, David, is super friendly and super fast in getting things fixed. - Security - I use sobelow to scan my app for vulnerabilities. I also found this talk REALLY helpful.
- Hosting - I initially used Google’s App Engine with a custom runtime, but I blew up the free $300 credit and found it’s actually quite expensive in the long run too. It costs about $40-50 USD per month to host a Phoenix app. But, the performance is really good of course. Eventually I moved to AWS simply because I wanted a lot of other things in their ecosystem. For example, I sell digital products on my Ecommerce store. AWS S3 offers time-limited Signed URLs to prevent leeching. I use AWS Lambda for managing image uploads. Google doesn’t have any transcoding options I’m aware of. Appengine has one image service that does image manipulations on the fly, but it seems not very well documented.
- Admin dashboard - I had a pretty bad experience using a gem for admin dashboards when I worked with RoR some time ago. So, I don’t use any plugins for this, I simply wrote a custom generator in Phoenix that, each time when I use
phx.newthat would generate using my own UI. I simply used scoped routes with role based authorization to restrict it from normal users.
The best part about writing your own Ecommerce app is that you can control a lot of things - For example, I can control the checkout experience and not need to adhere to a standard 2 or 3 step checkout. I can modify this experience however I want based on certain criteria too (if it’s a home page, follow a simple checkout. If it’s a product page, follow a complex checkout, etc). if I used an OTS solution, I would need to fight it and it would outweigh any benefits it provides me. Oh and did I mention, when I benchmarked, my solution is much much faster and consumes wayyy less resources than say, a PHP based solution? 
So, so far, I’m pretty happy with my choices. I hope this helped someone
16 Likes
IMO it’s hard to justify the use case.
There are going to be 3 types of people out there:
-
Low traffic, low budget boutique shops with standard requirements that can just use Shopify or Square Space
-
Mid range shops that want to own their own site for something custom who will tell themselves it’s going to need to be amazon scale but Spree will actually handle just fine. Also they will need a dev ecosystem for future support.
-
Companies with serious budgets who actually do want to do something unique who would end up building from scratch anyway.
It’s HARD to find the ecommerce niche where a packaged Elixir solution would gain traction
3 Likes
I think, you’re right in the sense that for most use cases Spree would suffice. But, in my mind, if I wanted a custom solution, I couldn’t go wrong with an RoR project (Spree). If I’m going for RoR, then why the hell not Phoenix? I love the language more than Ruby (personal choice).
EDIT Also, to add - Another important reason I wrote this was because I have 3 ecommerce properties that are somewhat related with each other. Unless this is a custom solution, it’s pretty hard to make 3 shopify stores talk to each other.
In my case, it was pretty justified because we wanted to really have full control over a lot of aspects:
- Easy theme development.
- Must be really FAST, this means, pagespeed score > 90.
- No data leakage. I absolutely hate when I inspect the network tab from an ecommerce store run by Shopify - 10,000 requests (exaggeration) to 1000 vendors (analytics, retargeting, adserver snippets, what not). I want to own my data.
- Highly customizable. Like I mentioned above, the checkout experience for example. Very important. We now have modules that can be customized by marketing dept. without touching devs. For example, they want to run campaigns with the subscription box containing a single step opt in vs a two-step opt in.
- No vendor lock down. Some platforms out there limit you to a handful of vendors. In some stores, you’d be able to use only Paypal express checkout, which really sucks. And even if they used Stripe, they would not be in a way that we’d want. For example, we don’t want to give Stripe any more data other than treating them like a Payment gateway. So this means, we don’t want to (re-)create our products within their APIs, we simply want to use the
chargeendpoint specifying an amount. - We recently implemented chatbot functionality. Not possible within Shopify or anyone else without paying extra.
- We don’t want to keep paying for stuff that is arbitrarily removed out of a core ecommerce functionality just so the vendor can earn. Woocommerce does this. Lot of modules that make the platform useful are paid.
- Finally, we sell both digital AND offline products. Not many vendors support all our requirements, not this one without having to buy another plugin, for example.
- Hosting costs - I am actually quite experienced with Shopify, Wordpress and Spree as these are the platforms I used early on in my career. If it solved my use case, I’d definitely go with something like Squarespace or Shopify, but unfortunately (or fortunately) it didn’t and I’m so glad I developed my own. I now spend $0 - $0.50 on servers, running on Elastic Beanstalk, with the free tier. For this, I get to explore new technology and have the pride of building something as complex as an ecommerce platform. So, there is definitely value in that as well.
5 Likes
They mostly buy of the shelf “high end” systems like Hybris, Oracle Commerce etc.
1 Like
It’s not quite Ecommerce, but I’ve been building two different two-sided marketplaces with Elixir and Phoenix. Both started life as JS apps, but for various reasons it was decided to move them to Elixir.
The first is a pretty simple classifieds website, so other than taking listing fees, bares little resemblance to a traditional Ecommerce store.
The second, that I’m still working on, is quite similar to a platform like Etsy, allowing people to list items, sell them through the site, with the site managing the handling of money (using Stripe Connect). So far, this has been pretty straightforward, but I’ll confess it’s being built in such a way that isn’t even close to suitable for reuse. It’s operating in a very specific market, and a lot of the functionality caters to that markets individual needs.
Between the two apps, I’m happy to conclude that building this sort of app completely from scratch isn’t all that painful, and that trying to work within the confines of another system can be much worse. As @dsignr has said, work with the right platforms (Stripe) and a few carefully selected libraries, and it can be quite straightforward.
4 Likes
