Is there any good and up to date documentation for SSR with Spartacus (1.5) for SAP COMMERCE?
I know this:
https://sap.github.io/cloud-commerce-spartacus-storefront-docs/server-side-rendering-in-spartacus/
https://enable.cx.sap.com/media/SpartacusA+SSR+Deep+Dive+-+SAP+Commerce+Cloud/1_6jbx5p6e
But maybe not everything is up to date in this documentation for current Spartacus release 1.5.
What could be wrong or missing if there is at least something generated with SSR but still things like
<header class=""><cx-page-layout section="header" class="header"><!----><!----><!----></cx-page-layout><cx-page-layout section="navigation" class="navigation"><!----><!----><!----></cx-page-layout></header>
are in DOM that are not rendering without java script?
Based on our experience, we are using these sources of information and technical approaches during project implementation:
Theory
https://angular.io/guide/universal (you can feel free to use Angular official documentation as a primary source, cuz Spartacus uses Angular OOTB features to make it works)
https://sap.github.io/spartacus-docs/server-side-rendering-in-spartacus/
https://enable.cx.sap.com/tag/tagid/spartacus (SSR related videos)
Practical approaches
You should observe and analyze console output during starting your application in Node.js
You can use SSR configuration from example Storefront application (https://github.com/SAP/spartacus/tree/develop/projects/storefrontapp) like a starting point, cuz OOTB SSR works like a charm
Related
We are building a marketplace using angular and we want to integrate Adyen payments. Googling for 'Adyen angular' or 'Adyen SPA' or even 'Adyen react' doesn't bring any useful results. NO results whatsoever.
Therefore I am left wondering, why the whole world (including Adyen docs) is not talking about integrating Adyen into a SPA.
It doesn't seem to be more vulnerable to network security attacks to me. At least I can't think of any reasons for that.
Please help me to understand, what I am missing out.
As madesch mentioned, integrating in a SPA shouldn't be too far from other kinds of integrations. Are you having issues with something in particular?
Here can see an integration with Vue, one with React and even one with React Hooks.
The card fields are not being loaded because I'm not using a real originKey, but it should give you an idea about how to do the integration.
I hope it helps!
It seems that I overestimated Adyen popularity and in reality, the truth is that it is just not popular enough to have gotten attention from SPA community. :(
it seems like originKey is deprecated, the current recommendation is to use Web DropIn. But this requires using a server component, as you don't want to expose your API key, right?
So if you don't want to use a deprecated API, you must always add a server component to your stack. A pure SPA does not seem to be possible using current APIs, it seems.
There are now few options available:
Angular support
Vue support
React support
All examples are based on the Web Drop-in approach which renders a checkout component with the supported/requested payment methods.
A basic explanation of the workflow is provided here.
I was enthusiast using Angular2 with Meteor, so I started a project with ng2 and Meteor. But more and more I am asking questions like:
Is ng2 deprecated router the way to go ?
What is the purpose to use ngForm validation if I use collection2 and autoform to do most of my form validation.
What are the benefits of ng2 architecture vs Blaze ?
So at the end, I am not even sure of why I am using ng2. There is not that much recent and relevant discussions on the topic. Is that the question that is already answered, obvious or just not so relevant ?
What are the pros/cons of using Angular 2 versus using Blaze ?
Blaze was raised with Meteor and is probably linked to his success. And ng2 could be as famous as ng1.
To be used in serious projects, which one is going to be 'more maintained and last longer' ?
Regards
PS: Also looking at https://builtwithmeteor.com, Blaze appears to be used more.
The Angular 2 router is deprecated but it's still the only router available to use at the moment.
In the future versions of Angular 2, a new router will be available.
So right now- the deprecated router should be used, and I think that it has all the features that you need from a Router.
You can choose to do the validations of the fields as you like.
Personally, I think that validation should occur in both client and server, so Angular 2 take care of the validations that needed to check in the UI and give feedback in the UI, and the Meteor validations should occur in server side and validate things like duplicates, data logic and such, along with fields validations that done by SimpleSchema.
I think that Angular 2 at the moment provides a better solution for client side development - much of it is because of the decorators that in use, the code is much clearer and easy to understand.
Also, Angular 2 is more that UI binding (which Blaze is...) and give you Dependency Injection, Router, Services and more features that usually required in the UI (in Blaze you need to use external packages for each one of these features).
Keep in mind that few months ago, Meteor team declared that UI developers should consider using another client side framework, and consider migrating from Blaze (they recommended Angular 2 / Angular with angular-meteor.com or React).
If you already have Blaze application, I think that you should consider migrating to Angular 2.
The Angular2-Meteor (www.angular-meteor.com) team is working right now on a full step-by-step tutorial for coexistence and migrating Blaze application to Angular 2.
Just started to discover meteor. created app with DiscoverMeteor book, but misunderstood many moments. then read Your first meteor application and Your first meteor application books. Realized that Todos example is really too simple to cover many important things. And only after that I found the official guide on Meteor.com! now reading about all these complex (for my opinion) things. and have 2 questions:
What router should I prefer to use? I want to create fast app with lots of data loading from the server. Found information that Iron router is deprecated, and Flow router is recommended nowadays, but also found that flow router can not route on server, only on client. And that exactly client routing is the reason why for example soundcloud is really slow. So that is the question - I know nothing about server/client routing, but want to make right decision for the future project.
What ui-framework to use? I read that blaze is easy to start, but react js is really powerful. So: is Blaze enough for serious project (like a popular blog)? Or do I have to learn react js in order not to rewrite code in the future?
I am working with Meteor 1.3.2.4, which is latest in market and believe, you don't have to do anything out of the box to go with experimental UI-Frameworks and stuff.
Blaze template which is handlebars based implementation is best.
Blaze template is very well glued with Socket.io, futures and DDP implementation for cutting edge implementation for asynchronous and reactive behaviour on UI.
Blaze is really good for cumbersome, heavy data websites as well. If you have any doubt, i can skype and show you what i have implemented in just 2 days on development using everything given by Meteor.
React.js, Koa.js (re-written Express framework), express etc are very good and powerful, but I think implementing it at initial level of your grasp is overkill. Go with Blaze first.
There are hundered sitting and developing Meteor.js just for you to be comfortable. I am not at all biased, I am giving you my open opinion.
I worked with Laravel 5.2, Play framework, MEAN.io, DJango in past, but believe there is nothing like pure Meteor js with there own packages. There are many videos on youtube like Meteor nights and stuff where you can find the developers from all around the world developing huge stuff just using stuff given by Meteor js.
For routing flow-router is good, even iron:router is awesome and easily gettable.
This video can guide you very well.
Flow Router is the recommended router by the official Meteor Guide. It's also the popular choice these days, and for a reason: it's a high quality router implementation.
As for MVC, it's really like choosing a religion. React has a huge community, possibly a bright future, and it's not Meteor-only unlike Blaze. But some folks find Blaze templates nicer than JSX files. I think it's easier to get help on StackOverflow if you pick React, but Blaze might be easier to get started.
Maybe this post helps a bit: How to set up React with Meteor?
I am evaluating Meteor as an alternative to developing real-time capabilities using socket.io and it looks like awesome framework for single page real-time apps. It is great time saver that enables developer focusing on the business logic of the app, rather than writing boilerplate code. However, I find it still pre-mature for a medium size app with multiple pages/routings and REST api. Plus, number of features like i18n are still not available which requires some time investment to develop by myself.
I think that it would be great if I could combine Meteor and Express and use Meteor in use cases where it really shines.
Is it possible to develop an app using standard Express/Mongo stack and use Meteor for only specific part of the app where I need real time collaboration?
For example, can I share a session between Express/Connect and Meteor?
Thanks!
This does not directly answer your question, but I thought I'd throw it out there:
You should check out the community packages on atmosphere. Specifically, I'd recommend having a look at iron-router and i18n (I'll note I have not used the latter).
I've built a large production app that uses iron-router and it's running smoothly. You may also be able to use its server-side-routing capabilities to implement your REST api.
I plan to build a database management system using Grails as the main framework. On the client side, I'm thinking whether to use dojo or flex to make a nice front end.
Could some experts here enlighten me on the pros and cons of choosing either, or both?
or any other options?
thanks!
I tried using Dojo in a project and even brought a few books. And while Dojo Looks good I found that JQuery and JQuery-UI was a lot lighter and worked faster.
This is just my opinion and it may help you.
From the description of the flex plugin at http://www.grails.org/Flex+Plugin
"This plugin was created as an experiment to prove that it's possible to communicate from Flex to Grails services without any configuration in Flex. There
is no plan to add functionality or whatsoever. It's not sure if the plugin works in production mode as it is only tested in development mode. This plugin
can be seen as an example on how to integrate Flex and Grails with Convention over Configuration in mind."
There is no scaffolding generation for flex, see this bug
Another disadvantage of Flex is its lack of accessibility for screen reader users with the default configuration. There is some work being done to address this but it isn't publically available yet.
I don't have experience with DOJO but according to this link if you use the standard Grails Ajax tags you should be able to switch libraries with out to much trouble and won't be tied to Dojo. For fancy UI stuff such as tabbed interfaces and data tables I've found GrailsUI works well for me. A demo project showing its features can be found at http://code.google.com/p/guidemo/ although you'll have to check the code out to run it.
I am developing an information-management application with Dojo 1.9.2 and Grails 2.3.9 (lots of simle/complex forms, listing screens...etc). The application has a single-page interface as well (a workspace) which was the primary reason for a heavy JavaScript library.
Overall, Dojo is fairly suitable for this kind of workload and I haven't bumped into any show-stoppers yet.
I needed to do a lot of work on integrating the Dojox DataGrid into the application (extending QueryReadStore to fit with Grails better...etc) and a set of custom widget extensions (e.g. a real, working AutoComplete).
After this larger, initial integration work is done, you can expect a fairly smooth ride.