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
