Ask HN: What stack to migrate

[kh3dr0n]

Currently I’m working at a growing Startup where we use Ruby on rails as the main stack for huge monolithic app, even the front-end is server side rendering. We are thinking adding new features, front-end will probably be React communicating with new API. We are still deciding about the best approach to add this feature and try to split this feature and future features from the monolithic part while keep sharing data and communication.

Also we are discussing about using another language other than Ruby, some co-workers suggested Elixir (with Phoenix), personally I would like to go with Go ...

Any advices on how to add new features to big monolithic app ?!, any tech/stack/lang/framework you recommend ?!, any experiences to share ?

[danielvf]

What problem are you having with Rails currently? A lot depends on that.

Personally, I’ve found that API/SPA apps end up being more development work per new feature than a single Rails monolith.

Also, anything you switch to is going to feel a lot more productive at first. This is somewhat deceptive, because what your really seeing is that your new software codebase is solving a much smaller problem at first, and of course that's much easier to work with.

[kh3dr0n → danielvf]

The current app is huge and has a lot of legacy/messy code, that still running, changing it will be really hard now. Tests takes ages to finish, the initial project structure is bad, many mistakes were done in the past. We are planing to build huge new feature, that can has it own UI, So we decided to go for SPA, but where are asking ourselves what's the best way to build the API, Just build it on top of the current project or new project with Rails or other stack ?!

[fiedzia → kh3dr0n]

You screw up your architecture and development process. Choosing your stack is not what you should focus on, whatever you choose will not solve your problems.

[spyckie2]

Rails is great. Front end server side rendering is great. Monolithic is great. These things aren't problems in themselves unless they are creating problems.

You should approach this question with a problem solving mindset. Write down what your main features are and then choose the right tool for the job. Is your app mostly business logic? CRUD updates? Lots of real time push communication? a bunch of custom UI components?

Are customers complaining about the speed of the app? Does it render too slowly or have long wait times? Is it too costly to run? Is development too slow?

Technical decision making is for solving problems, so make sure you know what problem you are solving. Unless you can name a real problem that can't be solved without a new stack, there's no point to rewriting.

For adding features on a monolithic app, you just add features... not sure what kind of answer you're looking for. Rails gives you the ability to build an api on it, you can add react, vue, or any SPA framework on top of it pretty easily.

[kh3dr0n → spyckie2]

Our current app is so huge, testing takes a lot of time, it has a lot of legacy code and it is too messy. That's the main reason behind building the new feature in different project. And we are not rewriting we are adding new features ... So the monolithic part will stay there for ever. Just we want a clean way to do it.