FAQ
Note there is an alternative solution with event sourcing.

Basically you have a recorded stream of critical events:

// client sends a
ClientMadeOffer

// seller listens to new events directed at him and responds
SellerAcceptedOffer
SellerRejectedOffer

// exchange completes the transaction, Client/Seller both listen to:
OfferFailed
OfferSucceeded

To build up a product list:
SellerRegisterProduct
SellerUnregisterProduct

Client and Seller can both listen and fetch the whole stream as necessary.
(Obviously filtering out any events not-directed to them for security and
performance.)

You can implement the event streams over a single DB table where a
goroutine continously polls it and sends the responses to the
client/seller. It's a stupid way to implement an event store, but it works.
If you want something better see https://geteventstore.com/.

+ Egon
On Friday, 20 May 2016 17:44:37 UTC+3, Egon wrote:

The simplest implementation: https://play.golang.org/p/FRHggU2E2H (lots
of TODO-s and always develop it with -race).

Implement the Client/Seller interface however you wish and they should
call methods on Exchange. e.g. Client/Seller connects via a socket and
registers ... and unregisters when disconnects. Alternatively Client makes
a HTTP request to register and another request to product list and another
request to make an offer and finally request to receive any completed or
failed responses.

I'm not saying it's the best solution (e.g. doesn't handle crashes, it
doesn't scale), but it's probably the easiest to understand. Once you
understand it, you probably can build upon it, e.g. add a database instead
of using in-memory lists. I suspect
http://www.greenteapress.com/semaphores/ will be helpful (both the book
and video).

+ Egon
On Friday, 20 May 2016 16:39:40 UTC+3, Maxime Guittet wrote:

Currently in dev of the API for my company, I have to make an API to sned
some data to my Xamarin client. A part of the API is to make communicate a
client with a "seller" which provide the service. The seller registers
himself to a list of available seller and then wait a client. However,
first problem: *Do I have to make an infinite request and then wait a
client? Or it's better to just open a socket?*. After a client is
interested, the command begin but at a moment, the both will have to speak
together.. So I though about make request but because I don't know in which
sens will be the exchange, I think it's to hard and then a "Socket" would
be the better way to handle it.

Now I have a second problem that I don't understand: *How can I have 2
server at the same time? I mean, I need a server/API but I also need a
socket, so how can I handle the second listener?*

It's my first API and honestly, I'm totaly stuck. I already though to
stock each socket in the related seller elem (in my dynamic list), but my
client aren't in a special list, they just ask for services, then an
exchange of request begin, but at the end I need communication and I can't
imagine the logic in my little mind..

This is the logic of the exchange:


<https://lh3.googleusercontent.com/-5eBOxC2vvBE/Vz8Jwpm8NWI/AAAAAAAAIF4/3B-2kqogoVw7OoHMoi-0734jiMHYjBDVQCLcB/s1600/PHyjH.png>
But this way isn't the best, in first for the notifications part... I
think I'm totaly lost and my API isn't right about the logic..

I think it would be better if the seller just registers itself with and
open a socket, then when a client ask and get the list of seller, it
chooses one and the communication switchs instantly by the socket. However
for me, it brings one more time a new problem: *Because the socket
cannot be opened between two client (client/seller), I have to pass by the
server, but how to organize that part of the API? Do I have to send to each
one a listener as HttpAnswer or they have to make a request with a "token"
to create a new channel or something like that?*

Maybe I'm not logic and I think so, but at the moment, I'm totally stuck
and not really sure about what I do and what I have to do..

Need help please
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 3 | next ›
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMay 20, '16 at 1:39p
activeMay 20, '16 at 3:17p
posts3
users2
websitegolang.org

2 users in discussion

Egon: 2 posts Maxime Guittet Fr: 1 post

People

Translate

site design / logo © 2021 Grokbase