@fmorato:
Bottom line on NEREID was:
NEREID is a maximum e-shop, designed as a full solution. It doesn’t address my specific points (bad luck), implementing, modifying and maintaning would be far too expensive for small businesses.
My conclusion is that in case NEREID is adapted to a prospect’s request, I’d rather cooperate with fulfil.io to deliver the solution, and a minimal e-shop for Tryton, basic and well born is useful to my natural market.
FYI, I found interesting the methodology used by https://shopinvader.com/
The idea to re-use an existing e-commerce software which is pluggable enough to replace some part of the backend by the Tryton backend, seems the best way to achieve this goal without reinventing the wheels.
Indeed you should check the module sale_payment, its purpose is mainly for sale from e-commerce. It allows to register a payment for a quoted sale and once the payment succeed it validate the sale automatically. And the payment will be used to pay the created invoice.
Indeed I participated in the development of the sale_payment module and have since deployed it in production. It was a good fit for the flask based e-shop we deployed. It was a one-off project however we are in the process of cleaning up the code to modularise/package it better and address a couple of things for version 4.8
I just found this project https://www.vuestorefront.io/. It is a webshop front-end, back-end agnostic and mobile first.
It would just require to implement the proper API for a Tryton backend.
2 Likes
Wow, this looks very promising but we still need to have some backend module to store the cart and all the other e-shop information. Probably this can be re-used for other webshop backend (like a flask-tryton one for example)
I think the sale order can be used as cart. We could just have a flag or a state to say it is the current cart for the user.
But the sale order requires a party to be entered and for a cart you may not now the related party until the cart is processed.
So I’m wondering if it won’t be better to use a separate model to store the cart that should be latter converted to sale: once the order is confirmed an we know all the required information.
Indeed this will duplicate a lot of code. For example for shipping cost, promotion, coupon etc.
So for me, the party required is not really a problem, we can create the party up front. If it is a new customer, it is not a problem we need this new party. If it is an existing then we can just merge the parties once the user is logged.
I’m still reading about Vue Frontstore and it is still difficult for me to understand what it is.
IIUC, it results in a ready to use solution for e-shop
- running both on a browser and a smartphone
- integrating elastic search and cached operations
- on the bleeding edge of techno
- synchronizing data and operations from/to a backbone server
In this case I unsderstand we would have to develop a kind of connector module for VF so the backbone can be Tryton.
It seems from this discussion that the impact on Tryton would be limited and VF doesn’t require a lot of modules to manage the e-shop (like nereid).
And probably, VF is easy to install apart of Tryton for deployment.
I think it would be a perfect fit for a minimal e-shop. Would you see problems in scaling, or in addressing more complex requirements of sites or in customizing at an affordable cost ?
Am I correct so far ?
If I am, that sounds magic, indeed.
For me, I still understand how we should integrate the payment methods like Stripe.
The architecture is clearly designed to scale.
The customization maybe require some knowledge but customization is already a dedicated project. Simple usage may be OK with the default layout.
Indeed there is a Stripe integration. So the payment token is just send as additional payment information.
Until we have more information about the party, we can use the session id for party name.
I don’t think that’s a good idea because the user may be already known but still has not logged in. So I think it’s better to allow to have sales without a party.
The name is not required on party so no need to have any trick here.
Indeed it should not be too complicated to make party only required in none draft state.
My proposal about temporary party comes from what we implemented for https://www.jurassicfruit.com/ but it was because we could not change the required on sale at that time.
Even better, we add a state cart and party is required for all other states.
The cart state can be set only programmatically and not by user interface.
2 Likes
Hi,
you can have a look to an e-commerce frontend using tryton as backend here: https://surfshop24.de/
I plan to open source it. A first review was done by @udono.
I wrote one single module for tryton exposing an API to the frontend to simplify and standardize the communication between tryton and a class using this API from cherrypy (or flask with little rewrite). I used cherrypy because of the awesome default()-method, which lets you implement a dynamic routing.
The module sale.sale is used as cart. Like @ced stated: calculating shipments, coupons, pricelists etc is already implemented in this module. I use a dummy_party, which is used for anonymous users. So you can define all defaults on this dummy user. There is also a relation to this dummy_party or a different one on country.country to calculate shipments on country change in payment integrations (f.e. paypal has a callback to your system if user changes the delivery address). This resolves a practical problem: in most cases the final customer is known after checkout, because buying as guest using external payment services is the most used way to shop this days.
The frontend uses product data cached in redis on create/write in tryton. A fulltext search is implemented using solr (after using whoosh first - to slow).
I decided to handle all the payment workflow in the frontend and on success I use the payment modules of tryton to store the result.
About the frontend: I use cameleon templates and a minimal set of javascript because I don’t like this dependency juggernaut of javascript frameworks this days. All is done with a masterpage an about 10 small templates filling slots in the master.
One of the hard things to manage are caching policies. I try to minimize callbacks to tryton for performance gain. So one thing you have to deal with is cache handling and define smart triggers to invalidate/rebuild them.
I appreciate further discussions.
1 Like
I do a matching if user buys as guest to avoid a lot of duplicates - and if not there is already the module to merge them. A script to find possible duplicates would be nice for better data quality.
I like the “dummy” concept more since there are a lot of functionalities in sale bind to the presence of a party. Creating a party before the confirmation/payment of the sale will bloat the database with trash and should be avoided regarding GDPR
I checked this integration and its nice. But I decided to a run the workflow of the payments until confirmed in frontend for the following reasons:
- it is faster
- there are sdk for them and so no need to bloat tryton
- it is more easy to handle the design and configuration side by side with the frontend
I only store the credentials in tryton so the shop owner can change them. I also have a bool for each one inside tryton for switching between live and sandbox mode.
FYI, I just uploaded a work in progress of vue storefront integration on Issue 9010: Integration with vue storefront - Tryton issue tracker
It is just the task to fill the elasticsearch with product, category and attribute.
1 Like