My goal is to make an application with a SPA front end that updates in real time, incorporating microservices architecture (and for solutions CQRS design patterns and eventing with Azure Service Bus).

I have -

  1. An SPA (using Angular) -
  2. A front end API (for the SPA) which exposes api and SignalR hub
  3. Some back end services - Azure Servicebus for operations on back end and notification for front end api that something is updated (in which case a signal R message gets pushed)
  4. Identityserver 4.0 as STS (and asp.net core identity as store)

I'm struggling on making a good, safe, scalable architecture of my system. I don't want unnecessary overhead nor want to create a big monolith. I want the back end services to be hidden from the rest of the internet but the front end Api can access it.

I want the front end API to be intelligent enough to query for specific needs that the SPA needs and to listen to events relevant for the SPA to get notified off via SignalR. In other words: I don't want a dumb gateway.

Feel free to school me. I really want to get started with implementation and learn more about architecture.

I feel the lines from back end to STS is overkill if I only allow access from the front end API.

I really need some insight.

This is what I made thus far: enter image description here

Main question is: where do I improve on and which mistakes am i making right now/which risks are there to this way of architecting my system?

  • Its terrible. Microservices should not call each other so that is that. So if they dont call eachother then I wont need to secure them for each other. And only the frontend api will acces them. – Viking Apr 9 '19 at 5:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.