Why Couchbase team still doesn't support React Native?

The only unofficial RN plugin has clear disclaimer “This package is not an official couchbase plugin and is not supported in any way by couchbase” and seems to be semi-abandoned:

  • CBL version 1.3 (while 1.4 is already out there for long time and 2.0 is coming)
  • poor (at some point - unusable) documentation: look at last screenshot on their frontpage (/{db}}/_bulk_docs endpoint) - there is just lazy copypaste of swagger html garbage. That’s documentation.
  • attachments don’t work (at all)
  • CORS bug
  • iOS emulator crash bug
    = these critical bug issues are there for more than year already

Really guys, RN sector is expanding rapidly and probably there is no reason for Couchbase to abandon this promising market leaving it on unofficial poor support. There are plenty devs who choose RN as a way to not bother with native iOS/Android stuff, and probably you want those crowds to choose tomorrow namely CBL as mobile persistence/sync. Or do I miss something?

1 Like

@greenais,

There are some recent commits to it.

The phone gap one is also active.

" Although this package does work as described it may not be fully featured and may not be suitable for your requirements."

Are there certain features that you are looking for?

@househippo
Thank you for prompt reply.
Yes, there are - all mentioned in my post. First of all - documentation, working attachments and crash in iOS simulator. Upgrade to the most actual 1.4 would be great as well.

In fact there is lack of actual howtos/tutors for RN devs, those existing in couchbase blog are obsolete (and probably should be deleted to avoid mess in minds). To my point that (along with above mentioned issues of still unofficial module) prevents plenty of RN devs from using CBL in their projects.

Probably for RN world it will be quite enough to expose REST end-point to RN and use fetch requests (as REST is quite well-documented officially by couchbase) instead of bothering with this swagger stuff ending with copypasted crap as “documentation”, but couchbase to decide.

Your point is well taken and we are definitely not “abandoning” this market. We recognize the importance of native and cross-platform/hybrid apps - For instance, we officially do support Xamarin

  • For 1.x, while not ideal, the REST API is available an option for cross-platform/hybrid app developers. The swagger client is one possible way to simplify the development of the REST client that talks to this interface. You are free to directly use the REST API if that simplifies your needs

  • For 2.x, We are evaluating options for JS cross-platform/hybrid app support in CBL 2.x - It won’t be available in 2.0 though . But curious - as a ReactNative developer, what are your impressions on directly using a REST API to use within your React Native client?

1 Like

That’s good statement but facts speak completely opposite point - RN module is unofficial
and as consequeences:

  • Critical issues stay unresolved for more than one YEAR
  • Old version
  • Poor documentation

Phone Gap or Xamarin activities obviously don’t make RN devs somehow supported.

REST API access from within RN isn’t officially documented elsewhere, am I really free to use?
Quite extensive hacking is needed to just get appropriate API url first and then authorization issues …

Again to my point, all above makes entry level for wide range of RN devs quite high, probably forcing them to use another more documented and supported sync/persistence solutions.

Don’t take me wrong, I see Couchbase, GS and CBL as great solutions (otherwise I won’t spend my time here trying to help Couchbase), but I don’t understand reasons why you at Couchbase don’t take React Native serious. To my understanding that’s probably improvident, but it’s Couchbase to decide.

It works well for me with query/View requests (as long as swagger client has a total crap docs on it unlike REST API ones), but doesn’t work for server/sync requests (as REST API is poor documented here in terms of authorization). So I have to use both at the moment - swagger manager and REST API. But again, accessing REST API from RN was a hacking journey, i.e. url returned by Couchbase.init (btw also not documented elsewhere) didn’t let me authorize against REST end-point, so I had to find way to get working url first, etc.

Our mobile team does not have infinite resources, and it takes a lot of work to add support for a platform — development, QE, release engineering, documentation, support, etc. We’re already supporting iOS, macOS, tvOS, and Android, as well as Java and .NET on a number of platforms including Windows, Linux and iOS/Android. And PhoneGap on iOS/Android too.

We aren’t “abandoning” ReactNative; we’ve never claimed to support it. I personally would love us to support it, but I’m not in management. I totally understand your desire to have RN support for CBL, but it would be more productive to frame your posts as evangelism than as complaints.

1 Like

I’m working on a fork of the react-native-couchbase-lite module by Upinion. I ended up moving to it after recent changes to the couchbaselabs offering made it difficult to work with the API, plus I was never comfortable with the REST API dependency. This module is all native calls to the CBL API, it also offers the listener if needed. I’m working on the iOS version for a client project at the moment. Responses from the original maintainers are slow to non-existent, so rather than collect PRs to send them I decided to create a new fork.

PR’s would be very welcome especially on the Android side.

To answer your question (as another React Native developer) using the REST API is ok for some applications, but for instance when you need to get events back from the DB it does not work so well, or if you already have native code accessing the CBL API, having the REST API seems like an unnecessary extra layer to go through. I also find the newer API based on Swagger very unintuitive.

Thanks for your input on the REST API for RN. Would love to learn about your experiences with the iOS version with the fork.

I clearly understand that any resources aren’t infinite (but stupidity, according to Einstein))
That’s why I choose that exact topic formulae - "Why Couchbase still doesn’t support RN?"
That’s pity that your management still doesn’t recognize RN as worth-for-efforts market, probably they will change their attitude soon. Let’s make our best to make it real.

Thank you for your suggestions.
That’s the thing - I personally prefer to stay away from native code(s) as much as possible, keeping RN concept in touch: pure JS.
And what I can see around - that many RN devs (at first being impressed by CB/SG/CBL brilliant functionality) are switching to another more complex for their tasks solutions (like Firebase + socket.io, i.e.) due to absence of support from vendor… That’s.really.pity.

Well, I guess there are different levels of RN developer - those that are comfortable dropping into native code and those that prefer to stay in JS land… IMO you lose a lot of the flexibility if you choose to stay in JS. I think a part of the RN concept is that you can drop into native code whenever you need to, and so choose which parts to build native and which to build in cross-platform JS.

Just my opinion, I know this is getting off topic…

You can help by becoming a paid Couchbase customer (if you aren’t already.) Management prioritizes requests from paying customers…

Agree, me too. Started with CBL, then switch to socket.io

For anyone interested I started React Native module for Couchbase Lite here https://github.com/bjornd/react-native-cbl. Currently implements all the basic functionality for iOS and Android: CRUD operations over documents, attachments, replications.

3 Likes

@bjornd, just wondering, have you also looked at the repo from @adamski? https://github.com/adamski/react-native-couchbase

Yes, @adamski already reached me on email. We’re discussing the better way to implement support for CBL 2.0.

1 Like