This discussion thread points some not addressed issues relevant in RWJS integration future plans. If such plans cater to companies that develop software programs which facilitate the management of business processes that deal with money.
The concerns raised below are of equal importance to RWJS management, development team and current as well as future customers.
Stripe, Inc. is an Irish-American financial services and software as a service company dual-headquartered in San Francisco, United States and Dublin, Ireland. The company primarily offers payment processing software and application programming interfaces for e-commerce websites and mobile applications.
Redwood integration with Stripe appears in these RW discourse threads:
@chrisvdm is the project lead for all three projects and @dom is her link to RedwoodJS framework team. I (@adriatic) responded to the invitation to help finish the item 3 (Redwood + Stripe example store ). In the last few weeks since I started to find out what Stripe really is, got me very excited (I am not the only one )
The first issue I encountered in item 3 (Redwood + Stripe example store ) is Secure Cart defined as “Cart works but needs to be managed on the backend to avoid security risks”. This assessment does not bode well with several properties of Stripe framework listed below:
Security at Stripe directly address the question: should we use the RedwoodJS security, Stripe security - or both. The answer appears to be both and that approach requires a pretty deep discussion that has not even started yet.
We need to discuss the “division of work” between RedwoodJS components and Stripe components, not just from the ease of such integration but also because the above mentioned security issues. In this context, the following Stripe components play a major role
Stripe apps - Embed custom user experiences directly in the Stripe Dashboard and orchestrate the Stripe API.
At the moment, I do not know the management team expectation from RW-Stripe integration and even less RW customers interest. We may soon find that based on the reactions to this post.
Is the ask here how to mock different component states/variants in the Stripe example that we are not already? If so, do you have a specific example you want help with implementing and can point me in the direction of the code or an issue in GitHub, or some other reference that describes what you are looking to do with Storybook?
Let me explain my thought: both RedwoodJS app integrated with Stripe and RedwoodJS app integrated with Storybook share the same problem - how to make them resolve the possible security conflicts. The situation I am describing in Redwood-Stripe integration - currently unresolved issues is particularly complicated because Stripe implements strongest possible security anywhere (because it handles financial transactions). This security takes over whenever any Stripe code gets invoked from the RW app. This does not mean that the RW app can just lean on Stripe and use Stripe’s security, because RW app needs to be able to protect its own code with authentication and authorization coverage (example: Login case).
RW Security implementation (see Security | RedwoodJS Docs)
currently does not handle this situation where two different security expectations co-exist.
I am still not quite seeing a connection between that topic and this one.
They way I understand it:
Stripe is a payment platform.
Storybook is a tool to aid in front end component design.
They solve different problem domains, and as such, their integrations have little to do with each other.
In the generic sense, that other topic was asking if there are existing patterns in Storybook to easily mock out a component whose state is managed through the Context API. It just so happened they used useAuth / AuthContext in their question.
Is there a specific component state in the Redwood Stripe example using Storybook that you are finding to be difficult to represent?
Since I failed to make it clear at the very beginning and failed to explain in the second attempt, I am either a very poor communicator, or I misunderstood the post Pattern for making Storybook and useAuth play nice.
Third time should work though: had I named my article making RedwoodJS and Stripe play nice, the analogy between these two articles would be more obvious. In Storybook and RW app you seem to be dealing with interaction between RW app authentication and mocking (needed to Storybook). RW app and Stripe we have a pretty strong case of “impedance mismatch” between RW concept of security and Stripe concept of security. In a Redwood app integrated with Stripe (use the case where Redwood app uses Stripe API as the most general case), the flow goes from RW to Strapi and back many times a second, and I am not sure that I understand the cases where RW app compromises Strapi.
I tried to discuss this with Stripe support and managed to get into their second level. At the moment still waiting …
Hi @adriatic - apologies, there still seems to be a bit of an “impedance mismatch” here. At this time I have nothing else to comment around Redwood’s Storybook integration; other than to reiterate that if there is a specific component state in Storybook that we are finding to be difficult to represent in the context of the Stripe example app, please let me know and I will be happy to take a look.
If we are not on the same page still I did not understand the RedwoodJS-Storybook issue. I connected with with my post after seeing the phrase Storybook and mocking out the useAuth hook .
)
