a few months ago @htgoebel and I started research on web shops, to find a solution easy to implement and to start with. Quite quickly we came to the point that Nereid is a really promising candidate. We see major advantages:
up-to date (Tryton v7.0) and actively maintained by @yangoon ,
fully integrated with Tryton, no need for any interlink layer,
everything (except layout) can be administered from Tryton,
usage is comparatively easy, nevertheless it seems quite comprehensive in features.
On the downside we see
very sparse user guidance
minor glitches
Unluckily, @htgoebel these days is really busy with other projects, so I’m stuck with (I guess) small problems I could not resolve yet.
As several fellows have expressed their interest in a “generic” Tryton web shop in various threads - would somebody like to join in and help to finalize Nereid? - I can offer to share setup advice, initial experience, as well as doing the testing and documentation.
In mid terms, it’s likely that I’ll need a productive instance as well and can collect and document further experience. For that, the German instant payment service “GiroPay” will be required, for this implementation I can invest some money.
Cheers,
Wolf
PS: I grabbed user names from various, web shop related threads. Hope you don’t mind if I paste them here to notify this idea: @sisalp, @vincent, @koekemoerac
Hi,
we never used Nereid but used galatea modules for years, which use flask and flask_tryton.
However, we recently created a new module we named Voyager to overcome several issues we listed:
Unlike Tryton, web development does not allow for reusing much of the work done between projects
The lack of automated tests causes more issues
There is a lot of dispersion in the code files, making a change can imply changes in several files and it is difficult to know well everything that needs to be touched
In an attempt to allow reuse of code between projects, a lot of initial configuration is required and makes the logic more complex than with Tryton’s module system
It is difficult to extend existing functionalities because the consequences it will have for the different websites are not obvious
When we need the website to be very interactive (and in almost all projects there is at least one part) we need to work with JavaScript, which complicates development even more
User session management is somewhat chaotic, excessively flexible and it is difficult to know where certain information should go
We depend on too many technologies
Voyager relies on HTMX and the concept of component as well as Dominate. That means minimal or zero JavaScript and no Jinja or other templating engines.
We’re using Voyager to develop a couple of web shops (using web_user module for handling users), an app for managing warehouse operations (using tryton users) and it is also used by the new Pivot view in babi.
There’s no code that resides outside of Tryton modules and the web app can be served by trytond itself or an app.py file provided by the voyager module which can be used to serve the sites.
We also rely on Tailwind and TailwindUI for new projects, but there’s nothing in voyager that depends on that.
I just can say we’re much more productive with the new framework. Probably more than twice than with galatea.
For the record, I think the Tryton stack should not be run by the website (like with flask-tryton) this prevents a lot of caching optimization and make deployment and scaling more complex.
So I still believe the way to go is REST API for user application and develop website (with flask or whatever web framework) as consumer of such API. But for now I have not enough free time to complete the API.
Voyager supports caching at component level (think of it as HTML tag + children).
Also natively supports lazy loading of individual HTML fragments/components (just pass lazy=True). That means that the whole web page will be loaded and the missing fragments will be loaded afterwards “onload”.
So you can design all pages as if everything was loaded at once at the very end fine-tune cache or lazy loading of slower components.
Very few websites have scaling needs where that is a problem.
Developing with such infrastructure is also considerably slower. For me, such approach should be taken when the performance or scaling problems are really going to be a problem.
In other circumstances development speed and cost is more important than potential scaling capabilities.
Here you are developing diferent solutions because you all have diferent problems to resolve:
@ced wants a website solution that can be optimized for speed and allows to cache most of the records
@albert wants a website solution that can be easly developed and which most of the components can be reused for different deployments.
@herrdeh wants a website that can be easly administred from the user interface and it is easy to use.
I must say none of them really convince me, probably because we have been using flask_tryton with web_shop_flask module which works pretty well for our needs.
Having said that I will like to have the REST API available but not to use for web shiop. I will prefer to have it for any generic integration. It’s common that an ERP system needs to be plugged with other systems, so having a generic REST API instead of RPC will ease this process.
Caching is much more complex within the Tryton API because of the Transaction.context.
For me the main difficulty is the speed of loading pages to get good SEO.
For that there are 2 main issues that are solved by decoupling the website from the ERP.
having instances close to the visitor (which on the same continent)
serving mainly only cached HTML pages.
I do not see why, it is consuming an API like other proposals.
The problem is that current flask-tryton can not be used to scale so when needed you have to rewrite the all website.
The proposal will provide the same ease of developing as flask-tryton but without the scalability issues.
Sure. One has to handle that for each component in Voyager. Deciding which component can or should be cached or not (or lazy loaded or not).
Yes, number 1, is necessary for certain (usually rather large) sites. Although my guess that in many cases (for both 1 and 2) a properly configured CDN such as Cloudflare’s can also be used with no need to create multiple instances of the web server infrastructure itself.
There’s no need to explicitly expose APIs if you’re running inside Tryton modules or flask. I understand that publishing an API can make some code cleaner, but it can be slower.
May I ask at what volume of requests per second or other volume metrics you found that kind of problems so hard that you needed to rethink it?
From my very limited understanding, it looks as if there were - for very different demands (as Sergi pointed out) very different solutions.
It would be great if the great and subtle knowledge collected here could be consolidated and be made easily accessible to people interested in the issue of “ERP <> web shop”. This could be a valuable asset for Tryton.
My experience from years of managing a webshop has actually only shown me one thing: Keep the requests to Tryton as low as possible, isolate the frontend and backend and cache as much DOM as possible. It doesn’t really matter which server delivers the frontend, given the number of possible stacks nowadays, this is more of a skill set. Whether RPC or REST doesn’t really matter to me, it’s important to have a clear picture of which functions absolutely need feedback from the ERP and which can also be handled by the frontend. Ultimately, the core functions of a store are clear (and also clearly visible in the web_shop module), but the customizations are more interesting from the customer’s point of view.
@herrdeh what’s wrong with using the existing core modules?
It’s always the same answer: I have no idea what is possible and how to do it. Still being a dumb user only, I’d need quite some guidance. Does such exist?