ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: New thin client and interfaces/facades
Date Tue, 12 Sep 2017 17:55:36 GMT
+1 one for the first approach. The users will start with a documentation page where we can
define in a table format the scope of supported APIs.

—
Denis

> On Sep 12, 2017, at 3:06 AM, Pavel Tupitsyn <ptupitsyn@apache.org> wrote:
> 
> I prefer the first approach.
> Users can easily switch to client mode, run their code and see what works
> and what not.
> 
> Second approach may require huge amount of refactoring to even try the
> client mode.
> And new users have to make a tough choice, because switching later is hard.
> 
> 
> As a middle ground we can introduce a separate top-level interface,
> IgniteClient,
> but re-use other interfaces when possible.
> 
> For example, first iteration of our thin client will likely include most
> cache operations in 2.3,
> so we can re-use IgniteCache interface.
> But IgniteClient will only include getCache() and getBinary() methods.
> 
> This way it is still reasonably easy for users to switch between APIs,
> and Unsopported exceptions are kept to a minimum.
> 
> Pavel
> 
> On Tue, Sep 12, 2017 at 12:42 PM, Vladimir Ozerov <vozerov@gridgain.com>
> wrote:
> 
>> Igniters,
>> 
>> We are developing new thin client. There are two approaches on how to
>> design it's interfaces - either re-use existing Ignite interfaces, or
>> define new.  Both approaches has pros and cons
>> 
>> *1) Re-use interfaces*
>> This approach is used in Hazelcast. Both server and client share the same
>> API.
>> 
>> Pros:
>> - excellent UX, switching from server to client is a matter of changing
>> several lines of code
>> Cons:
>> - first versions of our client would have very limited API support, so
>> users would have wrong impression that client is very rich, while in
>> reality most methods will throw "UnsupportedOperationException". This is
>> frustrating.
>> - Client and server interfaces will be locked forever, which might not be
>> appropriate in certain cases. E.g. thin client might decide to execute
>> "ComputeTask" inside the cluster, but ComputeTasl is not Serializable, so
>> it cannot be re-used.
>> 
>> *2) Separate interfaces*
>> E.g. we will have "IgniteCache" and "IgniteClientCache", "IgniteCompute"
>> and "IgniteClientCompute", etc.
>> 
>> Pros:
>> - Only really supported stuff is exposed to API
>> Cons:
>> - Separate code for thin client and (server, thick client) modes
>> 
>> I would definitely prefer the first approach with shared interfaces, but a
>> lot "UnsupportedOperationException" in the first versions scares me.
>> 
>> What do you think?
>> 
>> Vladimir.
>> 


Mime
View raw message