This question is not code but architecture related.
When you build a microservice in a web application you will need to somehow expose the service and make it accessible.
The ways I am aware of:
So my question is if I have a microservice running that for example continuously collects data in an event-driven manner, is adding endpoints to this micro-service a good idea? My contention is that my understanding of a RESTFul API is, that if there a no requests the API should idle and do nothing, this achieves scalability based on requests.
If I add a RESTFul API to a microservice that already runs code on an event-driven basis then there are 2 ways the microservice can receive workload, one is API requests, others are events coming in from the actual computational part of the service.
Let's say I have a microservice which reads in tweets from Twitter. The service streams the tweets which means that an event is triggered every time a tweet is being posted. For the sake of simplicity, let's say the service keeps the tweets it receives in RAM and does not store it in any type of database. The RESTFul API part of the service is now supposed to expose the tweets by allowing users to requests a list of gathered tweets for example.
In this scenario, there would be 2 directions from which workload can be received: a tweet is posted or a user requests tweets.
This seems to me to be a scalability issue since you will have to watch out for 2 different sides of the microservice.
Is there any general consensus around this topic?
is adding endpoints to this micro-service a good idea?
In my point of view, and look through a architectural perspective, it's not a problem your event-driven service expose rest endpoints if it's aligned with domain of your service, but you need to take some aspect inconsideration:
Scale the service became a little more complex, because you had two values to inspect to trigger the scaling process: number of request (from the perspective of REST side of service) and memory consumption (from perspective of event driven side of service).
Even if you had small consumption o memory but a grater number of request, maybe when you scale, you will have a larger memory footprint fro the rest side of service, or processor, and or storage... Or the opposite side, you had lot of consumption of memory in you event driven side of service but a little of request, the weight of one side (REST ou Event drive) will became part of total foot print.
Looking to you proposed problem, I think, the more aligned solution will be separate you service in two pieces (two services), one specialized in read (the rest one) and another specialized in write (the event driven one). This scenario allows you to scale this pieces independently base on their memory, processor, request or storage needs...
This described scenario is covered by a pattern called CQRS you can take a look here: https://martinfowler.com/bliki/CQRS.html
Is there any general consensus around this topic?
Consensus... well it's hard to say, you will see some patterns you can apply to resolve this scenario, one little more correct than others... Organization aspects of governance of services... Environment aspect factors and so on... In my opinion, a good solution is the responsibility segregation in two services.