I am trying the following scenario -
Build a Get products API in API Connect, which will invoke multiple back-end micro APIs and Web Services like product info, inventory, image lists, product reviews etc., and aggregate the response.
Is there a way to make these calls in parallel (asynchronously), to reduce overall latency?
This can be done using the LoopBack Framework, which is also part of API Connect.
This use case has been discussed here: https://groups.google.com/forum/#!topic/loopbackjs/39VI8apSsPM
Related
I am building a microservice application, and I try to follow the best practices. I use event sourcing and event driven state transfer in many places, but I realized that sometimes I just need to call another service in an asynchronous way to kindly ask it to do something e.g. send out a registration email (as the email service is a technical component and not a domain). I noticed that many times, services just call the other's service API endpoint, but that wouldn't be asynchronous. As I don't expect any returned value when calling from another service, the command would only produce events, RPC is not necessary.
In the end, my plan is to implement commands/actions that can be triggered by clients from REST API (then the commands may also produce responses) or by events or other services from RabbitMQ or similar. This leads me to how should I define the data structure of the command/action, is there any specification for that? Or existing solutions for Python? Or should I do something differently?
I am looking in to how to use API gateway in my project. My current API gateway pattern idea is to create a layer of composite APIs calling multiple APIs, and expose the composite APIs through the API gateway.
Researching elsewhere, I've found that it is not recommended to create composite APIs if using an API gateway, but rather that composition should happen in the API gateway itself. But if I need to do the composition in API gateway, doesn't that mean that I need to expose some domain logic there, because would I need to construct a meaningful request contract and possibly a sequence of calling APIs? Personally, I don't feel comfortable doing that.
Is there other way to do this without exposing some logic?
From what I research, it is not recommended to create composite API if using API gateway but composition should happen in the API gateway itself.
could you refer where did you find the statement?
IMHO the service composition is not task of the api gateway. It's task of n integration layer (you don't need to have a separate esb product or service, under integration lyer you can understand any services or service layer implementing the capabilities, such as composition, transformation, etc)
You did not specify any api product or service, it depends on the product if it is capable to execute any logic or not (some do, some some don't). Even if the api gateway product is capable of executing any logic, indeed I don't recommend it either (you will have to fight with maintenance, error and state handling,..)
But if I need to do the composition in API gateway, doesn't it means that I need to expose some domain logic there
(personally, I don't feel comfortable doing that) because I need to construct a meaningful request contract and possibly sequence of calling APIs?
what do you mean by composition in API gateway? I assume under the term executing some logic. Then the logic is hidden from the api clients.
Or could it be layer of composite API sounds better?
Indeed.
Generally try to treat an api gateway as a smart proxy (doing authorization, throttling, client facing api store,..) but the exposed backend services should be already exposed as they are
Alright, A friend and I are developing an App where I'm developing the back-end and he is developing the front-end. The project is separated into two repositories the front-end and the back-end, and we need to implement a payment API.
Now, since we're using the REST API Concept, we communicate both ends through JSON data.
My question is, when we're making the connection to the payment API, who needs to execute that request? The front-end or the back-end?
I know it's a silly question, but first timer here.
The backend will obviously process the payment, I'm not sure which payment API you're going to use. But depending on the API you go with, the implementation will vary. But the actual processing of the payment will be processed in the backend for sure.
It completely depends on the API.
In some cases, a payment can be accomplished via a secure web service call, which would be issued by your friend's REST service. The front end will still need to collect data (e.g. payment amount and card number) and may also need to collect additional information to satisfy the API (e.g. IP address or browser signature, for risk management purposes).
In other cases, the payment is sent directly to the service from the browser. The role of your application would be to render an iFrame housing a page that is reached via SSO. The back end may need to call a service to retrieve an SSO token, or may have to compute an SSO token using a shared key.
You should probably refer to the payment API's documentation. They often have very specific guidance which you must follow carefully in order to achieve payment card (PCI-DSS) compliance. There is nothing special about "payments" that says that allows StackOverflow users to guess anything about its API.
I'm new to IBM BPM. I'm trying to create a web service for a class i'm taking but the instructor/site architect is unavailable at the moment.
Is there some way to determine the different types of RESTful calls available at a particular IBM BPM url?
My understanding is, that you would like to see which calls are supported by the IBM BPM REST API, is this correct?
You can discover the calls via the REST API Tester which can be found by the following URL:
http://{host}:{port}/bpmrest-ui
In this web-interface you can see different REST APIs, calls and you can build your own rest services with the provided input forms.
Source and further documentation: http://www.ibm.com/developerworks/websphere/library/techarticles/1108_thaker/1108_thaker.html
I have been given access to a real time data feed which provides location information, and I would like to build a website around this, but I am a little unsure on what architecture to use to achieve my needs.
Unfortunately the feed I have access to will only allow a single connection per IP address, therefore building a website that talks directly to the feed is out - as each user would generate a new request, which would be rejected. It would also be desirable to perform some pre-processing on the data, so I guess I will need some kind of back end which retrieves the data, processes it, then makes it available to a website.
From a front end connection perspective, web services sounds like it may work, but would this also create multiple connections to the feed for each user? I would also like the back end connection to be persistent, so that data is retrieved and processed even when the site is not being visited, I believe IIS will recycle web services and websites when they are idle?
I would like to keep the design fairly flexible - in future I will be adding some mobile clients, so the API needs to support remote connections.
The simple solution would have been to log all the processed data to a database, which could then be picked up by the website, but this loses the real-time aspect of the data. Ideally I would be looking to push the data to the website every time the data changes or now data is received.
What is the best way of achieving this, and what technologies are there out there that may assist here? Comet architecture sounds close to what I need, but that would require building a back end that can handle multiple web based queries at once, which seems like quite a task.
Ideally I would be looking for a C# / ASP.NET based solution with Javascript client side, although I guess this question is more based on architecture and concepts than technological implementations of these.
Thanks in advance for all advice!
Realtime Data Consumer
The simplest solution would seem to be having one component that is dedicated to reading the realtime feed. It could then publish the received data on to a queue (or multiple queues) for consumption by other components within your architecture.
This component (A) would be a standalone process, maybe a service.
Queue consumers
The queue(s) can be read by:
a component (B) dedicated to persisting data for future retrieval or querying. If the amount of data is large you could add more components that read from the persistence queue.
a component (C) that publishes the data directly to any connected subscribers. It could also do some processing, but if you are looking at doing large amounts of processing you may need multiple components that perform this task.
Realtime web technology components (D)
If you are using a .NET stack then it seems like SignalR is getting the most traction. You could also look at XSockets (there are more options in my realtime web tech guide. Just search for '.NET'.
You'll want to use signalR to manage subscriptions and then to publish messages to registered client (PubSub - this SO post seems relevant, maybe you can ask for a bit more info).
You could also look at offloading the PubSub component to a hosted service such as Pusher, who I work for. This will handle managing subscriptions and component C would just need to publish data to an appropriate channel. There are other options all listed in the realtime web tech guide.
All these components come with a JavaScript library.
Summary
Components:
A - .NET service - that publishes info to queue(s)
Queues - MSMQ, NServiceBus etc.
B - Could also be a simple .NET service that reads a queue.
C - this really depends on D since some realtime web technologies will be able to directly integrate. But it could also just be a simple .NET service that reads a queue.
D - Realtime web technology that offers a simple way of routing information to subscribers (PubSub).
If you provide any more info I'll update my answer.
A good solution to this would be something like http://rubyeventmachine.com/ or http://nodejs.org/ . It's not asp.net, but it can easily solve the issue of distributing real time data to other users. Since user connections, subscriptions and broadcasting to channels are built in to each, that will make coding the rest super simple. Your clients would just connect over standard tcp.
If you needed clients to poll for updates then you would need a que system to store info for the next request. That could be a simple array, or a more complicated que system depending on your requirements and number of users.
There may be solutions for .net that I am not aware of that do the same thing, but those are the 2 I know of.