
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.<p>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 ...<p>Any advices on how to add new features to big monolithic app ?!, any tech&#x2F;stack&#x2F;lang&#x2F;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
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
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
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.

