If you have specific points you wanna discuss, possibly with some real arguments to back them up, I'd be more than happy to do so. Otherwise please refrain from submitting such pointless comments again.
I was just throwing CORS, 2FA out as examples. API's use LOTS of security and authorization. And that is implemented on the backend.
If you are saying AMQP is better than HTTP then you are saying it is a replacement for HTTP based API's.
So, how are you going to implement alot of the protocols that you will need to implement LIKE CORS, 2FA, Authorization? :)
Fill in the gaps that you want to replace. Thats a huge gap you don't have solutions for.
... and yes, REST API's can be async. Check it out sometime.
I already answered to all of you points and I'm starting to believe you are not interested in having a fair, healthy discussion but to just start some flame.
As I already stated, this article is about inter-service communications, not public facing APIs to be consumed by a user. So you don't have CORS, you don't have 2FA and you don't need microservices to authenticate with each other directly because this stuff simply doesn't apply in this context.
I really don't see where you're going with this discussion.
And again no, REST is not async on its own as I already said. You can use asynchronously, you can do funny stuff with webhooks and Websockets to make it behave like an async process, but REST itself does not provide any primitive for async message passing. And just saying "check it out sometime" without actually explaining your self or linking some resources says a lot about your way of managing discussions.
Now if you have some actual constructive feedback to give please be my guest, otherwise I will not continue with this pointless conversation
You haven't answered anything. You dodge. You merely state 'this is not an api' but neglect to answer how AMQO provides equivalent services to what HTTP provides
Great article. Addressing the security aspect for any future readers exploring messaging for their Microservice architecture.
Can this approach lead to a slower microservice? Yes, but there are occasions where security is more important than latency.
- The methods discussed above are top of mind solutions and not specific to any type of transport(HTTP, AMQP, SQS, etc) between microservices...
- Google "defense in depth microservices" for more info on item 5 of About Security.
- Checkout what OWASP has to say about security.
Lastly, I love using messaging for my microservices. Especially where high volume is a concern.
Very good points. In light of the main topic (AMQP-based microservices), advanced brokers like Rabbit do have ACL systems that can and should be used to restrict what each service can do. Maybe you have a topic where sensible data are exchanged and only some services can access them, with Rabbit you can set up ACL rules to block read access to those topics.
Or even segregate them on their own virtual hosts (kinda like namespaces or tenants) so that they are completely separated. Services don't need to know that this kind of access control is happening, it's enforced by the broker itself (which I prefere compared to security-aware microservices).
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.