"Reactive Rails"

Tech
41

Opening Position: React
It is clear from Matts videos that using Reative Rails means that we develop backend code for FE calls. This means that OFN will not be dogfooding its API between FE and BE. This, to me, is a dealbreaker. It reduces our ability to develop FE and BE in parallel. We are literally losing funding and users DAILY because our API can’t support what they need. I don’t want our API to be a side project to the app.

On top, the requirement to upgrade to Rails 5 first means LONGER without users seeing big changes. People now pay a lot of money to use OFN and they haven’t seen it move much in a long time. Of course we need to update… but we’ve just spent YEARS telling users the main thing we’re doing is tech debt. It would be so nice to actually show off our skills to our users a little :slight_smile:

42

Opening Position: React

Reactive Rails does seem quicker in terms of dev time but without any extra argument, I still think making the API the core of our product is the path forward, and deviating from it will always make it a side-product. Again, I believe that to properly dogfood it you need to write the API client yourself and feel the pain (or not) as a consumer.

It may take more effort to gradually rewrite our FE in React but although there might be new and more lightweight approaches is 100% a safe bet that lets us start working on the product catalog uplift right away.

To me, it’s what best fits all the constraints and variables at play, which go way beyond frameworks.

43

Abstaining - trusting the team :slight_smile:

I’m deeply sorry but I don’t think I can give or should have an opinion on Reactive Rails vs React.

Maybe my contribution could be to say that we need to embrace that we can do a mistake with this decision and it’s okay?
I’m super happy to see that we are trying consensus here and therefore I would like to bring up an important rule: if anyone feels they cannot live with the decision the group takes, they should raise their concerns now.
Failing together in 6 months and try something new again is not something we should be afraid of. If we are all aligned today, it will be super easy to work out solutions in the future. So we just really need to trust ourselves here and believe that we will take the best decision we can take now. No regrets :slight_smile:
Whatever the group decision, I’m committed to help the best I can.

Some thoughts on others topics - feel free to forget them as again I do have limited knowledge:

That’s a bit untrue :wink: . And the Rails upgrade are not the only stuffs that are keeping us busy. For the small team we have we are moving super fast. Also I don’t think people pay a lot of money for a software the size of OFN… but that’s a completely different topic :grimacing: My main point was that we musn’t forget that reactive Rails or not, we will need to kick off Rails 5 in 2021. Security-wise we cannot afford to stay on an unmaintained version of Rails anymore… In the same spirit:

Backoffice uplift is cool, network is way cooler :sunglasses: : . It’s going to be the most exiting feature we ever dreamt of. I’m not sure we will want to develop Network in Rails 4.2 and then have to migrate it to Rails 5… I foresee tester suicide :slight_smile: Again a topic for another discussion, I really feel we are mixing thousands of topics into one, which makes taking a decision super hard :face_with_head_bandage:

@lin_d_hop can you be more specific here? This is a super interesting statement. Maybe we should move this to the API discussion. I thought we were only looking to dogfood our API first, and if that’s the case I struggle to understand the immediate business opportunities it means.

Thanks all! I’m really learning a lot from those discussions :pray:

3 Likes
44

Hello! @Matt-Yorkley brilliant work on demoing the framework with the videos :clap: :clap: I like it and fully understand your excitement. I think it’s a valid approach.
If I try really hard to revert my opinion I bump into one single point which is: if we go reactive rails the data needs to be loaded in rails, including for example pagination. So it’s really zero usage of the API. The API controllers would then not be used by the app at all and but they would have to call code that is used in other controllers, services and models. It’s doable. Zero dogfooding also means zero api features for free as part of normal dev process. So all work on API would have to be prioritized like any other features. It never happens.
My technical opinion is that reactive rails is a valid approach and can actually accelerate and simplify development. This is debatable because separating/specializing FE makes projects like the recent Mobile Ready go much faster because you have true FE devs in the team. With reactive we would keep being a rails shop with mostly BE devs and some fullstacks. It’s not the most important point in this discussion.
Strategically, I think it’s a bad decision. OFN platform - ecosystem of interconnected tools - API first. Think 2025 with OFN being a nice tool still without a workable API.
I think this decision is important for the devs that will have to work with the framework, but it’s much more than that, it’s an important product/biz decision for the point above, an API based product strategy. Are we aiming to be a nice tool or to be a platform of interconnected apps? If we dont envision/plan this, it will not happen.

I am not voting React, I am voting whatever technology you want on top of an API. It doesnt even need to be rendered in the browser. At FF where I worked, the setup with react+api had the react layer running almost entirely on frontend servers, not browsers. But relying on APIs for the data.

2 Likes
45

Opening Position: Reactive Rails

I looked at the api branch on the repository that @Matt-Yorkley set up (thanks Matt :tada:). I think that it looks like a solid (preferable, even) approach to extract any business logic to a concern, and leave it to the controllers/reflex to determine how they render the data. This leaves them very skinny, boilerplate even, and makes it easy to keep things nice and clean. So after being pretty much ready 22 days ago to just make the call to go with React (much like @Kirsten yesterday), I’m now declaring for Reactive Rails, for three main reasons.

  1. We should de-couple this decision from the decision to prioritize the API.

Whichever option we choose, we will have to explicitly prioritize the API if we want it to happen soon. Let’s say we go with React. The first project is the Product Uplift which I’d say is realistically months away from being deployed. So the only API work we’d be forcing ourselves to do in those few months by going with React (in other words, the only API work we get “for free”) would be the endpoints to support the Product Uplift work, which is a small percentage of the endpoints overall. As we continue rewriting the front end in React, we’ll eventually be “forced” to do more and more endpoints, but I’d say it’s several months to over a year before that rewrite is complete. We need the full API way, way before then; therefore, we need to prioritize it separately; therefore, we don’t really get it “for free” by going with React.

  1. The needs of our API consumers are not the same as the needs of the web client.

I understand wanting to dogfood your own API, but designing a good API means thinking about the general case, not the specific case of your own web application. I would hope/assume that not too many consumers of the API are just looking to make a clone of the front end, but instead have some other, probably slightly different requirements. The conclusion is the same, that the API should be prioritized independently and not thought of as “this thing we’re building mainly to support our own React frontend”.

  1. It makes us and the code base leaner.

I would love love love it if we could hire someone to focus on general front end development. Hiring someone who’s very specifically focused on/skilled in React feels wasteful if we can instead use a tool that we already understand and achieve the same thing with less code to maintain, and as a bonus, free up that person to work on more impactful features. This might be the person we’ve already identified through the recruitment process and we would just be refocusing/redefining what they’d be doing.

Some assorted closing thoughts:

I definitely recognize that there’s a lot of strong feelings about this, and also a lot of context that I’m not fully aware of. I’m especially wanting to hear more about @lin_d_hop’s statement that we’re losing funding/users daily because the API can’t support them, yet according to Luis, the API work “never happens”, yet according to Matt, it’s a pretty small amount of work for everything but checkout. Is there some underlying blocker, or just a case of priorities/needing to JFDI? A question for another place though.

I would make the joke about writing you a shorter letter if I had more time, but that’s not the issue; I just couldn’t find a good way to leave any of these points out! To sort of honor the original request for 2-3 sentences, just read the bold parts :wink:

1 Like
46

Opening Position: Reactive Rails

But I would also be happy with React. We have two good solutions and either way we will be using a good technology. Both are mainly concerned with rendering HTML which is not a big feature of our application. Unless there is a veto somewhere, I’m happy with a simple majority decision.

My reasons to prefer Reactive Rails are pretty much the same as Andy’s:

We need to prioritise the API

We do get some API for free by dog-fooding. But we got that already. For example, we can query all variants that are in a shop front via the API, including stock levels. We need more than that free part though. An Australian shop would like to know when items in the shop reach zero stock. But our API endpoint is only listing items that are still in stock. It’s useless in this case and that won’t change with React. A new API endpoint can be written in a few hours.

Separating the concerns API and JS-framework let’s us move quicker

We mixed the JS framework upgrade decision with our API goals and then mixed that with our hiring. That’s why it became so complex and hard. We need front-end devs and we need API devs. They can be the same or separate, depending on what we find and need at the time. Let’s not block our decisions by making things dependent on each other. Unblock the pipe by progressing independently in the same direction.

Switching to Reactive Rails seems simpler and faster

I can’t make a hard claim on this. But the architecture looks so much simpler and it looks like it would save us a lot of maintenance work in the future. If it’s right that this is reducing complexity, it’s the best long-term strategy. And on top of that it also looks like it can be implemented very quickly. We need Rails 5 anyway. That’s not a blocker for me. Especially if we prioritise API which is independent of any JS framework and independent of Rails 5.

Summary

Reactive Rails let’s us develop our app faster while we prioritise the API to solve real-world integration problems. :beach_umbrella:

2 Likes
47

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.

48

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.

49

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?

50

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.

1 Like
51

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?

52

Can we move these discussions here:

Toward a roadmap for our API - #20 by jvalboa :pray:

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 :muscle:

1 Like
53

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.

54

@Rachel
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…

YES

We will move the conversation there and start talking about an API strategy.

55

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?

56

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

  1. There is strong developer motivation to move to Reactive Rails
  2. 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.

1 Like
57

Yes, I can live with that. One way or another we’ll do all the best we can for the project.

2 Likes
58

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.

1 Like
59

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
1 Like
61

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.