I could not find the PDF
. I am tempted to start coding my own e-commerce Phoenix application with some JS driven front-end but I believe that much planning work must be done on modelling the whole thing first, to specify the tables/fields needed for an application of this sort.
I could not find the PDF.
I believe this: http://www.moqui.org/MakingAppsWithMoqui-1.0.pdf
is the document in question.
IMO itās a bit too Enterprise-Java-centric-overblown as a specification
but there may be some good ideas if you wade through it.
ā¦ but I believe that much
planning work must be done on modelling the whole thing first, to specify
the tables/fields needed for an application of this sort.
And thatās so product-specific; hard to create a one-size-fits-all model.
Really, Iām surprised at the lack of active ecommerce open projects available right now, interest seems to have died down, people have either coded their own bespoke project and arenāt willing to share or seem to have moved on to other languages/frameworks ?
I manage a fashion retail store turning over Ā£1m a year online with Magento but I dislike php and the Mage ecosystem, itās way past time to move away. I have built a small ecommerce shop with phoenix/elixir/stripe, it has a few options for product variables/ configurable products but will take a large investment of time to make it as complex as I want it to be for things like cron/stock reconciliation/ promotions / order system. Do I just bite the bullet and keep plugging on till I get there and have the balls to take it to live production or save myself the time and headache and go with whats out there already? Iād be willing to collaborate with anyone who has good experience with the full lifecycle of ecommerce system to share the workload.
The question is how enterprisy or not you want to make it when we were trying to do something in this space it looked like there is much bigger opportunity at the high end as itās basically dominated by 3 products SAP Hybris, Oracle Commerce, IBM WebSphere Commerce and the pricing structure for these 3 products was not aligned with realities in smaller countries. Doing purely OS product is pretty hard given the scope of effort required.
Hi,
Iām currently reading the phoenix inside out book and in it the author @shankardevy builds an e-commerce site. I think this would be the answer to your initial question regarding resources to do this in phoenix.
All the best
Carlo
We have been adding gateways to gringotts which is a port of activemerchant from the ROR world so if you could tell us explictly which gateways you need we would implement them in our library.
Introductory post for gringotts https://elixirforum.com/t/gringotts-a-complete-payment-library-for-elixir-and-phoenix-framework/
Thanks!
@ashish173 Thatās very generous of you, thanks. PagSeguro is an inferior equivalent of PayPal and the biggest gateway in Brazil. It would be great to have them. Another one is MercadoPago. Itās more polished than PagSeguro and has English documentation. Those two would be a safe bet. Let me know if I can contribute, whether itās with translating documentation or actual code.
As others have said, the time and effort expenses would be too high to have an open-source ecommerce framework. I attempted this several times myself but came to the sad conclusion that I donāt have the time and energy bandwidth for it.
Not to mention that everybody wants some arcane features that you couldnāt even think of. Making flexible and robust software is very hard and warrants a generous payment.
Thatās my reason at least. I prefer to [re-]invent stuff on a per-project basis. There have been more generic patterns Iāve noticed but so far I havenāt incorporated them in a common library because it would be incomplete and little more than a 20-50 wrappers and protocols.
Perfect! @abitdodgy I have added the issues (#123, #124) on Github.
You can track the development on Github. If you would like to pick these you can get in touch with us on our gitter room if you would like to pick these. Weāll start work on them from 12th March FYI.
@abitdodgy We have started work on Mercadopago as well. You can track the progress in gringotts github link. It will be soon merged into master branch.
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?
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.
Very interesting, thank you very much for your effort to summarize your implementation!
Iām glad it was useful. No problem.
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!
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
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. https://articles.uie.com/three_hund_million_button/
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.
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.