The hybrid way in a fragmented technological landscape
Why we chose Node.js for our GraphQL API and incoming webhooks to expose our .NET workflow engine.
Starting from scratch can be a significant competitive advantage in the age of digital transformation. Being a part of every next technical upgrade is exciting: new tools, new languages, new ecosystems. We can solve (or skip) problems that plagued previous generations, and product development becomes faster with smarter frameworks and infrastructures.
The temptation is high — especially when the competition is fierce — to play with shiny new things and opt for a “Big Bang” approach.
But when you have to deal with hundreds of thousands of existing lines of C# code and a million active WorkflowGen users worldwide, the process of transformation is a little bit more tricky!
The hybrid approach is our Tao to deliver new features by using the latest technologies at an accelerated pace.
Hyper-fragmented development frameworks
I use the “hyper” prefix here because fragmentation is not only about the profusion of programming languages and frameworks, but also due to a new level of “moving” complexity.
The technical environment is nearly boiling over with multiple generations of solutions available at the same time.
Indeed, we have to navigate between .NET 4.6, .NET Core, JavaScript ES5-ES6-ES7, Typescript, Angular 1, Angular 2, React and React Native; there are also transpilers, such as Babel, that allow you to “time travel” by using future programming language releases and improvements. The time needed for a C# .NET 4 developer to learn Node.js is comparable to the time needed to learn .NET Core and its associated libraries; the programming language itself is just part of the story.
In the meantime, development stacks are composed by ever-changing floating elements. The possible combinations of modules, libraries and programming methods are limitless.
You can set front-end and back-end frameworks to reduce this complexity, but this is far from an ideal solution.
For example, Angular 2 offers two approaches to implementing a web form: template-driven or model-driven. React lets you decide how to manage the state, and multiple solutions are possible (redux, redux thunk, redux observable). .NET is highly fragmented, with multiple MVC and web API patterns and data access layers.
With advances in real-time APIs and Pub-Sub systems, most current frameworks and software architectures have to integrate new sets of functionalities and programming models. To support the upcoming GraphQL Subscriptions we’ll be adding new technical components to manage real-time updates.
With the hybrid approach, you don’t have to find the perfect development stack that covers all your needs and requirements.
You can instead limit your scope to the new features you want to address, focusing your research and prototyping on a restricted number of solutions. In our case, GraphQL has a great stack around Node.js.
A .NET implementation of GraphQL exists, but Node.js has more useful GraphQL libraries and modules. Prototyping a GraphQL API is also ultra-fast with Node.
Microservice architecture
Microservice architecture seems perfectly aligned with the hybrid approach. There’s no need to set a development standard across teams. Each developer, like an artisan, comes with their own set of tools to create a service compliant with technical infrastructure requirements.
There is an obvious risk of “babelization” here, but the question of maintainability can be partially addresses by a microservice’s limited code base: if a significant change has to be made, a developer can create a new version of the service from scratch again, without having to re-engineer the existing code or compromise with the previous stack.
Microservice architecture is seductive, even moreso when associated with serverless architecture.
Migrating the entire product to hundreds of microservices is not a viable option for us if we want to deliver new features in the short term, but we can reuse what makes this architecture successful.
The hybrid way
By observing the technological landscape as a dynamic system, the selection process is easier. The level of features and how modern the stack is are only parts of the equation. In a dynamic system, the primary quality is fluidity.
In a software environment, fluidity is how fast technology can be integrated, remixed and improved.
Since they both possess this quality, we have chosen Node.js for our GraphQL API and incoming webhooks. The Edge.js library is the missing link that has allowed us to bridge the Node.js server application with our existing .NET workflow engine, while the iisnode module preserves the existing infrastructure (IIS, authentication, logs).
Node.js offers a ready-to-deploy GraphQL API stack; there is no need to reinvent the wheel, and we can focus on implementation.
The first GraphQL API prototype was set up in days, and the Alpha was completed in three months.
For the microservice architecture, we took the lean approach. The GraphQL API and incoming webhooks Node.js server application layers are very thin regarding lines of code and complexity. These server applications are HTTP interfaces that expose our workflow engine via a .NET API façade, while most of the infrastructure-related code (as authentication and logs) is already managed by IIS.
The development environment has been simplified; the code is written in plain JavaScript using ES6 that provides modern programming language features (arrow function, promises). Babel and Typescript are very interesting, but they add an extra layer that’s not justified in our context. We want our customers to be able to customize applications according to their needs, extending the GraphQL schema and adding their own resolvers, for example.
Our clients are already familiar with customization features done in JavaScript client-side; they can now do the same server-side with the same language.
It’s also great for our React Native mobile application project to have development teams working on modern stacks for both the front-end and the back-end.
Conclusion
The hybrid approach is not totally new, since our front-end applications already use different technologies and stacks. What is new is having a hybrid approach on the server-side, which makes the software more transparent and customizable.
The human factor is also significant; our teams work with cutting-edge technologies while being fully operational in mature and widespread development frameworks.
The “Big Bang” won’t, in fact, happen in one single moment, but rather month by month and release by release, with the hybrid approach helping us deliver to our clients advanced features using modern technologies and development methods, the same ones used by many startups.
