tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/38-service-with-a-large-apiRobotlegs: Discussion 2018-10-18T16:35:41Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/171782822012-07-12T09:34:41Z2012-07-12T09:34:41ZService with a Large API<div><p>Hi Kerry,</p>
<p>I don’t have enough time these days to get into details on
the subject, but I notified Stray and Shaun, and hopefully if they
aren’t too busy you’ll get an answer :) I’ll also
tweet your question.</p>
<p>Anyway, I’d say yes to making an interface for your
services.</p>
<p>Cheers,<br>
Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/171782822012-07-12T11:14:04Z2012-07-12T11:14:04ZService with a Large API<div><p>in the scenario of hitting a large API from a service then I
would probably have multiple service classes handling specific
logic, not necessarily a service class per method more like a
service class which would handle say the client API, then a service
class to handle the room API etc (I am not familiar with the smart
fox API). This will hopefully enable you to have a tighter focus on
parsers used on a service class basis.</p>
<p>Next I would consider one of two routes for the parsing, I would
either:</p>
<p>1) Inject your specific parsers into the service class and then
choose which parser to use based on the method based on the api
response.</p>
<p>2) Have your service class method dispatch the response in an
event or signal which will then be process by some sort of factory
class. So maybe a command who's sole responsibility is to receive
the response data, parse it and then distribute the result data in
the appropriate format via a signal or event.</p>
<p>Cheers,</p>
<p>Simon</p></div>simontag:robotlegs.tenderapp.com,2009-10-18:Comment/171782822012-07-12T12:53:24Z2012-07-12T13:38:28ZService with a Large API<div><p>@Ondina Thanks! Also, the only reason I asked about making the
API for smartfox server was because I was thinking that the API was
pretty specific to SFS so it wouldn't easily be swapped out for
another service anyway. Then it occurred to me that even if I will
probably never use a different Multiplayer Server other than
SmartFox, at least I could then create a new test class to mimic
the server and easily swap that in and out.</p>
<p>@simon Appreciate the suggestions! Let's see if I understand you
correctly. You're saying that I should break the SFS API up into
smaller chunks (by creating an intermediary class? Using your
example I should create a class called SFSRoomService which gets
injected with a SFS instance but only exposes the functions that
deal with the room?)</p>
<p>Thanks for the help. I'm learning a lot. May take a while though
since I'm not really a hardcore programmer.</p>
<p>EDIT: 'the only reason I asked about making the API for smartfox
server'; i meant interface, not API</p></div>kerry.kim.russotag:robotlegs.tenderapp.com,2009-10-18:Comment/171782822012-07-12T13:35:09Z2012-07-12T13:35:09ZService with a Large API<div><p>Yes exactly. Not knowing how the SFS works I would guess your
simply hitting the api through a REST api or something similar so
you would only need to either inject or pass in the actual SFS url
no?</p></div>simontag:robotlegs.tenderapp.com,2009-10-18:Comment/171782822012-07-12T13:43:51Z2012-07-12T13:44:08ZService with a Large API<div><p>SFS is actually a socket connection. So maybe it's not
technically a web service since most of the time it's pushing data
rather than being asked for data. Maybe that changes everything???
I figured it still fell under the S in MVCS. I'm actually pretty
new to SFS as well so excuse my lack of knowledge on it.</p></div>kerry.kim.russotag:robotlegs.tenderapp.com,2009-10-18:Comment/171782822012-07-12T13:45:01Z2012-07-12T13:45:01ZService with a Large API<div><p>I don't see much of a difference in how you would handle this
either way to<br>
be honest.</p></div>simontag:robotlegs.tenderapp.com,2009-10-18:Comment/171782822012-07-12T13:59:04Z2012-07-12T13:59:04ZService with a Large API<div><p>You mean in regards to injecting the URL? I could certainly
inject the ip address and socket into my SFS client class but would
only want one instance of the client to be injected into all of the
surrounding service classes.</p></div>kerry.kim.russotag:robotlegs.tenderapp.com,2009-10-18:Comment/171782822012-07-13T11:06:41Z2012-07-13T11:06:41ZService with a Large API<div><p>Whenever you integrate with a 3rd-party API you should wrap that
API in an "anti corruption layer". This ensures that your
application is coded against an API that <em>you</em> control. When
the underlying 3rd-party API changes you only need to change your
wrapper. In most cases the surface area of your wrapper API is much
smaller than the full 3rd-party API.</p>
<p>Once you've done that you can inject your new service (the
wrapper) into other, higher level (application specific) services.
For example:</p>
<p>Wrapper (psuedo code):</p>
<pre>
<code>IRestService
function post(url, params):Token
function get(url, params):Token
function put(url, params):Token
function del(url, params):Token</code>
</pre>
<p>User Service:</p>
<pre>
<code>UserService ( restService:IRestService )
createUser(params):Token
-> return restService.post('/users', params);
loadUser(id:String):Token
-> return restService.get('/users/' + id);
updateUser(id:String, params):Token
-> return restService.put('/users/'+id, params);
deleteUser(id:String):Token
-> return restService.del('/users/' + id);</code>
</pre>
<p>The RestService deals with low level details - it is the anti
corruption layer. It is injected into the UserService. The
UserService is higher level, and delegates operations through to
the RestService. The IRestService is an interface, so multiple
implementations could exist (JSON, XML, Socket, CSV, YAML etc). You
can swap out the implementation without affecting any of your
higher level services as all they care about is the interface.</p>
<p>Hope that helps!</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/171782822012-07-13T12:33:54Z2012-07-13T12:33:54ZService with a Large API<div><p>That clears things up a lot! Thanks!</p></div>kerry.kim.russo