Looking for engin.io replacement -joining our effort initiative
-
Better late than never, I finally published a first draft of my work to design a Baas plugin.
The project can be found here : https://github.com/a-team-fr/QtQML-BaaS
It is really a Work In Progress stuff but things are slowly getting up...For now, it is only supporting Parse Server, I used to start working on Firebase then Bluemix but I stopped and finally even dropped the code for now. I find Parse to be a much better candidate and I prefer first reach an operative state with Parse server only and then complete the plugin with others cloud services.
So far, the BaaS element can only manage users (told you it was an early phase!) and the BaaSModel can be used to get data and work as usual with a ListView for instance...I have implemented some of the feature for query but haven't tested yet.
The best (I think) is to build the whole project and see the sample project to see how to add new feature.
All comments are welcome ! I will try to improve the commenting and documenting...I have an issue when deploying the plugin, the qmldir file is not copied to the plugin location - will investigate this later.
-
@Charby thanks !
I think you're right, and that Parse Server is a good starting point. It may be even more than a starting point because it's evolving to be more modular and allow to plug many services, including other DBs.
I've (mostly) finished porting my app, it's working nicely. I had to patch the Parse Server code for a feature existing in Engin.io but missing in Parse (atomic updates of subdocuments), it wasn't that hard in spite of my lack of Node.js knowledge. I was pleasantly suprised by the size of the code (it's rather small, I was expecting a huge pile of exotic JS).
I've made a pull request for my patch, let's see how the discussion with the maintainers goes.About your QML plugin, did you consider just forking/patching the Enginio C++/QML SDK instead ? If not, why ?
-
@Charby thanks !
I think you're right, and that Parse Server is a good starting point. It may be even more than a starting point because it's evolving to be more modular and allow to plug many services, including other DBs.
I've (mostly) finished porting my app, it's working nicely. I had to patch the Parse Server code for a feature existing in Engin.io but missing in Parse (atomic updates of subdocuments), it wasn't that hard in spite of my lack of Node.js knowledge. I was pleasantly suprised by the size of the code (it's rather small, I was expecting a huge pile of exotic JS).
I've made a pull request for my patch, let's see how the discussion with the maintainers goes.About your QML plugin, did you consider just forking/patching the Enginio C++/QML SDK instead ? If not, why ?
@gadlim I felt the same with Parse server, the project is rather small, simple and well written. Furthermore the project team seems very productive and I bet the project will become very popular.
I didn't fork Enginio for a couple of reasons :- I looked at the code and found it rather difficult to master - I still haven't understand the private class principle and I haven't found a design documentation. But maybe I should have spent more time to study and hopefully understand it...
- I think forking the project would have been more difficult in the long term to main backward compatibility with existing API.
- even if my project is not a fork from enginio, it is inspired of some enginio design principles - for instance I liked the enginio model, but rewriting a similar model was not a complex task (and it was interesting from the learning point of view)
- I wanted the plugin to be as much as possible backend agnostic, that the reason why the main class is pure virtual and will be refined to ease integration of additional backend services.
-
@gadlim I felt the same with Parse server, the project is rather small, simple and well written. Furthermore the project team seems very productive and I bet the project will become very popular.
I didn't fork Enginio for a couple of reasons :- I looked at the code and found it rather difficult to master - I still haven't understand the private class principle and I haven't found a design documentation. But maybe I should have spent more time to study and hopefully understand it...
- I think forking the project would have been more difficult in the long term to main backward compatibility with existing API.
- even if my project is not a fork from enginio, it is inspired of some enginio design principles - for instance I liked the enginio model, but rewriting a similar model was not a complex task (and it was interesting from the learning point of view)
- I wanted the plugin to be as much as possible backend agnostic, that the reason why the main class is pure virtual and will be refined to ease integration of additional backend services.
@Charby said:
I didn't fork Enginio for a couple of reasons :
- I looked at the code and found it rather difficult to master - I still haven't understand the private class principle and I haven't found a design documentation.
Ditto, I don't fully understand it either (the websocket stuff in particular). The private classes are mainly for binary compatibility that Qt has to maintain for all the Qt5 line, it's much simpler without that burden.
-
Hi,
Don't start by dropping the PIMPL idiom from that module, especially if the goal is to get it integrated with the Qt distribution some day.
For more details about private implementation you can look here
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
Hi,
Don't start by dropping the PIMPL idiom from that module, especially if the goal is to get it integrated with the Qt distribution some day.
For more details about private implementation you can look here
-
@SGaist Thanks for this information, I wasn't aware of this...
Nevertheless, for now I would prefer YAGNI over PIMPL ;-)The private classes are mainly for binary compatibility that Qt has to maintain for all the Qt5 line, it's much simpler without that burden.
Actually, as far as I know, binary compatibility is guaranteed only between major versions, but not for the whole Qt 5 line. Meaning 5.X.Y are binary compatible across all .Y versions, but not between the .X versions. Or in other words, Qt 5.5.1 would be compatible with 5.5.2, 5.5.3 and so on, but 5.4 is not guaranteed to be binary compatible with 5.5.
Nevertheless, for now I would prefer YAGNI of PIMPL ;-)
I believe @SGaist's point is that you're in fact going to need it if you ever hope to have your module as part of Qt. :)
Otherwise you'd be asking everyone that uses your library to do a full rebuild of their code on any change in the private implementation of your module (like adding a member of a class for internal purposes) ... and this ain't a good way to design a library ...Kind regards.
-
The private classes are mainly for binary compatibility that Qt has to maintain for all the Qt5 line, it's much simpler without that burden.
Actually, as far as I know, binary compatibility is guaranteed only between major versions, but not for the whole Qt 5 line. Meaning 5.X.Y are binary compatible across all .Y versions, but not between the .X versions. Or in other words, Qt 5.5.1 would be compatible with 5.5.2, 5.5.3 and so on, but 5.4 is not guaranteed to be binary compatible with 5.5.
Nevertheless, for now I would prefer YAGNI of PIMPL ;-)
I believe @SGaist's point is that you're in fact going to need it if you ever hope to have your module as part of Qt. :)
Otherwise you'd be asking everyone that uses your library to do a full rebuild of their code on any change in the private implementation of your module (like adding a member of a class for internal purposes) ... and this ain't a good way to design a library ...Kind regards.
@kshegunov said:
Actually, as far as I know, binary compatibility is guaranteed only between major versions, but not for the whole Qt 5 line. Meaning 5.X.Y are binary compatible across all .Y versions, but not between the .X versions. Or in other words, Qt 5.5.1 would be compatible with 5.5.2, 5.5.3 and so on, but 5.4 is not guaranteed to be binary compatible with 5.5.
No, there's binary compatibility for .X (minor) versions too
About the build dependencies, you're right, PIMPL is also better for that.
But I'll side this @Charby on this, it's a bit YAGNI at that point. The important thing is to get that project off the ground, and the code he's submitted is rather clean and simple, so easier to contribute to and build upon that the official Qt Enginio SDK. If someone wants to contribute a PIMPLification, I think he won't object (?), but I wouldn't be fair to require him to do that himself, as it would eat some of his time that can be better spent adding features. -
@kshegunov said:
Actually, as far as I know, binary compatibility is guaranteed only between major versions, but not for the whole Qt 5 line. Meaning 5.X.Y are binary compatible across all .Y versions, but not between the .X versions. Or in other words, Qt 5.5.1 would be compatible with 5.5.2, 5.5.3 and so on, but 5.4 is not guaranteed to be binary compatible with 5.5.
No, there's binary compatibility for .X (minor) versions too
About the build dependencies, you're right, PIMPL is also better for that.
But I'll side this @Charby on this, it's a bit YAGNI at that point. The important thing is to get that project off the ground, and the code he's submitted is rather clean and simple, so easier to contribute to and build upon that the official Qt Enginio SDK. If someone wants to contribute a PIMPLification, I think he won't object (?), but I wouldn't be fair to require him to do that himself, as it would eat some of his time that can be better spent adding features.No, there's binary compatibility for .X (minor) versions too
Right, either I have remembered wrongly, or the versioning system has changed somewhat from Qt 4. But in any case, using PIMPL is a good way to ensure all the aforementioned features.
But I'll side this @Charby on this, it's a bit YAGNI at that point.
I don't presume to tell you how to design or code your library, just throwing my 2 cents. ;)
but I wouldn't be fair to require him to do that himself, as it would eat some of his time that can be better spent adding features.
The only problem I see is that at a later point implementing PIMPL from existing code might be more involved, so I'd go with it from the start, but as I noted, it's up to the actual designer/programmer how to proceed. As a side note, the idiom doesn't actually require more work, only some care to separate the data from the interface. (If you wish you could take a peek at a library (wrap) I'm developing for OpenMPI, to have a baseline for what implementing PIMPL might involve).
Kind regards.
Read and abide by the Qt Code of Conduct
-
No, there's binary compatibility for .X (minor) versions too
Right, either I have remembered wrongly, or the versioning system has changed somewhat from Qt 4. But in any case, using PIMPL is a good way to ensure all the aforementioned features.
But I'll side this @Charby on this, it's a bit YAGNI at that point.
I don't presume to tell you how to design or code your library, just throwing my 2 cents. ;)
but I wouldn't be fair to require him to do that himself, as it would eat some of his time that can be better spent adding features.
The only problem I see is that at a later point implementing PIMPL from existing code might be more involved, so I'd go with it from the start, but as I noted, it's up to the actual designer/programmer how to proceed. As a side note, the idiom doesn't actually require more work, only some care to separate the data from the interface. (If you wish you could take a peek at a library (wrap) I'm developing for OpenMPI, to have a baseline for what implementing PIMPL might involve).
Kind regards.
@kshegunov Just to clarify slightly my words : when I mentioned my preference to YAGNI over PIMPL, I was not meaning that PIMPL implementation would not be needed : I have a better understanding of PIMPL now - thanks to you guys! - and I am convinced that I would definitely go for it.
Actually, I meant that my plugin design is not mature enough at this stage, I have only implemented one backend service (Parse) and it is not even complete...so it is likely that when adding new features (or even worst, when I will integrate new backend services) , I would need to change the design, modifying declaration, visibility and so on...and at this stage, it would be much faster if I only modify one class i.o two.
As far as I understood the PIMPL implementation, adding the private class when my plugin design would be mature enough should be a straightforward process. But if you think, I am missing something please tell me, so I could integrate PIMPL right away.Thanks for your feedback !
-
@kshegunov said:
Actually, as far as I know, binary compatibility is guaranteed only between major versions, but not for the whole Qt 5 line. Meaning 5.X.Y are binary compatible across all .Y versions, but not between the .X versions. Or in other words, Qt 5.5.1 would be compatible with 5.5.2, 5.5.3 and so on, but 5.4 is not guaranteed to be binary compatible with 5.5.
No, there's binary compatibility for .X (minor) versions too
About the build dependencies, you're right, PIMPL is also better for that.
But I'll side this @Charby on this, it's a bit YAGNI at that point. The important thing is to get that project off the ground, and the code he's submitted is rather clean and simple, so easier to contribute to and build upon that the official Qt Enginio SDK. If someone wants to contribute a PIMPLification, I think he won't object (?), but I wouldn't be fair to require him to do that himself, as it would eat some of his time that can be better spent adding features. -
Another but related topic : I have seen on the wiki, that it is encouraged to request for Qt playground project creation even if the project is in early stage. I think, that's would be great in this case so we could have a common repository to collaborate on a great plugin to give Qt App backend services.
Do you know how to proceed for creating playground projects ?
So far, I only sent a request on the development mailing list but I don't know what are the next steps... -
Another but related topic : I have seen on the wiki, that it is encouraged to request for Qt playground project creation even if the project is in early stage. I think, that's would be great in this case so we could have a common repository to collaborate on a great plugin to give Qt App backend services.
Do you know how to proceed for creating playground projects ?
So far, I only sent a request on the development mailing list but I don't know what are the next steps...@Charby
Hello,As far as I understood the PIMPL implementation, adding the private class when my plugin design would be mature enough should be a straightforward process. But if you think, I am missing something please tell me, so I could integrate PIMPL right away.
Mostly it's very straightforward process, however there are few "tricks" that are usually closely associated with the PIMPL idiom. I've used two of them in my project (sourced in my previous post), i.e. private slots and private object constructor. The private slots can be substituted with lamda functions if you're willing to enforce C++11. The second one can be implemented at a later stage, but I personally would detest refactoring a full working piece of code only to ensure that the user won't be able to create an object of given class. These two help with the design - not exposing anything besides the barebone interface, but you could certainly skip them (in most cases), or at least defer the[ir] implementation. I hope this is helpful.
Kind regards.
-
Another but related topic : I have seen on the wiki, that it is encouraged to request for Qt playground project creation even if the project is in early stage. I think, that's would be great in this case so we could have a common repository to collaborate on a great plugin to give Qt App backend services.
Do you know how to proceed for creating playground projects ?
So far, I only sent a request on the development mailing list but I don't know what are the next steps...@Charby said:
Do you know how to proceed for creating playground projects ?
So far, I only sent a request on the development mailing list but I don't know what are the next steps...The wiki page says "wait for the approval of a maintainer on the mailing list", so the next step is to wait for a response, but as it's been a long time, a bump could help, maybe.
On an unrelated note, my pull request was merged into Parse Server today, so +1 to the Parse Server project. There's now a 100% features parity between the Engin.io REST API and the Parse Server API (at least for the subset I'm using, but Id say I'm using all the most common methods).
-
Just a short post to give feedbacks...
Unfortunately I haven't had too much time to continue working on the BaaS plugin lately, here is the project status :- Authentification : partly done (miss the social linking)
- Object (alias collection) management : done
- JSonModel : partly done (read-only only for now)
- Adaptative QML List view : done
- Files : work in progress, I should have it completed by tomorrow hopefully
As always, comments are welcome !
-
Hi @Charby,
I've just seen this post now. How did your integration go so far?There is a Qt optimized cloud/BaaS alternative: you can look at V-Play Game Network: http://v-play.net/game-network/
Albeit its name, it is not only for games but also for apps.See here for a list of useful components with their Qt API reference:
- http://v-play.net/doc/vplay-webstorage/ - use WebStorage as a cloud-based key/value store. Its data gets synced across devices & platforms.
- http://v-play.net/doc/vplay-vplaygamenetwork/ - GameNetwork supports social login from Facebook so data can be synced across devices & platforms with a single user.
- http://v-play.net/doc/vplay-vplaymultiplayer/ - The multiplayer components supports a chat, push notifications and a friend system. You can add a QML-stylable messenger to your app with this component.
You can also just use some parts of these components, and freely mix it for example with Firebase.
Cheers, Chris
Founder of Felgo SDK - http://felgo.com/qt
Felgo simplifies
- Mobile App Dev with Qt esp. iOS & Android
- Game Development with Qt
What others say
Felgo scored #1 in Cross-Platform App Development Tools Report - see why: https://goo.gl/rgp3rq
-
Hi @Charby,
I've just seen this post now. How did your integration go so far?There is a Qt optimized cloud/BaaS alternative: you can look at V-Play Game Network: http://v-play.net/game-network/
Albeit its name, it is not only for games but also for apps.See here for a list of useful components with their Qt API reference:
- http://v-play.net/doc/vplay-webstorage/ - use WebStorage as a cloud-based key/value store. Its data gets synced across devices & platforms.
- http://v-play.net/doc/vplay-vplaygamenetwork/ - GameNetwork supports social login from Facebook so data can be synced across devices & platforms with a single user.
- http://v-play.net/doc/vplay-vplaymultiplayer/ - The multiplayer components supports a chat, push notifications and a friend system. You can add a QML-stylable messenger to your app with this component.
You can also just use some parts of these components, and freely mix it for example with Firebase.
Cheers, Chris
Hi @feldifux,
Actually I stopped working on this project for some time now. Currently the API is working fine with Parse server as datastorage. Support for social login and push notifications are missing.
V-Play Albeit sounds very nice !
I will definitely have a try the next time I would need social login or notifications support. Thanks -
Hi @feldifux,
Actually I stopped working on this project for some time now. Currently the API is working fine with Parse server as datastorage. Support for social login and push notifications are missing.
V-Play Albeit sounds very nice !
I will definitely have a try the next time I would need social login or notifications support. Thanks
