New thin client and interfaces/facades

[Vladimir Ozerov <vo...@gridgain.com>]

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.

Re: New thin client and interfaces/facades

[Dmitriy Setrakyan <ds...@apache.org>]

Vladimir,

I disagree. We already have client mode which support the full Ignite API.

Here we are talking about the new client binary protocol. To my knowledge,
the following APIs can be implemented over the new binary protocol:

- JDBC
- ODBC
- REST
- .NET Thin

All these protocols are already custom APIs. I would not migrate any other
existing clients to the new binary protocol, unless we see possible use
cases for it.

I am for the 2nd approach, where every implementation of some API over the
client binary protocol is custom to some use case.

D.

On Tue, Sep 12, 2017 at 2:42 AM, Vladimir Ozerov <vo...@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.
>

Re: New thin client and interfaces/facades

[Denis Magda <dm...@apache.org>]

+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 <pt...@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 <vo...@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.
>> 

Re: New thin client and interfaces/facades

[Pavel Tupitsyn <pt...@apache.org>]

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 <vo...@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.
>