Whichever option we choose, we will have to explicitly prioritize the API if we want it to happen soon… I’d say it’s several months to over a year before that rewrite is complete
Agreed. Rebuilding the whole admin area in React will take a long time, and will mostly focus on the endpoints we already have. Even if we go with React, I think it would make sense to prioritise work that improves the API for external clients being done way before the “React rebuild” is likely to be finished.
Kirsten’s example of the Enterprise endpoint is an interesting one. I had another look, and I think for the that case we’d want to use the
Api::ShopsController (which already exists) and the
Api::EnterpriseShopfrontSerializer (which already exists and has specs) and just add an index action, which would be 5 or 6 lines of code, so I’d downgrade my previous 1-2 hour estimate there to around 30 minutes (specs included).
With cases like a potential Odoo integration it might be that the requirements look different to the requirements of our app, in which case we might need some separate endpoints that we ultimately would not be consuming ourselves. And we’d still need to prioritise the work separately. We’d need to see the details of the use-case first though.
ok, I disagree with a few points and I am sorry this can have an impact on the vision/growth of the OFN platform but I think it’s good news you guys agree!!!
From a product perspective I am now wondering if there’s enough value in the REST API, maybe we should consider dropping the REST API and just build the DFC one? Will DFC be a blocker for some of the api consumers? Maybe a question to consider in another thread.
Ok looks like everyone’s hat is in the ring.
The weight seems to be sitting with Reactive Rails. Andy, Matt and Maikel landing this way.
Abstain from Rachel. Luis, Pau and myself all giving the reason that we want to dogfood our own API. However Luis and myself won’t be building this thing so carry less weight.
Would anyone like to reconsider their vote? Would anyone be willing to put forward a line that brings us closer to consensus?
Can we make a product decision that new features must be served over the API as well?
Or a product investment of x% time to API development?
Does anyone have a proposal that might help us more toward consensus?
We can do this! Go reactive!
Maybe in some cases, but for example checkout with stripeSCA would be very complicated. API will fall behind in terms of features naturally with this approach.
I like this and agree, we could have an agreed product decision that makes API dev a priority for a agreed part of the yearly budget every year.
So in terms of approaching Frontend UX for the app in general, I think this “Reactive Rails” thing is a much better direction than a React rewrite.
But I’m not arguing against the API; if we made “make the API great” our primary overarching strategic goal for 2021 and brought in new rules like making any new features available on the API (wherever possible) I would honestly be 110% behind that.
The idea that we can’t work on the API because we don’t prioritise it seems crazy to me. Can we just prioritise it and do it?
Can we move these discussions here:
Toward a roadmap for our API
The questions listed by @lin_d_hop there will need answers, which can then lead to a proposal for instance managers. Yes it sounds boring, and maybe even feel like a step back from the API consensus we have reached here, but I suspect half of our instance managers don’t know exactly what an API is, and for most of them it will feel like something invisible they cannot do anything with. We need to come up with clear definitions and help everyone understand why it is important. Kind of onboarding the community in that vision. Thus the team will be empowered to move forward.
Let’s organize a team to work on a proposal? Having a clear strategy on our API will feel really good
It feels like we’re moving closer to a consensus if we make some concrete steps towards an API strategy. I’m happy to put my hand up to be on the team to do a spike and set milestones/deadlines on it.
I’d also like to hear again from @sauloperez on whether he can live with this direction, if that’s what we decide.
We can move this conversation to that other API post once we have a consensus on this decision.
This conversation is inextricably linked. Our API strategy will be vastly different based on the outcome of this decision. So I think it makes sense for people to raise the API discussion in this thread. Since we try to work on consensus we just need to hear that Pau is comfortable with the decision. Note - not everyone has to like this decision but everyone has to be able to live with it.
Once this thread has consensus then…
We will move the conversation there and start talking about an API strategy.
Actually maybe I take back my last comment…
Should we make a decision whether or not to dogfood our API first? And then make this decision?
Chicken and egg, I know…
But @Rachel, is that what you meant when you were encouraging us to move to the API post?
I know I’m being noisy on this thread…
I have realised that I’ve made a mistake in working toward this decision from this angle. But I’m glad the conversation is moving.
At the time I thought this was a decision about which front end framework to use. I didn’t realise that this decision actually defines whether or not we dogfood our API between FE and BE. I should have taken more time to fully understand the implications when various people said ‘oh yeah the API will be fine’ along this discussion. I did not hear clearly that this enormous strategic decision was being made until after Matt’s PoC.
In hindsight I realise that the decision about whether to use our own API between FE and BE is a critical strategic decision that involves more than just technical knowledge of a framework. It requires a huge understanding of the product landscape, of the challenges in current use of the platform, or the direction we are going.
I also suggest that, in the decision-making style of Jeff Bazos, this is a Type 2 decision - a one-way door. I do not believe that it will be easy to turn around from this. I think we really really need to make the right decision here.
What we know now
- There is strong developer motivation to move to Reactive Rails
- Using Reactive Rails means the JSON API becomes a side project
Following on from this it is clear we have some big decisions to make regarding the strategic direction of our app and API.
So, following @rachel’s ever wise advice, I agree we should move this conversations to Toward a roadmap for our API.
Yes, I can live with that. One way or another we’ll do all the best we can for the project.
No, Luis has a lot of wisdom to share and so do you. If only devs decided, we would have an app that works perfectly for 1% of customers.
Or another main project. In the API discussion, we were wondering if we needed two APIs, one REST API for our dog-fooding and one DFC API. As Luis mentioned earlier, this is also an opportunity to just have a DFC API for the public while our application doesn’t need an API internally and is much simpler to develop. I think that going with Reactive Rails makes developing the API easier because we don’t have to consider code changes in our own application. Fewer stakeholders -> simpler decision making.
Woke up thinking about this decision, don’t think I was quite dreaming about it but not far off. Big decisions are really hard!
I think I am leaning strongly to Reactive Rails because
- speed is a really big thing - we have been so slow for so long and to be able to actually start caning through our backlog and significantly simplifying our code while doing so seems like a major plus, particularly over a massive rebuild in a new framework
- Network 2.0 - if speed and focus lets us actually get Network happening a year earlier than doing a whole React rebuild would then this is really BIG
- Re. the monolith - I still don’t understand why we can’t have a bit of both. If we were / are calling someone else’s API in our app we could still do this with a Reactive Rails app? We must be able to - we use Stripe’s API etc. So surely we could choose to start breaking up the monolith and doing things in a modular way for new things and choose to use our own API to do this in some cases?
- I’m sensing momentum around Project API that is in no way tied to React and the product uplift / network rebuild, which is really exciting. I agree we can choose to prioritise this. And if we can be pumping through other stuff faster we’ll get more of it done sooner as well
- The balance between @luisramos0 very valid and persuasive vision re. consuming our own API and @Matt-Yorkley’s tendency to transformative genius leaps is very difficult! I have this gut sense that Matt may be ‘future-sensing’ and if we were to embark on a massive React rebuild at this point we would kick ourselves hard in a year or two. Whereas Reactive Rails will just speed us up and give us a whole lot of stuff quite quickly, and we build a shit-hot API at the same time, and if we decide that we really want to start building new things separately in React using our API later we still can
So I’ve had a look at this: Home · Matt-Yorkley/reactive-rails Wiki · GitHub
and had general read of the thread as well as understanding the related API discussion and I just want to say something that I think I’ve said before in other threads.
Generally, from Design’s POV (both UX, UI, Visual, interaction etc.) I’m only concerned if we choose a framework that has a rigid and prescriptive UI visual design and it takes FE dev a long time to create new custom components that might not already exist in the framework and also if it’s very hard to re-style components we do want to use to look like OFN and not whatever framework it is.
I’ve worked on UI migration projects before where design basically was only allowed to build UX/pages of an app with only ‘off the shelf’ components and I want to avoid that scenario very strongly.
I’m fine with a framework where custom components need to be built, but they should ideally not be as hard, or harder to build in the chosen framework than if we build a vanilla CSS/Style library.
just for my techno-non-understanding @Erioldoesdesign is that a point in favour of either framework over the other, a general point, or something we would need to be aware of in how we implement either/both?
General comment on ‘frameworks’ in general and an ‘ask’ of the dev folks to notice and communicate if a framework has a ‘restrictive’ set of components and complicated path for customisation of CSS/Styles.
I for sure, can’t look at a framework and know the above due to not understanding the ‘guts’ of most frameworks so I’ll be relying on devs to choose and be aware of the design need
It would be really helpful to know your views on this. My BIG fear with Reactive Rails is that we win a few things and get really stuck later with specific requirements. Your POC was an awesome sales pitch for the tool that you wanted, but it left me with a lot of questions. As a senior dev it would be marvellous to know your insights on the risks with Reactive Rails. Under what scenarios would it slow us down later? If your answer is “it won’t” then I implore you to think harder
It might be helpful to think of frameworks in the same way we can now view Spree. It made things faster at the start but we’ve now spent years decoupling from Spree as it was significantly holding us back. Reread Eriol’s comments with this analogy in mind
Also, tech folks, I’m aware Spree and Reactive Rails it is an imperfect comparison. But it is not a useless one so please forgive it.
communicate if a framework has a ‘restrictive’ set of components and complicated path for customisation of CSS/Styles
It’s related to previous discussions in this thread: Backoffice Product List table user interface uplift - #11 by Matt-Yorkley
With Reactive Rails we wouldn’t be tied in to any specific component framework, but with React there are various frameworks that could potentially be used, and some of them could end up being restrictive and problematic, so we would have to scutinise those choices very carefully.
I think me and @Erioldoesdesign are in agreement on this point
A couple more indecisive thoughts for the pondering:
- In Australia, we are looking at Shopify, implementing a custom e-commerce and wondering how to connect it with OFN. Shopify uses React for extensions which means that using React has more cross-pollination opportunities in that space.
- Facebook is probably React’s biggest user but I constantly hear complaints from my partner about how buggy their user interface is. Long elaborated posts get lost, buttons stop working and sometimes the UI is just not showing stuff that should be there. React may suffer some side-effects of complexity which Facebook can’t resolve appropriately.
I’m still favouring Reactive Rails over React.
I think I am through the API problem, we can build it on the side. I am now convinced it’s a viable approach.
I am now more worried about Stimulus Reflex being a new framework, its v1 is from 2018.
I have read about some adaptations (we need an extra gem) to make it work with rails 5.2. This is initially a challenge because we need to get to rails 5 (probably 5.2, something to check) before we start using it. But it’s an advantage from the durability perspective, if it works today with rails 6 it means it will be ok at least until rails 6 is maintained. 2021 will probably bring Rails 6.2.
2022 can bring rails 7 and, if in two years time stimulus is no longer maintained, that will put us in trouble already in 2023/2024 where rails 7 upgrade would be difficult.
But this is unlikely, if in 2022 there is a rails 7 out, only 2 years from now, there will most probably be someone maintaining stimulus reflex and making it work with rails 7. This means that we would be ok until rails 7 is supported which will get us at least another 2 years, something like 2026.
I think it’s safe to say, even if the framework is new, we can get away with 5 years on it for sure. The question is about after that. In 5 years time something like stimulus can completely fade away. And 5 years is not a lot of time. React has a big advantage here, because it doesnt depend on rails and because it’s so popular it will be around for sure in 5 years time.
I thought this reflection would be useful. I am not so nervous about stimulus as I was before I wrote this post