We do not have the silly specialization to frontend/backend or to business logic/database or whatever it might be. Our team is small, but strong, and every engineer is perfectly capable of working on everything, and they do. When working on a task, every engineer is expected to work with PureScript, JavaScript (as needed), Ruby, Haskell, SQL, and any external APIs that might be required. One unfortunate exception is data science, which is a separate team of people, and they mainly use R for their work, though even they venture into Ruby land to make small alterations from time to time.As for functional vs. non-functional – personally I think that’s a false dichotomy in this case. Ruby is definitely object-oriented to its core, but this does not prevent it from being functional. We do try to be as functional in our Ruby code as the Rails libraries would allow us to be. And this definitely helps a lot with maintainability of the codebase.A separate dichotomy (true this time) is static vs. dynamic typing. I haven’t worked with large dynamically typed codebases before, and now that I have, I can definitively say that static typing is far superior. As I work on features, switching from Ruby to PureScript is always a breath of fresh air, especially if I was working with Rails libraries. Outside of Rails, it turns out to be possible to structure the code defensively, almost kind of a Lispy feeling.That said, I think coupling Ruby with PureScript has actually helped us with stability. Our PureScript code is organized in a way that more or less forces it to verify the shape of data structures it receives from Ruby, and combined with test coverage, this allows us to discover Ruby mistakes early (or at all). Even if not caught by tests, such mistakes are discovered via the error stream from production.To integrate PureScript into the Rails app, we have implemented a bridge that snaps into Rails asset pipeline (aka “Sprockets”) and exposes an interface very similar to what Rails uses for including JS or CSS files, but behind the scenes takes care of compilation, bundling, instantiating, and passing parameters, as well as server-side render and caching – all transparently to the developer. All the developer needs to do is write a PureScript module that exports a value of a specific type, and then, on the Rails side, provide the name of that module and any parameters.