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:

1. Authentication - Phauxth. Written by the man behind comeonin, bcrypt_elixir and a dozen more. Easily the best library out there if you’re looking for a straightforward devise alternative 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.
2. Security - I use sobelow to scan my app for vulnerabilities. I also found this talk REALLY helpful.
3. 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.
4. 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.new that 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

I’m just chiming in to share my experience. I’m currently building an e-commerce app using Phoenix. It’s not a traditional ecommerce app, rather it hooks into your Instagram account and turns it into a store. It’s a personal project.

I chose Phoenix because I wanted to do things like conversational commerce, build a chatbot, and make heavy use of channels. I already knew Elixir and absolutely loved the language. As a person who used Ruby, Elixir seemed so familiar and exciting, and Phoenix was very easy to grock.

I wrote the project from scratch because I’m interested in the building process and the learning more than the actual commercial product.

My main difficulty was finding libraries. Thankfully, I found most of the essential ones. Now that I’m fleshing out the payment solution, my issue is finding an Elixir lib to integrate with Brazilian payment gateways.

In general, however, it’s been really pleasant to work on this project and has proved to be a wonderful learning experience.

At some point I integrated React and Redux for some more complex UI (tagging photos), but it slowed down development time so much that I ditched them in favour of Turbolinks and server-side-rendered pages. I had to change a lot of UI, but the result was great and I’m happy I made that decision.

Here’s what I’m using:

• Ueberauth and Ueberauth Instagram for OAuth
• Guardian for authentication
• (Plays well with Phoenix 1.3 and is impressive at handling authorization)
• Elixstagram for Instagram API
• Cachex for caching API requests
• Bodyguard for authorization
• Furlex for scraping opengraph data
• Number for formatting numbers

There are a few others more abstract libs, but that’s about it.

Hi everyone, sorry to re-kindle an old thread, but, almost 5 years later, I managed to update my article series on writing your own E-Commerce:

https://medium.com/@ideatocode/a-gentle-introduction-to-elixir-phoenix-part-4-53f84ef441ce

As for the dynamic theme selection, I managed to make something you can just pass a folder name at build time for the application to pick up. The other alternative was using Shopify style Liquid templates, which Phoenix/Elixir has very good (100%) support for.

Hope you find this useful!
Cheers.