This audio was created using Microsoft Azure Speech Services

Our team is on a #IIoT project with Angular, GraphQL, NodeJS, JEST, Mongoose, MongoDB, Microsoft Azure and IoTHub. All that around VSTS as Version Control, Build System, Tests management and Scrum Tool. In this blog post I wanted to share our stack, the process we’ve done in order to get to those choices and our current experience.

Stack overview

Why Angular?

In a large Enterprise company like ours, it is sometimes easier to conform to standards, and one of them is standardizing the company around the Angular framework. On our last project we worked with AngularJS, and we really enjoyed it! The only missing part (as developers coming from a C# background) were types! On this new project, we directly started with the latest flavor of Angular coming with Typescript, and combined with angular-cli, everything works like a charm — Nice and easy build, with a lot of options like efficient treeshaking to optimize output weight, lazy loading and more, all easy to execute under the Angular CLI umbrella.

Why GraphQL?

We started the project using Meteor with the Angular Meteor integration.

We liked how easy it is to get started with Meteor, the possibility for real time updates through live queries and the fact that we could share code between server and client.

In just a few weeks we were able to implement the initial features and demonstrate to the marketing and management teams amazing results.  At that time, the Angular Meteor CLI integration with Angular 5, AOT and dynamic imports wasn’t ready yet, and we also wanted to use the Angular CLI directly, so we used Meteor Client Bundler in order to use a separate Angular CLI app with Meteor. When we switched from the Prototype into a full production project we contacted The Guild for help, architectural review and development. Together, we took a step back and reviewed our current stack. We saw that we don’t need all of the features that Meteor has and can get very far with plain Node 8.

This is when we discovered GraphQL. We loved the idea of having one endpoint delivering exactly what the client asked for, the typed API which helps us even more than Typescript and the possibility to still introduce real time capabilities through GraphQL Subscriptions and the possible future support for live queries. After few hours of discussion and creating together a POC we saw the huge opportunity of this way of getting data to the client.

Why Mongoose & Mongo?

We selected Mongo to have a quick ramp up. In combination with Mongoose, we are exactly where we want in terms of simplicity and effectiveness. With the approach of GraphQL-Schema-first-design we also have a lot of parts generated. We use GraphQL Code-Gen to automatically generate our ORM layer and code!

Why Azure?

Even though we started using it because it was a standard from our company, the more we discover this Cloud service the more we like it. From hosting front end; back end; database; requirement tools, VSTS, CI, everything is there and fully integrated. This makes a great way to build and deploy an end to end solution… We will dedicate a full blog post for this part later on!

Connections/APIs to other departments

Of course, when you start a project in a large company, you have to interact with a lots of other departments. Each of them has their own process, their own API, their own security standards, etc…
This is where we make an awesome use of GraphQL! We are creating a connector to each entity to isolate each service. Let me show you what is the idea in a nice graph. In this example, we have a department responsible for RBAC where they will manage Roles. This information will not be stored in our db. We will store only the user on our side. We created this architecture in following steps:

Step 1: Create the schema

Thanks to GraphQL-Faker, in the sprint planning meeting we can directly create the draft of the schema. So within this meeting we update the schema on the fly and make sure that everything fits to our needs. Soon, our Project Owner will bring the initial draft ready in advance for the meeting. Then, in the meeting, we will just need to update the schema and agree on it.

Step 2: Mock data

By having the schema already prepared when leaving the sprint planning meeting, the frontend and backend teams can already start working as if the other team is already ready thanks to the mocking capabilities of GraphQL.

Step 3: Generate types

Again, by having the schema, we can simply generate typescript typings for both the frontend and the backend thanks to the GraphQL Code-Gen.

Step 4: ORM data models

We also generate our ORM and data models out of the GraphQL schema, using Mongoose and the GraphQL Code-Gen.

Step 5: Resolvers

Thanks to the way GraphQL work, resolvers are a very simple and defined place to get the data from your data source to your clients. Currently we are not generating that part but we might do that as well in the future.

Step 6: Business Logic

Yes, at a certain point, we have to work! But now that we have our ORM data layer ready and we have a defined structure of our server thanks to GraphQL Resolvers, it makes the actual backend work a lot easier to do and a lot easier to manage and break down into separate tasks.

Step 7: Connectors

Here also we have to work. First, we need to exchange with people responsible for this service (here RBAC), understand their swagger definitions, how to use it in an efficient way, etc… Than actually code the connector to their service.

Wrap up

We are really happy about our stack in the middle of Google, Facebook and Microsoft! And we want to share it 🙂
Please let us know what you think about our choices. Ask questions that come up. Tell us about what are the next subjects you want us to focus on our next blog posts?

// Thank you Johannes G. & Uri Goldshtein for writing this blog content with me 😉