Does Quasar have any helpers for interfacing with standardized web APIs?
-
Just an idle curiosity I had. It seems to me like the design goal of Quasar is to implement as many best practices and useful tools as possible (tree shaking, Vue, Material Design, date utilities, color utilities, etc) - and most apps would be incomplete without some central data persistence.
Clearly not every app needs to sync data with a central server (a personal budgeting app may be just as good storing its data locally), and clearly not all central persistence has to come in any standard form (you could open a raw TCP socket to send back binary-encoded data, you could rely on REST endpoints, or you could transfer whole SQLite files if you wanted to piss off and horrify every dev who ever lived). But there are a few standards that are widely adopted and used across the vast majority of modern apps. Specifically, most apps either use:
- RESTful API endpoints acting as a thin layer of an Entity-Relationship model managed by some back-end ORM (e.g. “GET /users”, “DELETE /users/3”, “POST /comment”)
- GraphQL
If Quasar provided helpers for interacting with these two (or just one of these two) common API types, it could reduce app development time drastically. Bonus points if such a helper were integrated with Vuex so you merely had to define your models and you magically had access to them all in your components.
I was just curious if such a thing existed or was in the works with Quasar. It seems like they’re trying to be a “one-stop shop” for cross-platform app development, and this would really seal the deal if it’s already a feature.
-
Hi,
We have some app extensions in work, which cover these areas. Lack of manpower has caused them to be put on the back burner though.
https://github.com/quasarframework/app-extension-apollo
https://github.com/quasarframework/app-extension-feathersjsScott
-
Well, I am glad that Quasar is opinionated but not that much opinionated in the context of WebAPIs. Why? Quasar works on the high level of abstraction and WebAPI data access is very low level. Mixing those without additional levels of abstraction is BAD idea
.What those intermediate abstraction levels could be? For starters data models. Many Quasar components use a concept of “data source”. This data source could be a list of dicts. Those “dicts” have in fact a structure, let’s say every “dict” represents “user”. Hence the need of “user” data model. On the higher level of abstraction from those data models you could build a “data source” in the meaning of “data access” + “data models” + “meta information”. Frankly, this WebAPI access is only a “data access” transport module from the “data source” abstraction.
As for now, there is no “data source” abstraction in Quasar and this is the main problem. If you want to use the same data in QTable, QList or QTree you need to write many layers of accessors, transform and copy data, even process events (brrr). Data source could be helpful not only in visual representation of data (by Quasar components) but in their behaviours, too. What behaviours? Well, for instance global drag and drop support, global clipboard, global keyboard navigation, etc. Without “data source” concept in Quasar everyone needs to write this layer on his own.
Where are the WebAPIs/WebServices in this picture? In the context of Quasar there are boot files which are native to Quasar and there are VueX actions which are native to Vue platform. Those are the places where from the POV of architecture one could place simple WebAPI/WebService access (on the contrary, the mentioned “Data source” layer should be implemented as another QComponents).
Why there should be no implemented support for WebAPIs in Quasar? Because there are so many of them. I for instance do preferer (at this moment) the OpenAPI standard, where it is one API declaration and one could automatically generate server or client parts in almost every possible programming language. But many others could prefer classic REST or WebService or GraphQL even. Somebody would want something synchronised like PouchDB or need to have a push WebSocket data interface. Some other would want to exchange data with peers by WebRTC. As you can see, this “access layer” is not what Quasar should implement. Quasar “could” implement “data source” components and those components “could” communicate with all mentioned “data access” libraries and this would (could, might) be perfect.
What then? Well, I do like OpenAPI generators:
https://openapi-generator.tech/
or:
https://swagger.io/tools/swagger-codegen/I do like VueXORM:
https://vuex-orm.github.io/vuex-orm/guide/prologue/what-is-vuex-orm.htmlThose two technologies allows me to have very simple and open server persistence layer and synchronized, reactive, queriable, transactional, documented client side layer. BUT - if I could just have those “data source” components in QTable, QTree etc. I would be very happy.
-
In other words, app extensions are a good place to put API related things, so developers don’t have to continually create the same wheel.
Scott
-
@s-molinari said in Does Quasar have any helpers for interfacing with standardized web APIs?:
In other words, app extensions are a good place to put API related things, so developers don’t have to continually create the same wheel.
Scott
Hmm, maybe it is a good idea to have first incarnation of QDataSource as an app extension afterall. Nevertheless, the support from “data consumer” components (QTable, QTree, QList etc.) in terms of something like hooks, events, etc would be needed also.
I’m not entirely convinced to this GraphQL thingy, but because this graphql is dynamic on the client side then maybe Quasar data components (QTable, QTree etc) would greatly benefit from such integration.
