Great question! While GraphQL is pretty cool we really like protobufs because its a lot easier to generate nice client code. Using grpc-web allows us to use the proto file to generate types and code for the frontend making the experience much much better than GraphQL, in addition we have implemented a caching mechanism that avoids sending back unnecessary query results back to the client. Finally grpc-web uses HTTP2 and is much more performant than GraphQL. Having said that it is not too hard to add GraphQL support through a Nest.js plugin and we will probably add it in the future if there is enough interest.
We would love to use Kafka because of its extensive support (e.g. Debezium) and by creating a new Nest.js plugin it would be pretty easy to switch as the message bus is just an implementation detail, nonetheless, we decided to start with NATS because of its much smaller size and RAM requirements making it much better to use for smaller projects (e.g. when firing up a Docker image or running in a small Kubernetes cluster). As an added bonus, NATS is also faster.
Our team at Bitloops has just published a Todo app that we think you'll find very interesting as a reference implementation. It's designed to showcase some advanced software architecture concepts like Hexagonal Architecture, DDD, BDD, CQRS, and Event Driven Architecture.
We've used a variety of open source technologies, such as TypeScript, NestJS, gRPC, Jaeger, Prometheus, NATS JetSteam, Grafana, Mongo, Postgres, and more to build a clean and modular codebase that's as close to production-ready as possible.
We know that learning these concepts and technologies can be challenging, which is why we wanted to share with you this comprehensive example we wish we had available when we started learning these concepts.
I distinctly remember reading (but not where—it was real though, not fictional) about a tactile suit, which translates audio into vibrations on different body parts. Apparently deaf people successfully learned to use it to interpret speech.
A benefit of microservices is that you can use specialised languages for different parts of the system. The core of your system might be written in Java but you might one to use Python for an ML heavy module. Nonetheless, I tend to agree that in an organisation with 100 microservices probably the ideal way would be to have 4 or 5 based on exceptions where you have modules that need a specific hardware profile (e.g. a lot of RAM) or a different programming language than your core system. Everything else could go into modules in a megaservice.
We are building a new language that is not for fun and we have thought of this important issue. We solve it with a Package Ports and Package Adapters. The Bitloops Language (BL) is a transpiled language with support for only TypeScript at the moment. Nonetheless, if it picks up we will be adding support for Java, C#, and C++ so that people can leverage their investments in their existing packages.
