I've been looking at the event driven architecture and it's seems it might be the right architecture for a project I'm working on.
But there is one thing I don't really get yet, what is the best practice/common pattern when your micro services are being consumed by front-end applications?
For my project, I have a web app and an iOS and Android app.
Let's take a simple case of a feature letting users create their profile.
Let's say I send the profile data via REST/GraphQL to the api endpoint which triggers microservices (running behind Kafka or Pulsar).
How can I get the result of the profile creation and then maybe use it on the next screen?
Cheers
websocket calls to Pulsar will do most of what you want https://pulsar.apache.org/docs/en/client-libraries-websocket/
You could also call Apache Pulsar via MQTT which is not too uncommon from cell phones.
Or use a REST gateway or microservice between the app and Pulsar services. I use Apache NiFi for that.
Related
I know some basic programming languages but im new at using API's.
Can someone please explain how, or where do i run my API's codes?
Will the API's be run on the website i'm trying to get my data from or can it be run on a client or from another different running environment or platform?
Apis should only (I say "should" because I am not sure that something like this can be done on the client side) to run on the server.
when you get information from an api you are not executing it on the client. you are only getting the data you requested for the endpoints you used.
Do you plan to use REST APIs as a consumer or producer? That is, do you want to expose your data, systems and processes as resources for an end consumer, or do you want to be the consumer creating applications that leverage services?
The Producer
To produce REST APIs, you'll need to run your API providers using a web server. Just about any web server will do, so long as it can map resource paths to functions. Some common ones are:
Node.JS with Express.js
Nginx with Python/Flask
Java using Spring
You should be able to run whatever you chose on nearly any hosting provider, cloud VM or wherever else you usually run websites.
The Consumer
You can use Rest APIs anywhere you have network connectivity. You'll find this commonly in mobile applications, web applications, IoT devices, etc where data are combined from multiple providers on to a single application for end users. The key feature as a consumer you'll be looking for is a directory of API providers from which you can build your application.
ProgrammableWeb maintains one such list.
Need to develop a rest API which can read published messages from kafka cluster to a dataware house application.
Materials available over internet say use POST/GET commands , but i don't think this is for production use rather useful for testing purposes.
How to implement it in scala/ Java Programming?
Materials available over internet say use POST/GET commands , but i don't think this is for production use rather useful for testing purposes
Please link to where you read this... All production web-services operate over (more than) these two HTTP methods, hundreds of thousands times a day...
If you want to really use Kafka for throughput, though, you wouldn't "hide it" behind a REST interface, though. You would distribute SSL certs plus usernames+passwords, to remote clients, for example.
Need to develop a rest API which can read publish messages from kafka
REST is not meant to keep an open connection, primarily because it is stateless (it shouldn't maintain where you are reading from in Kafka)... It would make more sense to forward a websocket from a Kafka consumer, which is different from a REST API.
how to implement it in scala/ Java Programming
The Confluent REST Proxy is already written in Java, and it is open-source (and used in Production at several companies, I believe). If you need inspiration, then you can start there. Otherwise, you can find examples of Spring and Vert.x, for example, with their Kafka integrations in their respective documentations, but you'll be re-implementing a lot of the existing functionality.
I understand (somewhat) what are differences between monolithic , microservices .
And also what is SOA it is a service consumer/provider architecture and microservice is subset of SOA. and they use Restfull/SOAP APIs to communicate.
So when a a request something he/she does using Rest/SOAP API but how in a Monolithic architecture a client request through which API? I searched all the links/blogs on google, videos on youtube but still I am not clear about this.
Or may be my whole understanding is not correct.
Sounds like you are a bit confused, I would really recommend you picking up a book on the subject.
Monolithic vs micoservice application is more about how you package and deploy your application and in some sense how coupled modules/subsystems are. The extreme example: you always deploy the entire monolithic applications for the smallest possible change, and in the microservice example you just need to make the same change to one service.
Rest API and SOAP are protocols for how (http) messages are passed between client <-> server and has nothing to do with monolithic vs micro.
Monolithic application can of course have public http API's, and it might not be possible for a user (sending request) of that API to tell the architecture style of that application. And why would she care about that?
I think this is a nice start: https://martinfowler.com/articles/microservices.html
I'm looking to develop a blackberry application to consume a RESTful service. At the moment we plan to develop a REST layer which we will use to perform searches on a back end database and return the results as JSON.
I have used the Jersey framework ( http://jersey.java.net/ ) for consuming (and developing) REST layers in the past.
This is the first time we plan to develop such an app for a blackberry. From looking around I'm not sure if jersey is supported on the blackberry for consuming RESTful services.
So I'm wondering could someone offer some advice (on jersey or any other purpose built JARs) for using RESTful services on Blackberry? Otherwise we will have to build from scratch the code for consuming the RESTFul service. Or even use SOAP which I prefer not to have to do if possible.
Thanks,
John
Take a look at the JSON.org website, they have lib in Java to parse JSON data(I'v manage to make it work for BlackBerry without to much modifications.
The only thing left to do is a connection to the web service by passing the parameter you need to it. And then parse the response with the JSON lib to rebuild your data model in your native client.
And please don't use SOAP for mobile application.
Please read RIM doc for socket
You can use a httpConnection too
With Pusher and Beacon push cloud services I can get live updates in all browsers. Even implement chat functionality.
Can't these cloud services replace the need of me learning XMPP/AMQP/Websockets/Comet to implement the same kind of live updates/feeds?
These services offer Infrastructure as a Service so that you don't have to worry about the underlying technology. That said the services do use the technology as a selling point e.g. Pusher very much use WebSockets to sell their service.
As well as Pusher there are similar services so I'd recommend checking out the real-time tech guide for others that haven't been mentioned (I work for Pusher).
Can't these cloud services replace the need of me learning XMPP/AMQP/Websockets/Comet to implement the same kind of live updates/feeds?
Yes. The point in these frameworks and services is to abstract away the underlying connection and protocols to provide you with a reasonable real-time communication pattern (simple messaging, pub-sub, evented pub-sub, RPC/RMI or DataSync) that works for the application functionality that you are looking to build.