I am building something very similar at the moment and therefore, it would be really interesting how you tackled the part with “theme development”? I guess you implemented a multi tenancy solution, is that correct? How did you enable theme development and do you mean with the term something similar as Shopifys implementation with Liquid? Or is it just limited to customize some stylesheets?
Monotom
dsignr
Well, I’m glad to share my workflow. The way I solved is pretty unique to my usecase, but still worth sharing.
In my config file, I have this:
# Setup your site's theme here.
theme = "myile"
System.put_env("THEME", theme)
config :myapp, MyAppWeb.Endpoint,
url: [host: "localhost"],
.
theme: theme,
.
Inside my brunch-config.coffee:
theme = process.argv[process.argv.length-1]
themeUrl = "themes/#{theme}"
.
.
exports.config =
optimize: false
files:
javascripts:
joinTo:
"js/#{themeUrl}/admin/products/crud.js": [
"js/#{themeUrl}/common/*"
"js/#{themeUrl}/admin/products/ui/formatting.coffee"
"js/#{themeUrl}/admin/products/ui/product_variations.coffee"
"js/#{themeUrl}/admin/products/crud.coffee"
]
My assets folder looks like this:
js/themes/myile/admin/products/ui/formatting.coffee
.
.
and so on.
And then, I create a helper file for use inside my views:
def current_theme() do
Application.get_env(:myapp, MyAppWeb.Endpoint)[:theme]
end
def theme_url() do
"themes/#{current_theme()}"
end
And, inside my layout file:
<%= render MyAppWeb.LayoutView, "#{theme_url()}/components/my/search-bar.html", conn: @conn %>
This method helps me to define a standard theme. But, my store also has multisite support. Meaning, domains abc.com and xyz.com are run on the same instance of my store, so each store uses a different theme. Directly loaded from files on disk. But they can also be switched from a graphical UI inside my custom admin panel.
I initially wanted to go the shopify route (using liquid templates). But, not only does it complicate your implementation, it also doesn’t add much value. Since, these are templates used from the backend interface and not by my customers, I don’t need to worry about third party devs, in which case the shopify templates would have made sense. I can simply use the tried and tested EEX templates now which more than just get the job done.
I hope this helped.
3
Monotom
dsignr
dsignr
As an update to anyone following this thread, I’ve decided to start writing about my journey of writing my E-Commerce application from scratch on medium and why I made the choices I made. Hope it helps! 
4
pkrawat1
Aviacommerce is an open source e-commerce platform in Elixir. At aviabird have been working on it for last 9 months. This platform has all the core features which any basic e-commerce system should have. Developers can start exploring the project with the help from documentation website.
As of now, we have just released the developer documentation. This would help developers get started with using it to create their own solutions on top of it. Next up is user guide. We’ll release it by the end of October.
We are expecting feedback/suggestion from the community on how can we improve this e-commerce platform. Please use Github issues to report bugs if you find them.
We would like to thank all the developers and clients who have helped us make this project a reality.
Please use the gitter channel to interact with the dev team or if you have any questions or suggestions.
You can also follow us on twitter for latest updates.
Important links
3
Cochonours
Looks nice, and just on time as I was looking for something simple and nice, and hopefully not dead like other projects linked in here.
I just tried your demo and there is a big red flag : why do you force customers to log in when they want to checkout? That’s a big no-no to force them to create an account or log in when most people just want to buy something and go on with their lives. See. The $300 Million Button — UX Articles by Center Centre
2
ashish173
Wow! the revenue jump is mind-boggling for this small a change. By far the best example highlighting the importance of UX on any business.
We had a discussion internally about the approach to take with aviacommerce. When we started discussing it our approach was to review some of the existing e-commerce companies. Understand the approach they are taking and try to reason from there. We looked at amazon.com, flipkart.com, shopify.com flow and a couple others. In this not so extensive research we found out that all the platforms were taking the approach to force the user to log in before they could checkout. We believe these giants have research teams working on just making the checkout flow as smooth as possible. So we didn’t consider taking the guest checkout approach after this point.
However, we didn’t rule against the idea of guest checkout approach completely. We made a choice to not implement it at this point keeping in mind if the community shows interest and wants it then we’ll certainly add this feature. As an open source platform targetting the community we can’t afford to not support this. So we’ll implement this feature sooner than later.
At this point, we are focusing on providing support for essential third-party services such as marketing, shipping services, CRM etc. Any e-commerce platform is incomplete without the support for these services in form of plugins. Read more on our vision here.
Thanks for sharing your valuable feedback. It’s this kind of feedback that we are looking for.
FYI I am one of the members of aviacommerce project steering the project.
1
LostKobrakai
The bigger the platform the more likely it is that users already have an account on there, negating the negative effect of needing to register before buying something.
4
Cochonours
To complement what LostKobrakai said, the bigger platforms have a competitive advantage in requiring for people to create accounts: by doing so, users will be more likely to come back there to buy, and they want to sell often in order to promote their delivery subscriptions. Of course it only works because they are alrealdy in a position of monopoly, or at the very least are big and extensive enough to compel people to register.
I think for smaller platforms, and especially for the more specialised ones that do not really hope to sell a product twice or thrice to the same client, it’s much better to not force people to register. It’s always a nice option to give, but it should remain that: optional, for easier purchases later on.
BTW to complete the first purchase, the user will have to give his name and address, as well as email in order to receive updates about his purchase. The only thing lacking for the creation of a “real” account is a password, so the only difference between “create an accont” and “do no create yet” is one password field.
1