I agree. It seems like he pulled the plug a bit early but honestly he would know better than all of us if it makes sense or not. Perhaps he have found a better project to sink his teeth into...
There's no super easy way here. One way to get this done is find independent areas of the app that can be replaced without coupling. Then start building up as you go with the new system. At some point you'll be about 70% through of which you can decide if you want to make the jump and focus your efforts to completely uproot the old one.
Sorry for the abstract reference here, but it applies to almost any replatforming out there. In most cases it is a very expensive operation for a business and needs some major reasons in order to justify such a move.
Instead of a Single Page Application, make it an MPA (multi-page application), each of which is basically a separate SPA. You get latency when swapping between sections of your app, but on some codebases (such as for an internally-used app), that's less of a problem.
We did something similar to this when we broke up our Ember application so that we could code new things in React. We still maintain our Ember codebase, but are rewriting parts of some routes in React, and adding all new things in the React app.
We deploy ours as separate pods in a Kubernetes cluster, but you could even host them on the same server with separate nginx routes.
The initial ramp up of this is a little frustrating, as it seems you're adding extra overhead to everything, the long term goal is to have infrastructure and workflow that supports having part of your app in The Old Proven Thing, and part in The New Hotness. This is valuable whether you're switching to React, or upgrading from Ember 2 to 3, etc, as it lets you upgrade a smaller set of dependencies, and experiment with things.
We did. We are building our entire company: SQQUID on 100% serverless architecture. Scalability is awesome, in fact we had to do extra work to serialize some operations in order not to bring down other major corporation's server stack. Cost is a fraction of the traditional app scaling setup.
The best part is no devops needed. We use Serverless Framework. The biggest downside are cold starts for frontend response time. But this hasn't been a terrible issue as of yet. We have considered moving these 20 API endpoints to a nodeJS server which will resolve the issue but didn't have the time to do it yet.
My team just completed a similar performance optimization for a massive ecommerce site. The 3rd party javascript libraries are a huge penalty in performance. The second you get those out of the way and loading async or after page loads, you can start breathing again.
Most 3rd party tools should seriously start evaluating how they offer JS inclusions into web pages.
DevOps Lead | SF ONSITE | Competitive compensation + equity
Educents is the first and only marketplace for educational products. For the first time, we're bringing together digital & physical products and making them easy to browse, shop, and discover - for parents & educators worldwide.
We are currently looking to build our DevOps team. We're looking for 2-3 DevOps who are comfortable in leading the way and establishing our DevOps methodologies and practices within our larger team. We're looking for DevOps who master AWS and Docker.
