1

We have an application that has served us and our clients well from some 20 years now. Pretty good track record but it's obviously showing it's age in some areas.

We are looking for advise and suggestions for bringing the product to the next level. The idea is to address some issues without throwing away or rewriting 10,000's of lines of code.

Here is what we have today: The application server side (actually dozens of programs and CGIs) runs on Linux (CentOS specifically) where interactive operations are handled via browsers (lots of javascript/jquery, some ajax calls, mostly server side rendering). The server side is almost exclusively written in C. We have our own proprietary forms engine that handles data retrieval, posts and launching of programs. MySQL is used as our database.

The application is financial in nature and handles 100's of thousands of transactions and customer records. The core of the product is solid. By core I'm talking about our business logic, batch processing, etc. It's the interfaces and the periphery where we need retooling.

We could use more granular access/permissions model, better access to data and processes though APIs and we need to be able to develop these components more rapidly than possible with our current system.

To preserve our investment and not fix what is not broken, we are investigating what changes can be made to address these concerns but still keep most of the libraries and programs written in C.

One idea we have is to replace our front end with a Node.js based application. The application will initially provide API (Rest based json data) services for read and update of data as well as business logic process endpoints. It would also manage access to data (read and write) and processes via some roles based permissions model.

Eventually the existing interfaces will be redone to use these APIs and possibly do more client side rendering and better interactivity via socket-io and client side javascript frameworks.

Finally, my questions:

  • Does this idea have merit?
  • If not, what other approaches should we consider?
  • What other considerations are there for this project?
  • Will Node.js used in this fashion scale?
  • What server side js framework should we consider? Express seems promising but maybe some other more "opinionated" framework would be better.

For ready only operations, I expect that all server side activity will be handled in the Node.js application. For business logic, maybe database writes, I expect we will hand off the processing to a separate program. We assume the aysnc/await ability will allow this w/o performance degradation. Add-on integration might be possible but as our libraries aren't thread safe that might have limited usefulness.

Thanks in advance for your comments/ideas/suggestions.

7
  • 1
    Does this idea have merit? - Yes. – Robert Harvey May 15 '20 at 19:01
  • 1
    What other considerations are there for this project? -- There are many. But your approach has the desirable benefit of being incremental. – Robert Harvey May 15 '20 at 19:04
  • 1
    Will Node.js used in this fashion scale? -- That's hard to say. The only way to know for sure is to hook up a node.js instance to your existing infrastructure and see if it holds up. However, node is designed to handle a large number of concurrent requests. You can read up on its "event loop" to find out more. – Robert Harvey May 15 '20 at 19:06
  • Does this answer your question? I've inherited 200K lines of spaghetti code -- what now? – gnat May 15 '20 at 19:06
  • 2
    What makes you think that a 20 year old application needs to be "modernised"? Nothing has really improved in 20 years. None of the tooling has simplified. Nothing (in development) has become appreciably "more rapid". In fact complexity and faddishness has reigned. I would stick with your first judgment and "not fix what is not broken" - if the existing approach is working and the application remains robust, then continue in the same groove. The costs of change and additional complexity will likely dwarf any speed penalty that you feel you are currently experiencing in development timescales. – Steve May 15 '20 at 20:18
2

That's a very valuable software you have here, and a nice plan to evolve it!

When such is system is serving customer and works, the rewrite strategy you take is critical. If your goal is to improve the existing application (and not build another one), do it progressively.

You already said you won't rewrite the whole thing, which is a good plan. But don't go for a big-bang rewrite of the front-end neither! Progressively roll-out a new front-end.

The key idea is: current software works for current users and is full of hard-won knowledge you're not aware of. Gently rewrite so you can get user feedbacks and adapt.

There's a pattern for doing just that: the Strangler Fig.

The idea would be to migrate the API as you go. You can tackle that endpoint per endpoint. The idea is to have a facade that redirects the calls to the Legacy or Modern API, which is invisible for the end-user. The same logic can be applied to the front-end too (I've seen a whole SPA be rewritten progressively, using iFrames to embed the old pages that were not ported yet).

These resources on the topic can be helpful:

Regarding the choice of Node.js, the choice is yours. You can build such thing with Node. Will it be the best choice for you? You know better what you constraints are and what benefits you're looking for. Don't underestimate the familiarity of developers with the language (pick something that suits you) and the community you're joining when you pick a language.

Express is minimalist indeed, it requires more experience to scale IMO. But it does the job very well and is flexible enough! If you're looking for a more opinionated one, there's Sails.js. The recent guy in town is Nest.js which is good if your team wants to go for a more Java-style back-end (it's based on TypeScript).

I wish you the best for your migration, that's an exciting project!

1
  • Thanks, Never heard of Strangler Fig. Interesting. Javascript is appealing because we know it already, it's "c" like and it can be deployed on both the server and client. Also a standard data notation (json) is a huge plus. I looked at Nest,js. Looks promising. I'm thinking we need some structure to our efforts and Nest.js may be the way to go. Documentation looks very strong and it seems to be getting alot of traction in the developer community. – user44021 May 18 '20 at 19:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.