kafka-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From adrien ruffie <adriennolar...@hotmail.fr>
Subject RE: Suggestion over architecture
Date Sat, 10 Mar 2018 19:32:34 GMT
Don't worry :-) I understood. Thank a lot !


Adrien

________________________________
De : Svante Karlsson <svante.karlsson@csi.se>
Envoyé : samedi 10 mars 2018 20:16:10
À : users@kafka.apache.org
Objet : Re: Suggestion over architecture

Yes, but I misread his reply and thought that he meant the "kafka rest
proxy". But now I see that we say the same thing - sorry for the confusion.

The normal way to do the authentication and authorization would  be in the
rest/grpc endpoint before sending it to kafka.

2018-03-10 19:39 GMT+01:00 adrien ruffie <adriennolarsen@hotmail.fr>:

> Thank Nick, thank Svante,
>
>
> Svante, you say like Nick right ? Send a client message type which
> encapsulates the emailing to a REST endpoint in our infrastructure and the
> endpoint
>
> push into a kafka's topic ?
>
> And if we need to ensure that client which send any emailing is allowed,
> where you potentially check is authorization ? After message reception on
> the REST endpoint ? Directly by the sender in on premise webapp ? Ok before
> push the topic ? I think it's really better to check that before sending
> message to our infrastructure side, but the webapp is unaware if it allowed
> or not ...
>
>
>
> thank for your reply 😊
>
> Adrien
>
> ________________________________
> De : Svante Karlsson <svante.karlsson@csi.se>
> Envoyé : samedi 10 mars 2018 19:13:04
> À : users@kafka.apache.org
> Objet : Re: Suggestion over architecture
>
> You do not want to expose the kafka instance to your different clients. put
> some api endpoint between. rest/grpc or whatever.
>
> 2018-03-10 19:01 GMT+01:00 Nick Vasilyev <nick.vasilyev1@gmail.com>:
>
> > Hard to say without more info, but why not just deploy something like a
> > REST api and expose it to your clients, they will send the data to the
> api
> > and it will in turn feed the Kafka  topic.
> >
> > You will minimize coupling and be able to scale / upgrade easier.
> >
> > On Mar 10, 2018 2:47 AM, "adrien ruffie" <adriennolarsen@hotmail.fr>
> > wrote:
> >
> > > Hello all,
> > >
> > >
> > > in my company we plan to set up the following architecture for our
> > client:
> > >
> > >
> > > An internal kafka cluster in our company, and deploy a webapp (our
> > > software solution) on premise for our clients.
> > >
> > >
> > > We think to create one producer by "webapp" client in order to push in
> a
> > > global topic (in our kafka) an message which represent an email.
> > >
> > >
> > > The idea behind this, is to unload the client webapp to process several
> > > mass mailing operation groups, and treat them ourselves with
> > >
> > > dedicateds servers into our infrastructure. And each dedicated server
> > will
> > > be a topic's consumer where the message(email) will be streamed.
> > >
> > >
> > > My main question is, do you think, that each client can be a producer ?
> > > (if we have for example 200/300 clients ?)
> > >
> > > Second question, each client should be a producer ? 😊
> > >
> > > Do you have another idea for this subject ?
> > >
> > >
> > > Thank you & best regards.
> > >
> > >
> > > Adrien
> > >
> >
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message