In terms of the React path, there’s another very big question that I’m not sure we have made a concrete decision on (Maikel mentions it above), with these two options:
Option 1: ripping out the entire view layer and the controllers in admin area and replacing it with a large React frontend that’s essentially an entire new app, which sits on a bare API with nothing else left.
Option 2: keeping the view layer and replacing the existing UI components that are based on Angular with new React components that are rendered in the current pages.
These two options would need totally different approaches and would require a lot more thinking in terms of how we will fit either option around these different things like product uplift. Eg: which of these are we aiming for, and exactly how would we fit them around everything else?
On the dogfooding front, I think it actually would be possible to do this “Reactive Rails” thing in a way where the code is re-used across both the Reflex actions and API controller actions, but I’ll have to make a POC for that because approaching it in that way is not implicit in StimulusReflex itself and there are not clear examples of what I mean that are readily available.
Essentially: it’s entirely possible (and in fact preferable) to make a lot of the Reflex controller actions very tightly adhere to REST. That is; each resource would have a corresponding Reflex controller, and all the actions in that controller would look like standard RESTful actions.
These Reflex actions also receive normal Rails params objects as input, exactly as the API controllers would. So sticking to REST, the actual logic and code in each RESTful action would be identical in say Api::VariantController#update and VariantReflex#update apart from the rendering at the end. In this case where every bit of code is identical except the rendering that happens afterwards, it would be very easy to directly share the code across all corresponding RESTful actions so the the same code is used in both places.
Anyway, I would need to make a POC to show an example of this.
Hello!
I am new here, but I found the conversation very interesting. I’ve been building React Apps for the last 5 years, I started with React 0.13 and moved along the way. I have built large apps with millions on LOC and multiple teams working on it (I was on of the main designers/architects of the app) and also small ones with smaller teams. As a new person into the conversation I would argue that if this is just a purely technical choice between two technologies, personal preference should be one consideration. The other things to consider is project goals (scalability, hiring/recruiting, ecosystem, timeline).
If this is a Rails Shop, as I can see from the github repo, the turbolinks and reflex look like a natural progression. I would argue that React provides a lot of benefits, but might not align with the goals.
Do you have a document or wiki that mentions what’s the purpose considering Reflex vs other front-end alternatives?
*I thing React is a great tool, but is not a Panacea. Pick the right tools to solve the right problems.
I won’t reiterate the arguments were brought so far. I want to highlight the con of having to wait until Rails 5.2 which would sit next to the product priorities we went over yesterday night that are currently in play or coming up next. @luisramos0 estimates seem even too optimistic to me.
I’d also like to mention that Stimulus and Github’s architecture was one of the options that came up in the discourse post about the FE tech which the team seemed to discard in favor of React. I don’t know if that was because we didn’t dig deeper or if we now have details we didn’t have back then.
Re dogfooding, I understand your point about reusing the business logic between API and reflex endpoints but the point about dogfooding the API is writing a client for it ourselves. That’s the only way to know if an API is well-designed: confront your decisions from pov of a consumer. If it fits OFN’s needs it’s highly likely it will cover 3rd parties’ needs.
My general opinion is that OFN will benefit from being on the stable side of tech adopting established technologies where the risk of our decisions is more predictable rather than X company or Y startups are using Z. I’d personally stick to the existing tech strategy as there’s more to it than just the particular language or framework we will use.
I am new here too and I have some questions to add to the thoughts here.
First, I think we should be clear of the product priorities and the compromises to it each decision would have. Does choosing StimulusReflect would have any drawbacks in UI/UX? Is it really that faster to develop and is load time that better or would it only be some marginal gains over React?
And tying the UI to the back-end wouldn’t make it even harder to upgrade the existing tech?
That’s a very interesting thread: each of you has many arguments, well presented. It’s a complex decision to make!
My 2 cents :
Generally, separate things in web development is a good idea. Having a complete separate application that runs outside the backend with an API can be an argument : such as for having a functional and up-to-date API ready for 3rd party clients. In the same way, having people dedicated to UI/UX and client-side issues can be a relevant way to work (closeness to the designer and working on a separate design system such as storybook, …).
Disclaimer: I’m a java/html-css fullstack developper who decided to move into a react frontend developper since 3 years ago ; I’m also involved in the recruitment process at OFN.
I want to throw my hat into ring. After much consideration I’m on the side of continuing with the current process and not switching strategy.
I feel this way because:
I want us to be very clearly moving away from a private API and toward a public API in which the FE consumes everything and we dev everything in this approach
I don’t think we can afford to wait until we get to Rails 5.2 to start the Product Uplift work. We need to leverage the investment so far and deliver this feature to our users.
While I like the idea of the additional security of our BE devs being able to do FE dev more readily, I want us to move toward having BE and FE specialisms in the team. I’m ready to take the gamble that we will be able to fund this into the future.
I think I lean more and more this way (continuing with the current process) now as well… @Kirsten posted above about postponing a decision on hiring for another month, but that’s feeling like a long time (and another big pro-for-React/con-for-RRails).
Unless the POC from @Matt-Yorkley is completely stunning (or maybe even if it is), it just seems like the React strategy fits where we are now much better, even if the tech itself isn’t quite as good.
In regards to Rails 5 upgrades, I had a quick look at it today out of interest (#sundayhackday). After resolving 8 or 9 major issues in ~1.5 hours, I can now boot the app in Rails 5, navigate around all the pages, and almost all the functionality seems to be working already (shopfronts, maps, add to cart, bulk edit orders, etc).
I’d estimate completing the Rails 5 upgrade would take 10-15 hours at most, not 1.5 months. That would bring it to roughly a similar ballpark as the Rails 4.2 upgrade, which took ~17 hours.
I’m not that confident either. There’s also code review, discussions will arise, S2s will delay the upgrade even more with our current limited resources, etc.
Just read a comment on Reddit today where a project decided to start replacing all their frontend React code with StimulusReflex. Apparently they removed 30k lines of code and replaced it with 3k lines of code in the first PR…
Interestingly, it seems like the hot new frameworks in the Javascript space (like Pheonix LiveView) are also going back in the complete opposite direction; trying to move away from client-side rendering/processing and back towards solutions where they ultimately rely on server-side HTML rendering as much as possible, partly to avoid the various problems faced by SPAs and partly because it’s obviously the most efficient way of doing things with web servers. They’re also using Websockets more heavily and marveling at how much faster things are compared to the way that the current frameworks are doing things…
So essentially they’ve decided; the best way to handle the transfer of data from user interactions on the client side updating something on the server and sending back a response is through Websockets, and the best way to handle updating things on the client side is to render the HTML on the server and send it back. The Javascript frameworks of tomorrow will probably look like this.
The issue there is; you don’t need a big Javascript frontend library in that case. You need a well thought-out but ultimately very thin layer of Javascript on the client side (which is what the client-side part of StimulusReflex looks like) and a great backend that has nice controllers, nice organisation and rendering of view partials, View Helpers, nicely organised fragment-caching, etc etc… and that’s what Ruby on Rails is.
ok so I know I’m not the target audience here, but I woke up thinking “we just need to make the call and go with React because we NEED to get our API shipshape and fast”. Now I am not so sure.
I think your last experiment with the API ‘Concern’ is a critical thing - I would love to know devs opinions on whether this approach would be adding hideous overhead / complexity, or it might be a direction that a lot of people end up taking to keep the ‘API-first-ness’ of having a separate front-end framework whilst jumping onto the apparent significant advantages of Reactive Rails
A couple of quick questions, apologies if these are dumb questions:
The speed at which everything is working in these pages is partially / significantly due to the simplicity of the app and the data being handled I think? So applying this approach isn’t going to magically speed up all of our pages?
If things like Notifications and messaging are that simple can we just do them? Is there something that makes implementing that little Notifications thing vastly complex within current OFN that means we would need this new setup to do it? and if so WHYYYYYYYY (sobbing - or is it just ‘priorities’?
It seems like some combo of this and an actual API-first approach might get us some big wins very fast. For example, if we had a good Enterprise endpoint that included a few bits of extra info, seems like we could be building pages that work like this very very quickly - getting major UX improvements on our discovery issues without the complex zapier / airtable / extension / wordpress workarounds we’re currently using to do this, and looking at replicating in other places like Canada
Could we start doing some things within different ‘apps’ that appear seamless and as one to the OFN user - like the StartinBlox people talked about, and as I am increasingly coming to understand within the Shopify space? If we could, could some of those new apps be built within new framework without needing to do the whole rails upgrade on the whole app first? i.e. we could do Discovery app that’s like a plug-in? same question goes for
Could we start work on the Product uplift rebuild in Reactive Rails but as a slightly separate but integrated app, that uses the API to CRUD product / variant options? That way we could a) start now, b) consciously and deliberately develop the API to do so which enables c) setting us up for all the other use cases where people want to manage their products and variants from outside OFN e.g. Connection with Odoo
There was a big discussion thread with Luis and others about the API (in the #dev channel in Slack) recently, I’ll summarise a few bits from there:
we already have lots of API endpoints covering a large part of the useful objects in the datamodel
finishing it off a bit and making it usable would not require much dev effort at all (and we could do that at any time)
the only exception to that is the checkout, getting it on the API would probably be a really large and complex bit of work, but rebuilding the admin area in React would not apply any API-first focus there anyway…
So updating the API for certain use-cases like Oodoo integration could just be a standalone bit of work which isn’t necessarily tied to everything else.
The speed at which everything is working in these pages is partially / significantly due to the simplicity of the app and the data being handled I think?
The other framework (LiveView) that’s now using the same strategy is hailing it as a whole new thing called “real-time apps”, where the updates are so much faster you don’t need loading spinners or placeholders any more. So to some extent; yes this example is quick because the app isn’t huge or complex, but the idea is you can get similar results in production, especially combined with some basic optimisations like Fragment caching and Russian-Doll caching, and in a lot of cases only a small bit of the page is re-rendered instead of the entire thing. The time between the user clicking something and the page being updated can be somewhere in the region of 10-50 milliseconds.
If things like Notifications and messaging are that simple can we just do them?
Live-chat and some of the instant-feedback stuff would need something like StimulsReflex, but a simple version of a notifications feature would be incredibly easy, yeah.
if we had a good Enterprise endpoint that included a few bits of extra info, seems like we could be building pages that work like this very very quickly
Adding an endpoint that returns enterprises with a few bits of data like that page requires is probably XS T-shirt size and could be done at any time. It’s not complex, maybe an hour or so of work including writing full spec coverage. In theory there’s nothing stopping us from doing that today, testing and merging it next week and including it in the next release…
On the upgrading front, I think even even if we go with React we’d get a lot of value from upgrading to Rails 5 (especially if it’s not very difficult). It added various things like enhanced concurrency handling (which is a problem we have currently) and additional support for using Rails as an API backend as well as support for global ID which enables some nice security-related enhancements when dealing with external clients.
Alreeet, thanks @Matt-Yorkley for such detailed explorations of Reactive Rails.
I must admit it came across to me as more of a sales pitch and less of a pragmatic investigation. I would have liked to know the things that will be hard.
I am feeling an increasing sense of urgency to move forward on this, make a decision and approach our candidates with something more concrete. So, without further ado I’d like to propose:
A Process for Moving Forward
In this community we tend to use consensus with our decisions. I hope we can come to a point in which the people most impacted by this decision can all agree. So I propose that these people reply to this post with:
Your Opening Position: Reactive Rails or React. You must choose!
2-3 sentences explaining your choice.
This decision impacts a lot of people so I would like to invite anyone with a strong view, experience or stake in the decision to comment. Specifically, however, we need to hear from: @sauloperez @apb @Matt-Yorkley (I feel like we know it, but for completeness) @maikel (though I’m aware you’ve been less involved recently) @Rachel @luisramos0 (though you now have less stake your insight is invaluable)
If you feel your name should be in this list and isn’t, I do apologise! I’ve put my ultimately pragmatic hat on. Please do add your response too
Once the above people have responded we will be in a stronger place to make a decision. I hope we can respond to this in the next couple of days
- or is it just ‘priorities’?
