shopinvader / odoo-shopinvader

It's more of a CMS development toolkit than a "real" CMS which from my understanding is what shopinvader needs: not too generic but there's enough to gain time

simahawk commented 3 years ago

IMO if we have to move away from Locomotive we should 1st move to a new JS layer (eg: web components) and 1st rework Locomotive integration on top of this. Then you should be able to replace the app layer as you like.

Regarding the app underneath: IMO we should consider Odoo itself. Especially because we want to push this to the Odoo community. You'll still have 2 services but they will use the same tech + benefit from all the goodies of the Odoo world. That's maybe not appealing for web designers but neither will be with any other framework if you don't rely on fully independent frontend layers. To mitigate this, we can probably leverage an old friend from the Plone community: http://docs.diazo.org/en/latest/. Just static themes applied on top of any application.

bealdav commented 3 years ago

Please @Cedric-Pigeon @lmignon @sbidoul @acsonefho @JordiBForgeFlow @rousseldenis @Laurent-Corron @yvaucher @grindtildeath could you have a look here ? A pythonic alternative to Locomotive ?

legalsylvain commented 3 years ago

Hi. For the GRAP side, I just migrated from 8.0 to 12.0 and we are interested to deploy some shops with shopinvader technology. One of the blocking point to invest time / money on that project is the language of the shop. I think that using another language than python reduces the adoption of Shopinvader, because Odoo is based on python.

So any movement in this direction would be welcome. :100: :+1:

IMO we should consider Odoo itself.

@simahawk : I don't get your point here. Do you consider having 2 Odoo instances, interconnected. (one for the front end, one for the backend ?)

Regarding coldCMS (light Python CMS, based on Wagtail), if you have questions, you can ask to @arthru and @luciend.

simahawk commented 3 years ago

@simahawk : I don't get your point here. Do you consider having 2 Odoo instances, interconnected. (one for the front end, one for the backend ?)

Exactly. Good reasons:

ease inheritance/override of modules and themes
same tech, same knowledge base, same deployment approach, etc
strong base for any frontend development given the huge OCA ecosystem
make OCA adoption easier
the future of the framework is (even if only partially) in our hands

I made a proof of concept almost 2yrs ago and it was good. I stopped only because time was short and porting all templates from Locomotive to Odoo was not a quick task and was not adding big value to customer for the project's scope. But to me is still a valid alternative even if it might sound weird to ppl not used to web devs w/ Odoo.

You can even imagine to use it w/ one Odoo instance (eg: customer don't need/want separation).

The core features of Shopinvader are still there: REST services and product catalog delegation to external SE.

bealdav commented 3 years ago

Yes Odoo is an option with all Pros that @simahawk said. About Cons:

not free migration path with Odoo websites. Odoo backend migration is already a project in the project
refreshing websites rhythm might not match with odoo backend project
[Edit] build web, websites, ecommerce, miscellanous applications or portal not only concern Odoo aficionados, it can be achieved by many other great tools great things living in other repositories than OCA [/Edit]
many website makers are sometimes scared by Odoo website stack, at least learning curve may appears hard
inheriting of Odoo choices is sometime painful and web technos evolve faster than Odoo implemented projects
Odoo developers might make a smooth transition to pythonic stack other than Odoo, for websites
to code in other stacks could lead to better practice when back to Odoo itself

Then to have all these options, we need to make it easy to plug shopinvader components / api for many web technos: js, ...

kevinkhao commented 3 years ago

Some discussions have been going on at Akretion FR for a while about this.

One point to raise is that this is a high-level strategic decision for everyone that uses Shopinvader. If we choose one option for someone's x or y reason, it might not align with everyone who uses it. In the medium term, it seems from a business standpoint we can keep on doing what we do and be fine with Locomotive.

If we choose to change to another technology, maybe 3 years later we realize we are limited in our goals and then we have to change the whole stack again. Ideally everyone will have about the same idea of what exactly Shopinvader should be, its place and scope, what are its long-term targets, and then we have some real basis for actually pooling our efforts in x or y technology (I don't speak for Akretion, but it seems to me like it would be ready to invest when we know where we are going).

simahawk commented 3 years ago

Yes Odoo is an option with all Pros that @simahawk said. About Cons:
* not free migration path with Odoo websites. Odoo backend migration is already a project in the project

And? Whatever tech you'll choose, you'll have to deal w/ migration when new major versions come. Also, you can be completely independent from Odoo websites in terms of templates.

* refreshing websites rhythm might not match with odoo backend project

IMO you don't care: potentially you can have backend on 14.0 and frontend on 12.0 as long as they are 2 separated instance -> you won't have to migrate 2 odoo instances when the new shiny Odoo version is released.

 * web, websites, ecommerce, misc portal is not only concern Odoo aficionados, great things live in other repository than OCA

I don't get this.

* many website makers are sometimes scared by Odoo website stack, at least learning curve may appears hard

Just because they don't know it. The same goes if you don't know nothing about Django or Locomotive if you are not familiar w/ Ruby and/or Liquid.

* inheriting of Odoo choices is sometime painful and web technos evolve faster than Odoo projects

Which on the other means a bit more stability?

* Odoo developers might make a smooth transition to pythonic stack other than Odoo, for websites

I'm not sure about this, given good docs an big ecosystem.

* to code in other stacks could lead to better practice when back to Odoo itself

I won't bet on this :smile:

Then to have all these options, we need to make it easy to plug shopinvader components / api for many web technos: js, ...

This is very important.

sbidoul commented 3 years ago

I personally don't have strong opinions on CMSes. Except that maybe if there are so many of them it could be that the graal has not been found yet, or there are so many competing use cases that can't converge.

The most important thing is the Shopinvader REST APIs must be stable, well documented and easy to use. And not tied to Locomotive.

All improvements in that area will make Shopinvader better and maybe at some point people will be able to easily create an e-commerce site with the CMS of their choosing. But we are not quite there yet I think. And as mentioned above, keeping the community focused is probably more important at this point in time.

Important topic to address towards these goals are IMO (I certainly miss some):

customer authentication in Odoo (will happen this year)
the cart cache mechanism can certainly be improved and made easier to use in the front-end and the back-end while keeping the architecture reasonably simple
in general, understand what Shopinvader knowledge is embodied the locomotivecms plugin and see if it can be reduced (towards being able to use a purely "headless" CMS)
some reusable web components that would encapsulate the trickiest parts of the front-end template

As an aside, about the web components, I think it's a very good idea but not for the whole template. There is value to the copy-paste template approach in the front-end.

@legalsylvain all this should not make you fear to come aboard. Shopinvader works very well and you don't need to learn any Ruby to use it, only Liquid templates.

simahawk commented 3 years ago

Some discussions have been going on at Akretion FR for a while about this.

One point to raise is that this is a high-level strategic decision for everyone that uses Shopinvader. If we choose one option for someone's x or y reason, it might not align with everyone who uses it. In the medium term, it seems from a business standpoint we can keep on doing what we do and be fine with Locomotive.

If we choose to change to another technology, maybe 3 years later we realize we are limited in our goals and then we have to change the whole stack again. Ideally everyone will have about the same idea of what exactly Shopinvader should be, its place and scope, what are its long-term targets, and then we have some real basis for actually pooling our efforts in x or y technology (I don't speak for Akretion, but it seems to me like it would be ready to invest when we know where we are going).

I understand the POV of Akretion :) In any case, we should consider improving this thing. Locomotive is for many aspects very fragile. Not to mention is a pain in da neck to keep templates in sync (fixes, new features, etc).

From my POV the only key selling point are: live / fast deploy, theme design w/out full stack. The rest is something that you can get from any modern and light CMS out there. Correct me if I'm wrong.

In any case, working on a generic pluggable frontend layer (JS mostly) that can be reused across templates/projects and across technologies seems to be good choice.

rvalyi commented 3 years ago

Hello, a few considerations:

I know the web and CMS very well myself (not the case of all people coming from the ERP world). I think there is a couple of issue to worry about with LocomotiveCMS: basically it is not as active as it was and MongoDB is holding its adoption back nowadays. Fixing that has a cost for sure. But eventually that cost is not more than the other options.

May be first, I should say I totally agree with the idea to make the Odoo Shopinvader API the cleanest possible and have all the Shopivader logic behind this API.

Now a few consideration about the CMS and web stacks:

A) considerations for projects with very specific requirements on Locomotive

I totally understand that some people feel more comfortable using another CMS or web stack, possibly in a stack they are more familiar with. This is specially true for large projects with a lot of specific requirements.

But sometimes it seems people are trying to address specific requirements by twisting the Liquid tags to their specific requirements. This is not the way Liquid is intended to be. Liquid is made to give web-designers and non specialized web delevoppers a basic toolbox to achieve a scalable offer for standard projects exactly like Shopify is doing with a tremendous success.

On Locomotive, very specific requirements are better addressed with specific Rails developpments, ideally consuming the persistent data from Odoo or Elastic. And Rails is arguably one of the most powerfull web stack for customized developpement. Eventually one can also break free from the Liquid sandbox using custom client side developments, like with VueJS along with Odoo API customizations. A good Shopinvader API consumable directly from Javascript certainly helps here and with any backend technology.

Addressing custom requirements through a templating library will always be very hard and reserved to an elite on the considered stack. Debugging a Liquid error stack can be daunting. But this will also be true to debug a Vuetify template error, this is also true to debug a qweb stack trace...

Advanced things like getting Rails a Turbolink Javascript context right might be challenging.

But many CMS simply just don't have such options or in very experimental ways while in Rails they are used a lot by Shopify, Github and many for years. And now Rails has things like Hotwire or Stimulus for an effective partial server side rendering.
Doing trivial client side rendering like in an average Vuetify tutorial might look sexy on the surface, but this alone will not do the cut for a real work usage on mobile or for the SEO.
Once you complete this with server-side rendering options like the excellent NuxtJS, then you will find back the complexity you had with Turbolink or Hotwire.

B) considerations for a scalable CMS offer

Here I mean scalable in term of business not what the biggest site you can do. One should not underestimate the value of Liquid and LocomotiveCMS here. There are many other CMS arround. But anyone with e CMS experience shoudl know that a huge part of a CMS project is the cost of the interaction between the web-designers and the website backend. Supporting such a cost is totally acceptable for large projects with very specific requirements. BUT it is not acceptable for standard projects and the CMS stack with no solution for this will simply get no market. Specilly they will loose against the Odoo standard website stack more and more. With the wagon webdeveloppment cycle, Locomotive got this very well and I saw no other CMS with such a thing.

C) considerations about Wagtail

I didn't dig very deep in Wagtail. But still let me point you a few things you may not be aware of. First, just a bit like Locomotive it also depends on a single guy doing 80% of the work:

2021-02-23_11-06

Second, Python is a very good language and it may probably totally take over Ruby in the future (given the 2 languages kind of fit the same space and Python, being simpler is getting way more popular). But Rails is not just about Ruby and Django is not Python. Specially Django is a more naive architecture that force you to assume much more things than the basic Rails stack. The consequence is that it's way easier to have very large startup co-invest on the Rails stack while not so many will co-invest on the Django or Wagtail stack.

C) other considerations about Locomotive

Let me remind you that Locomotive has a remarkable quality and test coverage and many of its issues can hence be fixed. On one side you may think that Locomotive is just Didier.

But you should realize that Locomotive stands on the shoulder of a giant with modules way more mature and tested and popular than an average OCA module. For this you should have in mind the packages it depends on an realize how large is the worldwide investment on this stack https://github.com/locomotivecms/engine/blob/master/Gemfile.lock You don't have such a thing on a Django CMS and will probably never have it! If a Python webstack were to beat Rails in the future, it is unlikely to be Django based I think.

That doesn't invalidate the value of Django or Wagtail for projects with a lot of specific developments. But I think this would be naive to think Wagtail would soon be better than Locomotive for a scalable business offer.

That being said, complementing the E-commerce Shopinvader API with a Wagtail based CMS API could be appealing for some projects with custom requirements. But again I think it is unlikely to create a tool more popular than Liquid templating or even the Odoo website stack itself.

D) consideration about an Odoo website client

That may be something not to hard and interresting to try. In 2014 the Odoo website stack of a joke, just one more "throw shit on the wall to see what sticks" from Odoo SA. But it does stick and eventually given Odoo SA now got its business model right (despite having endangered all of us for years), it is likely they end of with a reasonable website stack for the simple requirements of their SaaS customers. Reusing that stack may work for some projects. Certainly not the silver bullet for projects with very specific requirements or big performance requirements but may eventually lead to a scalable offer too.

kudos if you read to the end!

arthru commented 3 years ago

As ColdCMS is mentionned here, I can add a few things about it.

ColdCMS is based on wagtail and offers to build a static website from a wagtail admin. It has some basic pages defined (landing page, blog, faq, etc...), with templates based on Bulma CSS. It is still in its early life, but at hashbang.coop, we are willing to improve it a lot this year (we received many orders to build websites with it).

Making an ecommerce with ColdCMS is something we have in our TODO list.

@legalsylvain if you are willing to work with ColdCMS or wagtail, we can plan a dev sprint soon. As you, I've been very reluctant to mix languages for any project...

simahawk commented 3 years ago

@rvalyi I come from the CMS world and I've worked on this subject for more than 10yrs. Always python, always OSS. I've worked w/ all kind of templating engines (ZPT, Chameleon, Django tmpl, Jinja, Mako, Genshi, etc as well as JS templates, not to mention QWeb). I've built a lot of whole themes from scratch, even w/ Odoo.

All templating engines have their pros and cons but I'd not choose a CMS because of the templating system. Also, maybe I miss some very important feature, but I fail to see Liquid as a "revolutionary engine". It's yet another templating engine. The very good thing in this ctx comes from wagon, not from Liquid. Wagon is great because you can render the whole website w/out having to plug Locomotive nor Odoo. And THIS is very helpful for web designers.

B) considerations for a scalable CMS offer Here I mean scalable in term of business not what the biggest site you can do. One should not underestimate the value of Liquid and LocomotiveCMS here. There are many other CMS arround. But anyone with e CMS experience shoudl know that a huge part of a CMS project is the cost of the interaction between the web-designers and the website backend. Supporting such a cost is totally acceptable for large projects with very specific requirements. BUT it is not acceptable for standard projects and the CMS stack with no solution for this will simply get no market. Specilly they will loose against the Odoo standard website stack more and more. With the wagon webdeveloppment cycle, Locomotive got this very well and I saw no other CMS with such a thing.

This depends on the scope/scale/grade. For instance, I'd never recommend Locomotive for as an enterprise-level CMS. It's very far from that. Regarding the issue of theming... well, that's common to every single tech out there. There's no magic, there's no silver bullet: sooner or later you'll always have to face the problem of integrating static blocks + dynamic blocks + JS + SSR + whatever the tech and theme requirements imply.

To my knowledge, the best way for designers as well for web devs is to work w/ static themes (this is why I mentioned http://diazo.org). But then, if you want to automate certain things (eg: shared headers/footer) you'll start using some tool to compile template (eg: task runner + template like Jekyll). Then you can serve the static site as you like. Or you could use tools like Gatsby and plug your own tools to retrieve contents from an headless CMS.

Regarding Odoo: I don't care about Odoo core dev in this area (website module is poorly designed for many aspects). I care about the fact the the framework has a great potential for this too. And, as you mentioned "small projects" where you don't have too much budget to build your site/theme, well, like it or not the website builder can address many of those cases. Then, if you deal w/ multi lang, you end up w/ quite some PITA to handle translations, but that's another story :smile:

But let's start from what we have and let's focus on what we can improve in the short/mid term.

I agree w/ the checklist by Stéphane:

customer authentication in Odoo (will happen this year)

the cart cache mechanism can certainly be improved and made easier to use in the front-end and the back-end while keeping the architecture reasonably simple

in general, understand what Shopinvader knowledge is embodied the locomotivecms plugin and see if it can be reduced (towards being able to use a purely "headless" CMS)

some reusable web components that would encapsulate the trickiest parts of the front-end template

The last point will likely ease porting changes from theme to theme or from version to version.

I'd add: get rid of MongoDB and go for PG.

But maybe we should move this to another issue :wink:

bealdav commented 3 years ago

https://github.com/GrappleGQL/gatsby-source-wagtail#readme

rvalyi commented 3 years ago

Hello @simahawk inline answers:

@rvalyi I come from the CMS world and I've worked on this subject for more than 10yrs. Always python, always OSS.

3 for me at Smile but did a few other websites later, several other years with Rails. What I mean is that not everybody coming from the ERP field understands well the web and CMS requirements to be productive.

[...]

All templating engines have their pros and cons but I'd not choose a CMS because of the templating system. Also, maybe I miss some very important feature, but I fail to see Liquid as a "revolutionary engine". It's yet another templating engine. The very good thing in this ctx comes from wagon, not from Liquid. Wagon is great because you can render the whole website w/out having to plug Locomotive nor Odoo. And THIS is very helpful for web designers.

I agree with that and I think I wrote nothing different. That being said, Liquid benefits from a massive investiment from Shopify:

You have performance things: https://github.com/Shopify/liquid-c/graphs/contributors
You have a huge knowledge base: https://www.shopify.com/partners/blog/topics/learning-liquid
You have a huge and growing pool of available web designers because of the success of Shopify. Something not comparable to qweb popularity or many other Python templating languages.

But there is also an other underrated feature: Liquid is non evaling from its conception. For years qweb relied on eval instead and despite safe_eval came there were lots of possible sandbox escalation exploits and probably many more to come. This is important for a multi-tenant scalable offer. Many other Python templating languages are non evaling but one should understand Odoo SA didn't really think about these things when the created qweb...

B) considerations for a scalable CMS offer

This depends on the scope/scale/grade. For instance, I'd never recommend Locomotive for as an enterprise-level CMS.

Neither would I (and I know what are full featured Enterprise CMSs). I mean LocomotiveCMS can be scalable in the sense you could really have many small e-commerces with the same kind of scope as Prestashop or Magento with a productive web design workflow that many other CMS arround like Django/Wagtail/Odoo CMS just don't have and may probably never have. I meant scales in the same sense Shopify has a scalable business.

[...]

Regarding Odoo: I don't care about Odoo core dev in this area (website module is poorly designed for many aspects). I care about the fact the the framework has a great potential for this too. And, as you mentioned "small projects" where you don't have too much budget to build your site/theme, well, like it or not the website builder can address many of those cases.

Yes I agree with that. IMHO the things that currently suck the most on Odoo website technology is it would do tons of non optimized full blown transaction isolation queries to display the dumbest piece of HTML fragments around. They also never got the REST culture in the way they interract with the clients. Odoo SA said they were planing to have specific cursors for the READ queries, so finally 10 years after Tryton they may improve a bit on that.

Now eventually these small e-commerce shops where the guy will create the design himself from a template may probably just pick the native Odoo SA e-commerce instead of Shopinvader. They are unlikely to be the ones who see functional limits of Odoo standad e-commerce nor be afraid about the security implications of the Odoo stack. They are also likely to value the abundance of cheap Odoo plugins from the Odoo appstore over choosing open source modules (specially as they don't code nore have money to hire a developper). So all in all, I'm not so sure if that would be such a big Shopinvader market, not even sure it would pass the Locomotive based one.

But alternatives are a good thing.

bealdav commented 3 years ago

I didn't dig very deep in Wagtail. But still let me point you a few things you may not be aware of. First, just a bit like Locomotive it also depends on a single guy doing 80% of the work

Ok @rvalyi, then if I want to evaluate Odoo, do you advise me to only look into https://github.com/odoo/odoo ? not https://github.com/OCA ? Wagtail benefit of django native plugins mechanism then many extensions in many repos https://github.com/search?p=1&q=wagtail&ref=opensearch&type=Repositories.

bealdav commented 3 years ago

It seems that https://www.jpl.nasa.gov is an headless site

Selection_188

It lead them to get Mars

simahawk commented 3 years ago

If we go headless I'd evaluate tools like https://directus.io/ which seems cool or https://github.com/strapi/strapi or similar. This way you simply provide an admin interface and keep the website/design separated. Up to you what you want to use. Then I'd move all relevant functional features to a vanilla JS lib (eg: invader.orders.get(), invader.cart.get(), etc)

lmignon commented 3 years ago

Hi Simone,

For our future Shopinvader project, we are seriously considering a new stack for the development of the frontend. At first, we imagined offloading Locomotive from the authentication part and implementing a JS component for the cart management. After a discussion with Akretion and the presentation by Thibault and Sebatien of the Jamstack, we imagine going even further by removing Locomotive CMS. The stack could be the following:

External authentication and account management system able to generate JWT tokens
Odoo and ES authentication via JWT token
Jamstack https://jamstack.org/ for page definition and generation (using Nuxtjs https://nuxtjs.org/)
JS component for the shopping cart (allowing the management of the cart even if Odoo is not available)
Headless CMS for the 'static' content.

All this still needs to be analysed and the choice of the headless CMS is an important piece of this puzzle...

Regards,

lmi

On Mon, Mar 29, 2021 at 9:50 AM Simone Orsi @.***> wrote:

If we go headless I'd evaluate tools like https://directus.io/ which seems cool or https://github.com/strapi/strapi or similar. This way you simply provide an admin interface and keep the website/design separated. Up to you what you want to use. Then I'd move all relevant functional features to a vanilla JS lib (eg: invader.orders.get(), invader.cart.get(), etc)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/shopinvader/odoo-shopinvader/issues/883#issuecomment-809155453, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEE2WSS3DUZ22NQUYY4G6TTGA5L7ANCNFSM4XOL4IPA .

bealdav commented 3 years ago

The graal (probably not realistic) could be to have one a cms content managed potentially by different CMS (content generator). As there is a lot of cms, they could be selected if they can share settings (css, etc) to produce a similar headless content.

chooseyourown #illusion #wecandream

simahawk commented 3 years ago

Salut Laurent,

Hi Simone, For our future Shopinvader project, we are seriously considering a new stack for the development of the frontend. At first, we imagined offloading Locomotive from the authentication part and implementing a JS component for the cart management. After a discussion with Akretion and the presentation by Thibault and Sebatien of the Jamstack, we imagine going even further by removing Locomotive CMS. The stack could be the following: External authentication and account management system able to generate JWT tokens Odoo and ES authentication via JWT token Jamstack https://jamstack.org/ for page definition and generation (using Nuxtjs https://nuxtjs.org/) JS component for the shopping cart (allowing the management of the cart even if Odoo is not available) * Headless CMS for the 'static' content. All this still needs to be analysed and the choice of the headless CMS is an important piece of this puzzle... Regards, lmi … On Mon, Mar 29, 2021 at 9:50 AM Simone Orsi @.***> wrote: If we go headless I'd evaluate tools like https://directus.io/ which seems cool or https://github.com/strapi/strapi or similar. This way you simply provide an admin interface and keep the website/design separated. Up to you what you want to use. Then I'd move all relevant functional features to a vanilla JS lib (eg: invader.orders.get(), invader.cart.get(), etc) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#883 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEE2WSS3DUZ22NQUYY4G6TTGA5L7ANCNFSM4XOL4IPA .

Let's talk about it! Would be nice to have a sprint and maybe a preliminary brainstorming call in, say, 1 or 2 months from now

I've talked yesterday w/ @sbidoul and he'll send a proposal.

Mat-moran commented 3 years ago

Hi :smile:

Did you have this preliminary brainstorming?, Any news on this thread?

github-actions[bot] commented 1 year ago

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.