Hacker News Reader

Comment by danias | Hacker News Reader

11 pointsdanias7 comments

Really interesting that you used gRPC for the communication with the frontend. Why was this your main preference instead of using GraphQL? Is it easy for GraphQL communication to be added?

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.

Hi HN!

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.

Check it out https://github.com/bitloops/ddd-hexagonal-cqrs-es-eda and we would love to hear your feedback. Let us know what you think and if you like it please star!

Why did you choose to use NATS for this app? Why not use Kafka?

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.

I really like the fact that it comes close to production-ready code - that sounds promising. I'll definitely check it out and see if it's something I can wrap my head around. Thanks for sharing!

Thanks for your feedback and looking forward to any questions you might have!

Reply on news.ycombinator.com