Looking for engin.io replacement -joining our effort initiative

Charby · B benlau 7 Feb 2016, 15:12

@benlau that could be indeed another good candidate to evaluate...

gadlim · B benlau 7 Feb 2016, 15:12

@benlau AWS Lambda is for creating your own "micro-services" (~API), that can be useful, but it's more comparable to the MAR part of Qt CS than to Qt EDS (a.k.a. Engin.io).

bnogal · wrote on 9 Feb 2016, 17:15

i just post to say, i support the idea!

lets see what i get from my little code. i hope i can upload it soon this week.

gadlim · 19 Feb 2016, 17:56

Follow-up on my Cloudant evaluation: I ran into problems trying to figure out how to encrypt user passwords.
I'll have a conversation on that subject with IBMers tomorrow.
I hope to also discuss the broader subject of whether Cloudant is a good fit for 2-tiers apps (no server code, or almost no server code).

If you guys have questions, tell me, I'll try to insert them in the conversation.

bnogal · 12 Feb 2016, 16:47

Well

I am almost ready to upload my code.
I just miss a class... that i used lately at my job and i should remove it from my personal code now...

It is a swissknife class that it is almost no needed, but does a basic task.

For the login.

My code uses google login in android, so security is taken by google and baasbox. It should be possible to do something similar for iphone.

For "secure" password login without using "social login" by the moment i just hash at application level the password, as by the moment i dont use ssh for requests. It doesnt make secure the system, but unless it doesnt exposes the original password in plain text.
It should be easy to improve the code to use a certificate and SSL sockets with some Qt magic.

Today i have a some social event... hope i can rip off that class and upload it tomorrow. The rest is ready

Charby · B bnogal 12 Feb 2016, 16:41

@bnogal Sounds great !
From my side, I couldn't progress at that rate...what I did is create the skeleton of a plugin (I was unfamiliar with the plugin mechanism) and request for a playground project from the developer mailing list. I have continued evaluation with Apigee candidate. But I feel I should restrain myself now and focus on a something simple that could be later on improved so I will start with the firebase plugin. Hopefully I should be able to publish in a couple of days.

gadlim · 2 Dec 2016, 17:38

Hello,

Quick update from Cloudant:

Security should be ok, but I'm still missing some pieces
Offline+sync support for mobile and web apps with PouchDB, very similar to how the Firebase SDK works (but with more options for queries, including server-side filters)

xargs1 · 13 Feb 2016, 10:07

Looking at people's attempts to get PouchDB working with Qt/QML, it doesn't seem very encouraging.

gadlim · X xargs1 13 Feb 2016, 08:29

@xargs1 said:

Looking at people's attempts to get PouchDB working with Qt/QML, it doesn't seem very encouraging.

Do you have some links ?
There's a Python adapter project that uses Qt internally to wrap PouchDB, so a C++/QML adapter should be feasible. That said, maybe it's too much effort and we should to stick to the REST API.

xargs1 · 13 Feb 2016, 19:50

As far as I'm aware, PouchDB is pure JavaScript and doesn't have a REST API.

Here's the discussion on failed attempts to integrate PouchDB into QML:

https://github.com/pouchdb/pouchdb/issues/3709

gadlim · X xargs1 13 Feb 2016, 19:39

@xargs1 said:

As far as I'm aware, PouchDB is pure JavaScript and doesn't have a REST API.

I was referring to the Cloudant REST API

Here's the discussion on failed attempts to integrate PouchDB into QML:

https://github.com/pouchdb/pouchdb/issues/3709

I see. It's in a "maybe could work with some efforts but nobody's working on it" state.

xargs1 · 13 Feb 2016, 21:09

It seems to be like most of the large JavaScript frameworks: it assumes it's running in either a browser or node.js, and QML's JavaScript doesn't provide either of those environments.

gadlim · X xargs1 13 Feb 2016, 20:08

@xargs1 said:

It seems to be like most of the large JavaScript frameworks: it assumes it's running in either a browser or node.js, and QML's JavaScript doesn't provide either of those environments.

Yes.
There's another non-JS (Android) adapter that's using the same tactics as the PyQt adapter (hidden Webview), but it's also unmaintained.
What's strange is that IBM (Cloudant) is advertising PouchDB as the right solution for mobile apps sync, so they're focusing on "mobile" web apps maybe.

Charby · wrote on 14 Feb 2016, 17:03

Hi all,

I think it would be helpful to create a Qt playground project so we could publish our backend wrappers in a commun repository. I have sent a request for creating the playground project to the development mailing list but I don't know whether it is the way to go...Do you know what is the process to follow to create a playground project ?

So far, I have designed a QML plugin which is a work in progress :

the plugin only offers for now a Firebase backend element which is quite limited : the only supported authorization method is the secret token id and at this time it is only a thin wrapper around the REST API (GET, DELETE, POST, PATCH and PUT are supported).
what remains to be done :
- define and implement an API suitable for supporting multiple backend : one option could be to design an API similar to the former enginio (create, update, query, uploadFile, downloadURL, remove...) but this API relies on backend features that we would have to mimics (users and usergroups, fileref...) so I am not sure this would be the way to go...
- create a model that could be nicely used from QML like the former enginio model
- use the Android and iOS sdk depending on the deployed platform (and using the REST sdk otherwise)
- implement other backend using the same API (cloudant, apigee, BaaSBox...)

I don't know if this does worth to publish this to github or to wait for the creation of a playground qt module...

gadlim · 14 Feb 2016, 20:50

@Charby said:

I don't know if this does worth to publish this to github or to wait for the creation of a playground qt module...

I'd say, if you have some code, even WIP, publish it. When discussing specs in a group, actual code can help to keep everyone on the same page.

Given our limited resources, it would help a lot to have only a thin layer of code to add to another, wider audience project (at the moment Qt/QML on mobile is a small audience, sadly). I thinking specifically of Hood.ie. I don't know if it's technically feasible, but using Hoodie as a kind of middleware could save a lot of code; just mimicking its API could be useful too. Of course if (for instance) Hoodie is bound to the browser, we have the same problem as with PouchDB.

xargs1 · 14 Feb 2016, 20:22

I just finished a pure Qt Quick CouchDB interface (no C++ or plugins) which meets my current needs for storage. It would probably be trivial to get it work with Cloudant, but I'm not interested in adopting yet another BaaS provider that's going to disappear in a month or a year like Enginio and Parse did.

gadlim · X xargs1 14 Feb 2016, 18:58

@xargs1 said:

I just finished a pure Qt Quick CouchDB interface (no C++ or plugins) which meets my current needs for storage. It would probably be trivial to get it work with Cloudant, but I'm not interested in adopting yet another BaaS provider that's going to disappear in a month or a year like Enginio and Parse did.

That's great! A CouchDB interface should be directly pluggable to the Cloudant service. See this. In fact, I gather that IBM is currently a main contributor to CouchDB, and was before the acquisition of Cloudant, which was originally an independant company. Think of Cloudant as CouchDB hosting + benefits.
The situation is different for Enginio because of the closed-source components. OTOH, CouchDB is an Apache project and Cloudant can be self-hosted if you don't like "public" clouds.

As an aside, why Enginio, or a least the main parts, can't be open-sourced is beyond me. Given the competitive nature of the Baas market, not having an "we-failed-commercially-but-here-is-the-source-code" exit plan is disappointing, given the Qt ties to the OSS/Free software world.

Charby · 14 Feb 2016, 21:06

@Charby said:
Ok, I will wait a couple of days to see if we could get a playground project to collaborate, otherwise I will create a github (next week) with my project at its current state. I came back a shortwhile looking to Apigee and I think it could be the best candidate I have seen so far, I will keep Firebase in my project but will definetely add an Apigee wrapper in addition.

gadlim · 14 Feb 2016, 23:09

@Charby said:

I came back a shortwhile looking to Apigee and I think it could be the best candidate I have seen so far

I've also looked at Apigee a while back and found the pricing plans a bit steep (starting at 300$/month without a datastore). Maybe I misunderstood that page ?

Charby · G gadlim 14 Feb 2016, 21:06

@gadlim You are right (sic) - Actually I missed that pricing page as I jumped directly to the console after having signed a trial free account. Apigee seems to match perfectly what I was looking for (100% RESTfull, push notifications, social login, already builtin collections for assets-users-group, console is complete and powerfull and documentation is comprehensive...). It is a very unclear what are the pricing plan for BaaS...but if it is really 300$/mo (or more) it will be a no go for me...

additional candidates :