JS Based Backend Re-Implementation

[ice1080]

This was proposed by @DeeDeeG in the slack general channel, I'm just creating an issue for tracking this and to start conversation with @DeeDeeG for me to assist on this, if open to it.

Scope / difficulty

Because specs already exist and this is just a re-write, hoping that this will only be a moderate difficulty.

Impact

This will recreate the full API, but if done correctly will not affect the end users at all.

Rationale

Anything more modern and less outdated than our current Rails approach.

Dev Experience. Modern languages/frameworks. Etc.

Proposal

Use the OpenAPI/Swagger-based api docs here: https://refugerestrooms.org/api/docs/

Re-implement all the same endpoints and functionality as the current ruby backend.

How to actually do this:

Open to framework ideas. A few initial options:

• express
• koa
• fastly

[DeeDeeG]

Hello, thanks for reaching out.

JavaScript vs Ruby/Rails?

The specs (and most core logic of the app) are in Ruby / based on Rails framework.

It's possible to have a fairly JavaScript-focused app ultimately running in Rails. As long as this allows moving to recent dependencies and lets us drop some deprecated/unmaintained things, this is an okay option: moving some Ruby things to JS, while still in a Rails context. Such as something to handle just interacting with the DB? (But Rails remains fundamentally a Ruby-based framework.)

If it's possible to move the whole app to a JavaScript-based framework, and not be using Rails, that could also be very good (hopefully better than staying on Rails, pending a more specific roadmap/implementation to consider).

What's deprecated that would be good to move away from?

The main deprecated thing I'd love to get away from is Rails' Webpacker 5 + Webpack 4. This is keeping us stuck on NodeJs 16 at the moment (see: #682).

If it happens to be convenient during any refactor, moving away from Google Maps would be really great, but if it's not convenient then that could be left as a separate thing.

What the end-result should look like?

The main requirement at the moment would be to have something that can be hosted on Heroku (like the current web app is), and presumably still have a postgresql DB (also hosted at Heroku) for the database. Unless there is simultaneously a better web app host we can all get behind using.

Should support the same API we provide to access our restroom records DB, because existing users (like the Android app) make use of our existing API.

Disclaimer: My skill level with programming isn't super high

Fair warning that while I am effectively the most active, and quickest to respond maintainer here, I'm rather self-taught and the least programming-skilled member of the current maintainers. I happened into this role by volunteering some time ago to try and address a number of smaller bugs at the time. So I can do my best to dive into any new code, but unless other maintainers can bless some of the things, then some of the review may just have to be based on testing (and some amount of faith) as much as full-on code review, if it's me doing it.

[ice1080]

This is super helpful to understand, thanks for sending all this info @DeeDeeG!

My disclaimer would be that I've used many different languages and frameworks, though ruby and rails are an area that I have less experience with. I'm fairly comfortable reading documentation and existing code to understand how most projects work though. I believe that my experience architecting and building various other projects will assist on the technical side, and your experience with this project itself will assist on the product related side.

That's helpful to see the deprecated things and the target Node version, etc (regarding #682). Regarding heroku, they offer support for lots of different backends, so whichever approach we take should not be an issue with heroku and postgres.
As a note, this work should be done separate from the google maps change, as that is a pretty major migration and we would want to isolate the two initiatives.

I've not done a multi-language backend before, like you're mentioning, at least not in one single repo. My initial thought was to migrate the whole project to JS, though I'm open to either approach. Before we go too far down this re-implementation though, I want to make sure that the other maintainers are on board with this. I remember seeing some of your comments that the other maintainers are not very active or responsive, but just want to make sure that if they were to come back to this project and it was in a fully different language and framework, that they wouldn't reject it and roll things back to before.

[confused-Techie]

I know I've never interacted with this repository before, but a fellow contributor in another project pointed this one out and I thought I'd add my few cents.

To clarify, I actually have some really great experience of recreating a JavaScript backend from scratch based entirely on spec documents. I actually did exactly this for Pulsar, when I recreated the Atom.io backend completely from scratch, and I made it all in JavaScript, working with a PostgreSQL backend.
And even that I had to mostly base my work by testing hits to a live backend, instead of having some awesome Swagger docs.

If you'd like to check out that work or see it live. But that's all to say, this is a idea I've done before and would be more than happy to help out with.

So if this is something that was wanted, I'd be much more than happy to take a shot at it, although some guidance would be appreciated as I'm unfamiliar with the repo. Such as where the code specific to the backend actually lives, and if just making a PR out of the blue with a full rewrite would be alright. Although I've never worked with Heroku, so I'm unfamiliar with how things would need to be structured to work there, as I'm mostly familiar with a NodeJS environment, and using express that'd be my default go to methodology of getting the backend up and running, unless otherwise suggested.

But I'd be happy to help with code, methodology questions, or even to bounce ideas off of about migrating to express or JS in general for this task when considering some of the pitfalls or pain points.