I think Phoenix and Elixir is actually an excellent platforom to built e-commerce/marketplace platforms from scratch. This is different question from if you should build e-commerce platforms from scratch at all.
If you do make the decision that you build it from scratch, however, either a dedicated software for your business, hosted solution for many businesses or something you’d license to others - in my humble opinion it’s good choice to build it with Elixir and Phoenix.
Being able to scale up, being able to handle abusive clients (web crawlers/scrapers used heavily in the industry), being able to monitor things, perform long-running operations such as reporting, reaching out to external services (payemnt gateways etc) en masse etc. BEAM/Erlang/Elixir eliminates tones of problems that are being faced by the industry when they desing similar systems say in Ruby. Shopify would do well switching from Ruby to Elixir, for example (again, in my opinion). I’d say they’d definitely cut down on the hosting cost and simplify infrastructure significantly.
I don’t think Elixir is good choice if you want to use something out of the box, in most cases, as the libraries are simply not there. But if you’ve already made the decision you need to build custom stuff, go ahead and use it.
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.
For the past couple of months we’ve been building an e-commerce platform from scratch with Elixir. It’s going to be an invite only platform to bridge the gap between Shopify / BigCommerce / Tictail and custom solutions.
The general idea is to build an API first platform and build the admin and storefronts (and apps) on top of it.
First, I am impressed by the undertaking to build from scratch. I am considering to build a commercial site from scratch too but using Phoenix in the JSON API back-end and VueJS for the front-end. I have couple of questions:
Where and for which needs do you use channels?
How do you store the the shopping cart, while making shopping? In session, local-storage, as JSON object client-side? server-side?
Wow! Thanks for sharing this. I am working on a supply chain management design which is a variation of the e-cart design from Dave Thomas’ ROR book. I started with pure Elixir to play with the backend api structure. Then I added Ecto to persist the data model. From there I built it out into a set of Elixir applications with the intent to add a Phoenix client. In my current sprint, I am building it as a Phoenix app with contexts that match my application architecture. Future sprints will involve a lazy distribution architecture that will facilitate the kind of scaling that brick and mortar supply chain shops would require,
At this point, I am fully confident these technologies are a good fit for my e-commerce and enterprise needs. And, if I had to call a shot, I would say that this platform can run Amazon-level loads on a very affordable amount of hardware.
The biggest question for me (using Shopware, Oxid, OScommerce) is the right extension approach.
I don’t know, why nectarcommerce (https://github.com/vinsol/nectarcommerce/issues/53)has died, but without an extension approach, there is no way in making something like Magento, Shopware, Oxid…
I want to build conversational commerce and chatbot and broadcasting capabilities, and channels are perfect for that.
How do you store the shopping cart, while making shopping? In session, local-storage, as JSON object client-side? server-side?
I’m still designing this part, but it’s fairly straight-forward. If I go with a single item model (you only purchase one item at a time), then I only have to create an order and lock the item to prevent others from buying it until the transaction completes. If the purchase is abandoned, the lock is released.
If I am to go with a full shopping cart, I would create a database cart and store its reference in the session. I would add products as line items to the cart, and on checkout I would associate it with the current user. If the current user was already signed in, then it’s even simpler.
First, I am impressed by the undertaking to build from scratch.
Thanks. I took this on as a learning project and it soon morphed into something more. I have 25 users today, mostly small businesses. But at the moment I just link back to the products. The cart functionality will be out in about 4 to 6 weeks. I’ll let you know how it goes.
My biggest headache for now, though, is finding and Elixir lib for Brazilian payment gateways.
First, your work is inspiring. I am putting currently something together using Drupal 7 CMS. It is not an easy task, since things are so scattered there and many settings are stored in database. I believe building with Phoenix is better since using it I can achieve exactly what I want with way less lines of code.
As for the cart, I have seen a JS based front end solution which stores all cart items client side and only on checkout sends them to server. I guess you are using Phoenix HTML rendering, not client-side JS for the front-end, correct?
I think in order to make something like Shopware, Magento… you have to offer something for developers to develop plugins for the system. Simply for extending/changing the templates, programming new controllers without changing nothing or not too much of the core system.
In java world, there is ofbiz.apache.org and moqui.org available, for building ecommerce and erp.
Is it possible to build something like them in elixir? What is the advantage and shortage by doing it in elixir?
Thanks. I did build some functionality in React, then React and Redux, and then I went back to Phoenix HTML when it got painful to make progress. I ditched React and Redux because of the overhead. I wrote a couple of vanilla JS classes, barely 40 lines each, that replaced all that react stuff above. My app has some photo tagging functionality, but it’s not so rich that it required React. I added Turbolinks and the app became so fast and responsive that it became almost indistinguishable from a clientside app, so I stuck with it.
My advice about building from scratch is to only do it if it aligns with your objectives. I’m interested in learning and building something unique. I crave the learning and building experience. If I were looking at this project as an entrepreneur, I would build and test faster, and make decisions to move on or iterate further constantly. For now, I’m happilly letting this thing organically grow and so far it seems to be working out well.
In my use case, I use this reference diagram (taken from Google Images for the sake of an example)
I think it’s a simple design. It’s also pretty easy to take things from here, add more variables, etc.
The biggest challenge in building your own E-Commerce solution would be order fulfilment. It’s easily the most time consuming. In my case, I sell digital and physical products, so we’re talking about an Amazon clone, and both (offline and online) fulfilment methods are of course, drastically different.
Also, as with RoR, if you have (and you will have) 2+ layers of nested models, then it will consume a lot of your time. For example, a product has many variants and each variant will have many images. So, if you have a create product form that will also allow you to create an image and variant, then you will need to work on pretty complex logic.
I agree about the payment gateways part. Unless you’re based in a Stripe-supported country, you’ll be in so much pain since most Payment gateways are incompetent, built on legacy technology. Take PayPal for example, they have the worst possible code quality. Their APIs are almost always unreliable and slow. I wouldn’t be surprised if you tried to integrate them and saw a drop in conversions. A dirty solution would be to incorporate a company in a country like USA or Singapore which are business friendly and setup your payment gateway under them. But, you will need to decide if the bureaucracy and compliance of your company with the business laws would be worth it (hiring a tax accountant, etc) the cost trade off.
So, at any given time the user will have one shopping cart. Thanks for sharing the diagram. I hope @abitdodgy would share his model also. I think attributes, variants, colors, sizes, weights and associated costs need much coding to be implemented fully.
attributes, variants, colors, sizes, weights and associated costs need much
coding to be implemented fully.
Exactly. If you think about separating concerns, one piece of what
you’re building is an inventory management system tailored to the
types of products involved.
The “shopping cart” is separate, and fairly simple by comparison.
For data model, I recommend to check out the Moqui data model-mantle udm(universal data model). It looks complicated but is good for future expand.
For example, product price can be put in seperate productPrice table, so you can record prices of different time period by defining fromDate, thruDate. Images, warnings, terms and conditions, warranty, specification, meta keywords, meta descriptions… can be put in seperate productContent.I am trying to get myself familiar to it and it looks great. Some introduction of the data model can be found in the PDF file in moqui.org homepage, mantle-udm can be found on github. It might be helpful for your reference.
