Reduce complexity / Make app more maintainable
DeeDeeG opened this issue · 14 comments
[EDIT 10 April 2019: My main reason for posting this issue, not feeling personally up to the task of maintaining a Rails app, has been addressed by continued learning and practice. (And also I have a better idea of why we need a framework such as Rails, i.e. so that we have a server without having to code every bit of that from scratch by ourselves, essentially. We start with a base that "just works," the base default Rails app, and work from there.) The rest of the discussion can be limited to technical suggestions. I am personally inclined toward incremental improvements, mostly.
- DeeDeeG]
Hi all,
Refuge is a great app, and it is an important feature in people's lives. People love the app, generally speaking.
The code, on the other hand, is a bit intimidating.
I appreciate the way Ruby on Rails allowed an incremental approach, starting from the working default page, toward what Refuge Restrooms needed to be. And it has continued to offer quick access to lots of strong/great features. Mostly through gems, many of which thoughtfully work with and on top of each-other's functionality to make something that is greater than the sum of their parts.
Which is to say I like the app AND I like the code.
But still, it can be a lot of work to keep it going, and to make changes is also a challenge.
So that said, I felt it would be good to start a discussion about ways to make things simpler/easier and reduce maintenance headaches.
I am totally open to suggestions, and wanted to get a couple of points of view on this if possible, since it might mean a major change in direction for some bits of the code if this is properly addressed. And perhaps I am the only one who feels the degree of complexity with this app is any high. I'm interested to know what everyone thinks.
- DeeDeeG
Edit: fixed a couple of spelling mistakes.
To get the ball rolling, I feel like there are a couple of broad strategies we could take:
- Reduce dependencies
- Drop bundled extra features we don't use that come along with the features we do use
- Replace pre-packaged features with direct, hand-coded code in some places
- (Implement just the feature we need, rather than the general purpose version from the package)
- Start over
- In the same vein as the recent web mockup I have been working on, try to do as much with native web tech as possible, using frameworks and pre-packaged stuff only where needed, or to a minimum extent.
- Basically re-implement what functionality we already have shipped, but try to stay light performance-wise and approachable maintenance-wise
- Use something other than Ruby on Rails?
- Heroku can host all sorts of code, including Node.js and React, or some combo of those with Ruby on Rails
- (see this for an easy way to get bootstrapped running a React app.)
- I dunno whether this would help the complexity or make it worse, but it is an idea, and those with more familiarity with React or Node.js might be able to evaluate this suggestion better than I can ...
- There was already an issue at some point that mentioned switching parts of the app to React, #289.
- Heroku can host all sorts of code, including Node.js and React, or some combo of those with Ruby on Rails
So those are my thoughts so far of ways to make this an easier project to maintain.
Regards,
- DeeDeeG
Another idea I just had, is to make jumping to new Rails versions easier, at some point we could try to re-implement Refuge on top of a fresh copy of the default "hello world" Rails 5.2 app, or eventually rails 6.0.
I expect this would mostly be copy-pasting stuff as needed from the existing repo onto the "hello world" app from 5.2, and checking that it works properly. So we'd have the more up-to-date config files and such from 5.2... rather than turning off all the new defaults assuming they'll break things.
(We'd use all the new defaults and assume they don't break things unless proven otherwise.)
At that point, moving to the next version should be easier, as our configs would closer-match the defaults anyway.
Edit 3: I have since learned how to better use Docker, including docker-compose run web bash to get an interactive shell and do things like update the Gemfile. So this comment no-longer applies. I am fond of Vagrant, since it's simple (mostly just a VM and a shell script), but I am finding it slower to set up than Docker, and I find actually using/maintaining a Vagrant branch in almost all other ways equivalent to or less convenient than Docker.
Also, I find updating the Gemfile and Gemfile.lock much easier with Vagrant than with Docker.
If it wouldn't bother other maintainers, I'd be happy to set up/maintain a branch where Vagrant is re-enabled instead of Docker, specifically to make dealing with the Gemfile/Gemfile.lock easier.
Edit: see my demo branch at https://github.com/DeeDeeG/refugerestrooms/tree/revert-docker (I already used this to make PR #482 easier.)
Edit 2: Speaking of updating the Gemfile, I had another idea: Every gem with versions specified in our Gemfile is going to have to be manually updated at some point (usually to resolve dependency conflicts, particularly when it times to upgrade Rails). We could remove specific version numbers such as ~>1.0.2 in favor of the default, which works out to >= 0. We would basically only have specific version numbers where we feel an update to that Gem is likely to break our stuff, and otherwise rely on the Gemfile.lock to keep a tested and known set of packages and thus keep from breaking things.
pro: Move faster 👍
con: Break things? 👎
To get the ball rolling, I feel like there are a couple of broad strategies we could take:
Reduce dependencies
Drop bundled extra features we don't use that come along with the features we do use
Replace pre-packaged features with direct, hand-coded code in some places
- (Implement just the feature we need, rather than the general purpose version from the package)
Start over
- In the same vein as the recent web mockup I have been working on, try to do as much with native web tech as possible, using frameworks and pre-packaged stuff only where needed, or to a minimum extent.
- Basically re-implement what functionality we already have shipped, but try to stay light performance-wise and approachable maintenance-wise
Use something other than Ruby on Rails?
Heroku can host all sorts of code, including Node.js and React, or some combo of those with Ruby on Rails
- (see this for an easy way to get bootstrapped running a React app.)
I dunno whether this would help the complexity or make it worse, but it is an idea, and those with more familiarity with React or Node.js might be able to evaluate this suggestion better than I can ...
There was already an issue at some point that mentioned switching parts of the app to React, #289.
So those are my thoughts so far of ways to make this an easier project to maintain.
Regards,
- DeeDeeG
Rails allows you to install React, Angular, VueJs, Elm, and Stimulus (https://github.com/rails/webpacker). You could keep your same application, move your views into a frontend framework, and use Rails for api calls. This would only work though if you have frontend developers who want to contribute. Did you mention React because you know some React Developers who want to help?
Any changes where you're separating the frontend and backend is going to require more developer skills. My opinion: If you have a team of frontend developers it may be helpful to install a frontend framework in your current Rails application. Then you can just focus on finding some backend Rails developers, knowing that the frontend is being taken care of. If you don't have any frontend developers, you're now putting more work on yourself to find both Rails developers (or Node.js, PhP, Go, etc developers) and frontend React/JavaScriptFramework developers to help out.
Thanks for the feedback.
My impression of the team is that we are:
- Largely self-taught as it pertains to Rails and/or React (I might be wrong about this! I certainly am self-taught, though.)
- Volunteers working in our spare time.
So the sky is hypothetically the limit, and the actual limit is time and the ability to self-teach. I think if we self-taught these new frameworks, and came to prefer them, then it would be a plus.
Conservatively approaching how likely we would be to adopt a new framework, I'd say it's a bit far off. But we do find time for things here and there, and have bursts of activity that lead to progress on these larger projects.
Out of the strategies I laid out, I believe lightening up what we already have (1 & 2) is closer to my existing skill areas. 3 was to try to include previous discussions on what directions we might the the app. I lean toward 'less kinds of tech = more maintainable,' and I would lean toward not adopting any additional frameworks without eliminating other ones.
Did you mention React because you know some React Developers who want to help?
Not developers who I know of, but there was mention that in general there might be more developers comfortable with React in the open-source community. We do get pull requests from the general community at times to improve the project. (I support anything that makes this project accessible to the developer community at large.)
Edit: See also this mention of the MERN stack: #468 (comment)
As to the benefit of a new framework, as I see it: I think we would make a "NodeJS app" (or else insert your JS-based framework of choice here) and port the app all at once (including the backend and all the features) if a JS-based approach would be taken. If that framework is easier to deal with as a whole than Rails, it would be a net plus (as an extended hypothetical, since I don't know these JS frameworks at the moment.)
Those are my thoughts off the top of my head. (I am the most-junior of active maintainers at this time, so my opinion should presumably carry less weight on this than the other maintainers'. Just wanted to get the ball rolling in case this could prove a fruitful discussion.)
Thanks again for the feedback. It is good to get some ideas, info and perspective.
I'm relatively comfortable with React/ES6 so I'd be willing to contribute if needed.
Laravel has webpack integration by default and is pretty well suited all round, however I'm not sure how well supported Geo-coding is.
It would be entirely possible to use vanilla react + a REST API for the most part, as there's only a few requests going on for the most part (search & display).
Thanks for the comment.
IT does seem like a fair amount of people would be able to contribute to an app using a JS (probably including React) framework. So that's certainly an item in the "for" column. Would love to have some comments at some point from @mi-wood and @tkwidmer, since their consensus on this would basically be a pre-requisite for moving in any major new direction IMO.
For now, thanks for the comments and insights, everybody.
I'd feel pretty good about moving to React / Redux. The only real barrier imo, is really cleaning up solidifying the API, and strictly using an API to make all requests including POST requests. In general I think it would make our project a lot more attractive to FE folks wanting to contribute. There are a few issues to figure out logisticly.
Moving translations, etc. (I've actually used a package called i18n-js for this.) We could then completely move to webpack for the front end and get out of the asset pipeline. Possibly even move the FE to it's own repo. Etc. All of those are positives in my opinion (cc: @DeeDeeG @tcmal )
Perhaps focus the effort on a mobile friendly website/web app. Google just released the possibility to release web apps (PWA) in Google Play for easier discoverability among end users who still have not been fully educated to find web apps not present in the app store.
From what I understand Refuges Restrooms does not depend on any features that require it to be implemented as a native app or cordova to access native functionality other than for distribution in the app stores.
But if you have people who love to toy with the native Android and iOS code, then let them keep toying with that. As people liking to toy with things is what brings open source forward.
As some inspiration a related project Wheel Map does use React JS for their frontend for web, and mobile (android+ios) using cordova from the same frontend project. Their frontend project is open source (MIT) and available on github. Wheel map frontend project
Hi, I'm interested in contributing to the project, so I just wanted to throw this question out regarding major efforts. As far as moving to splitting the back and front ends, is that the most value that can be delivered to users or is it more of a icing? Don't get me wrong, "it would be fun," is a perfectly valid reason for pursuing work, but I'm personally interested in producing value for users. Turning the front end into a PWA is definitely valuable, but is it needed when people are willing to work on native apps?
Increasing test coverage, if necessary, and reducing dependencies seem like strong routes to making work more accessible. Just my opinion though
Hi @allgoodserra, and thanks for your question.
As far as moving to splitting the back and front ends, is that the most value that can be delivered to users or is it more of a icing? Don't get me wrong, "it would be fun," is a perfectly valid reason for pursuing work, but I'm personally interested in producing value for users. Turning the front end into a PWA is definitely valuable, but is it needed when people are willing to work on native apps?
Yeah, I agree that having the tech the way it is, is probably just as (if not more) maintainable than a separate front-end framework. Likewise, we have mobile "covered" by mobile apps, with an active team on Android, and the iOS app is tailor-made and still working at the moment, despite not having had its code updated in a bit. Don't need to fix it if it isn't broken. Would be nice to have more people/bandwidth up for working on the iOS app, of course, but it's been ok so far IMO.
The thought of going to a more mobile-web solution has come up recently. I am neutral to this; I am fond of the existing mobile apps. PWA features (Google-style) are optional with regard to creating a good experience on the mobile web. But it does let you "install to home screen" and promises to work somewhat better offline. So there could be a benefit... But these priorities are still well-covered by the existing mobile apps, so it would have to be a strong case to move from those to mobile web IMO.
I have become increasingly comfortable with Rails tech and maintenance of a Rails app since I posted this issue. Perhaps it is moot at this point, because I am convinced staying roughly with what we have is good enough. And less costly than a major change in technology in terms of initial implementation, and probably maintenance effort down the line.
Increasing test coverage, if necessary, and reducing dependencies seem like strong routes to making work more accessible.
Both good principles in general. Our test coverage hovers around 90+%, and I'm not much of a programmer, so I find it a stretch to improve this myself. (I could give it a shot...)
Re: dependencies we might drop... I think we can customize our usage of bootstrap to not pull in the whole CSS framework, for example, just the bits we need. I think we could quite possibly move away from HAML (which has DRY qualities, very concise... but it's another language to learn) for ERB (basically normal HTML with a way to put lines of Ruby in). Those are just off the top of my head.
I defer to maintainers/devs who have been here longer, though, on any of these things. Just brainstorming here. Anything I do toward these goals would be in a PR, well-discussed beforehand, etc.
Practically: My inclination is to stay with what we have (and maybe pare it down tech-stack-wise where it's not disruptive to do so) and wait for signs from @tkwidmer and @mi-wood about major new directions.
We might want to close this issue for now, since my reason in posing it (my personally feeling not capable enough to maintain the app) has subsided. I think we have enough Ruby/JS folks around to handle the code, and I'm comfortable now with almost every other aspect of maintaining the app that doesn't require direct, moderate/advanced-level programming.
Oh, I should have checked the test coverage percentage, sorry! 90% is more than good, imo. But cool, I'm glad you're feeling more confident! I'll be poking around in the open issues for potential contributions.
Finally closing this, for reasons discussed in recent comments and my edit to the original comment. (i.e. the main point of this issue has been addressed.)
If we want to revisit changing frameworks, that can probably be a separate issue. Feel free to link back to this in future discussions, though.