I'm investigating the best web framework for my purposes.
We'll develop several microservices, and we need to dispatch events on some microservices, that could be listened on other microservices.
Is there any support for that using FastAPI?
If not, is there a way to listen db event operations?
I saw the #app.on_event("shutdown|startup") from starlette, but can I dispatch more events?
Thank you in advance.
Currently there are no generalised event dispatching/listening features in FastAPI.
#app.on_event("shutdown|startup")
Are a subsection on the ASGI protocol. Implemented by Starlette and in turn available in FastAPI
https://asgi.readthedocs.io/en/latest/specs/lifespan.html
FastApi/Starlette are web frameworks only and limited to http and websocket events they don't provide pre-built event handlers for any specific database events.
While FastAPI doesn't support general event dispatching, there are libraries available to supplement this. The one I've been using is fastapi-events (Disclaimer: I'm the maintainer)
Events can be dispatched by using dispatch("event name", {"payload": "here"})
The handling of events can be done either within the code, or be forwarded to a remote queue.
Related
I normally develop with ASP.NET MVC, but I'm very new to Blazor. I'm creating a new site in Blazor WebAssembly. The very first thing I need to do is create a page with a simple form, that can create or update an item and send it to the server, to be saved in the DB. I can either send the object using SignalR, or use HttpClient to post it to a controller action. What's the best practice here in Blazor Wasm? I was tempted at first to just use SignalR all the time.
I've seen examples of using both, but very little to help decide which to use in what circumstances. This was about the most useful thing I could find but it doesn't answer the exact question and it's also not specific to Blazor.
The question is specifically about the simple create update operation, but other pros and cons of both would be very helpful. Is it as simple as "only use SignalR when clients need to listen for messages from the server, to avoid having too many open connections"?
Thanks a lot
Is it as simple as "only use SignalR when clients need to listen for messages from the server, to avoid having too many open connections"?
Yes, I think it is. CRUDL operations are transactional and asynchronous. Do a transaction, wait forever on the user, do another transaction,.... I would always do these through an API Get/Post.
The only time I would consider SignalR is where I'm passing object defined objects - such as a Dictionary<string, object>. They are a pain in controller API calls.
Using grpc c++‘s async server api, should I add one cq per rpc method or just one cq for all service?
I am taking over a grpc c++ service in my job. it use 10 completionqueue for a async service method , and yet another 20 completionqueue for another stream service method. The handling of the completionqueue is quite similar to the helloworld async service example, except that it use one thread worker per completionqueue.
Such a design is not very convenient for adding more service method. And I am thinking that refactoring it to using just one completionqueue, and dispatching the tags in the completionqueue to my own domain transactions handling thread pool.
Is it the right design pattern, or is there something better?
The best way to know the answer for your specific application is to create benchmarks with various scenarios and then compare the results from the different threading models.
Based on https://grpc.github.io/grpc/cpp/md_doc_cpp_perf_notes.html, the current recommendation is to use a pool of num_cpus threads with each thread polling over its own completion queue.
I want to publish an event through one of my aggregate event handlers to the axon Kafka topic as I am using kafka as my event bus. What is the correct way to do that? Should I directly push the message to the topic or can I use AggregateLifecycle#apply(event) in this case?
I have multiple events getting published from my aggregate, through one of the event handlers I want to publish another event. I am using axon 4.2
Easiest would be to start using the Kafka Extension Axon provides. The shared repository contains all the necessary code to create a publishing end and a consuming end of Axon Event from and to a Kafka topic. For configuration convenience, there is a Spring Boot Starter present in that project too
Added, the repository has a (Kotlin) sample project showing how to configure it, which you can find here. Lastly, for a full description of how to set everything up, I strongly recommend to give Axon's Reference Guide a read, especially the Kafka page here.
I'd like to recommend you thought that this extension is perfectly suited to communicate between Axon and non-Axon applications, making Kafka a form of "Enterprise Service Bus". Using it as the EventBus replacement within Axon Framework is doable, but requires a bunch of fine tuning on you rend. It would be wiser to use Axon Server instead in those scenarios, or if you really must, share the data source containing your events directly between the applications.
I'm using Axon version (3.3) which seamlessly supports Kafka with annotation in the SpringBoot Main class using
#SpringBootApplication(exclude = KafkaAutoConfiguration.class)
In our use case, the command side microservice need to pick message from kafka topic rather than we expose it as Rest api. It will store the event in event store and then move it to another kafka topic for query side microservice to consume.
Since KafkaAutoCOnfiguration is disabled, I cannot use spring-kafka configuration to write a consumer. How can I consume a normal message in Axon?
I tried writing a normal Kafka spring Consumer but since Kafka Auto COnfiguration is disabled, initial trigger for the command is not picked up from the Kafka topic
I think I can help you out with this.
The Axon Kafka Extension is solely meant for Events.
Thus, it is not intended to dispatch Commands or Queries from one node to another.
This is very intentionally, as Event messages have different routing needs apposed to Command and Query messages.
Axon views Kafka a fine fit as an Event Bus and as such this is supported through the framework.
It is however not ideal for Command messages (should be routed to a single handler, always) or Query messages (can be routed to a single handler, several handlers or have a subscription model).
Thus, I you'd want to "abuse" Kafka for different types of messages in conjunction with Axon, you will have to write your own component/service for it.
I would however stick to the messaging paradigm and separate these concerns.
For far increasing simplicity when routing messages between Axon applications, I'd highly recommend trying out Axon Server.
Additionally, here you can hear/see Allard Buijze point out the different routing needs per message type (thus the reason why Axon's Kafka Extension only deals with Event messages).
I'm implementing a Core Service "Facade" for some lazy programmers that don't want to change their coding style (me included), and wanted to implement object cache, which obviously leads to the grand question of "how long and how much should I cache".
The ideal answer is to cache forever except when data is changed.
Is there a way (via some WCF event perhaps) to implement a "listener" for data changes that could be used to remove items from their cache?
BTW, I am using .NET's native ObjectCache (MemoryCache) with a 1 minute sliding cache policy for now.
Thanks,
N
There is no such system built-into either WCF or Tridion that I know of.
You could of course roll your own, where you:
Listen for changes to the relevant data on the TCM server with Event Handlers
Have those event handlers forward the event to a central notification server
Have your WCF clients register with that notification server when they start up
Have notification server subsequently send the notifications on to the connected clients
This is essentially quite similar to how Tridion's Broker Object Cache works on the Content Delivery tier.
If you're interested in implementing such an approach, I'd suggest having a look at the Signalr project, which takes a lot of the hassle out of it.
Edit: it turns out WCF has something akin to what you're asking for called Callbacks. See this question and this blog post.