ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Tupitsyn <ptupit...@apache.org>
Subject Re: New thin client and interfaces/facades
Date Tue, 12 Sep 2017 10:06:46 GMT
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,
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.


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message