Make Quasar more easily integrated with a NodeJS backend

[claustres]

I played a little bit with quasar in order to create a complete web app. First of all I want to say it seems to me to be a great work : components, CLI, electron integration, etc. What I want to share here is how I made some minor modifications to the default template in order to make developing a full web app with a NodeJs backend simple within a conveniently integrated environment.

Of course I know that quasar is a front-end framework however I think it makes sense because at least in dev mode quasar is already integrated with a node backend because of webpack. It also integrates a proxy for APIs.

The main changes are the following:

• added a server directory to host server-side code with a server entry point index.js that simply start an express server (such as done before in script.dev.js)
• changed output dir for front-end files to dist/client instead of dist
• added output dir for back-end files to dist/server
• added babel CLI as dev dependency to transpile server-side code
• added a npm prod script to run server in prod mode and serve client prod version
• added nodemon as a dev dependency to watch changes in server side code and restart the server
• activated server-side debug mode in node for dev
• changed existing npm scripts to handle client and server side tasks

To give you an idea here are the npm scripts

"scripts": {
    "clean": "node build/script.clean.js",
    "dev": "nodemon --watch server --exec npm run debug",
    "predebug": "npm run build:server",
    "debug": "node --inspect --harmony_async_await build/script.dev.js",
    "preprod": "npm run build",
    "prod": "node --harmony_async_await build/script.prod.js",
    "build:client": "node build/script.build.js",
    "build:server": "babel server -d dist/server -s",
    "build": "npm run build:client && npm run build:server",
    "lint:client": "eslint --ext .js,.vue client",
    "lint:server": "eslint --ext .js server",
    "lint": "npm run lint:client && npm run lint:server"
  }

Before provinding you with further details, code, etc. let me know if this is something your are interested in or if I should work on this in a separated way. It could be integrated in the main stream of quasar or maybe seen as a specific template or wrapper. I am waiting for any feedback.

[rstoenescu]

Hi,

It's a good idea. Created Quasar template repo for this: https://github.com/quasarframework/quasar-template-express

Are you willing to be its maintainer? Meaning to port changes from the default Quasar template whenever they occur? Full read/write permissions have been added for you on the newly created repo.

If we have a go, I welcome you to the Quasar team! Contact me on Gitter to get us started with this.

Cheers, Razvan

[claustres]

Yes I am interested in working on this and be the maintainer. However I have the ambition to build something more "evolved" than a simple express server, particularly to make real-time app development fast. I am looking for something similar to quasar for the backend side, more specifically I would like to try to integrate with http://feathersjs.com/. Both frameworks together will provide a really interesting base for building apps. So I don't know if we should rename the template according to this ?

This might also requires small modifications in the quasar framework, such as adding a 'quasar dev' command, create a documentation on this part, create a specific docker environment, ... I have also a question about how to manage the different app configs (dev/prod/test mode). In the default template there is a single config file which includes a dev/prod part. I believe we should have a global config file for each mode + a shared global config. The final config file is a merge of both files depending on the current mode, and the value for the current mode overrides the shared one. Indeed, I can't imagine a use case where you need to access prod settings in dev for instance. For some settings that are today splitted in the dev/prod parts (such as port) it could make sense to have a default shared value for all modes that could be overridden. Let me know what you think about this.

I will contact you on gitter next week.

[smolinari]

Would you be interested in working on a GraphQL backend? In my limited capacity, I'd love to help out on that too. I think a GraphQL backend would make more sense from a web component standpoint. Most React apps are powered by GraphQL, simply because it makes the developer lives (both front and back-end) easier.

Scott

[claustres]

Frayer beeing database agnostic you can use different ones, it already supports graphql.

[claustres]

@rstoenescu wouldn't be easier to maintain the different templates if they all are forks from the default one ?

[smolinari]

@claustres - Frayer?

Scott

[claustres]

Feathers.js sorry (I just switched off this f...g predictive text in french on my phone ;-)

[smolinari]

Um, ok. But, with GraphQL, we are talking about the client-server API, not the persistence layer. Feather.js is REST. I'd like to suggest using Apollo instead of Feather.

http://dev.apollodata.com/ https://dev-blog.apollodata.com/

Scott

[smolinari]

I am not sure if this code is 100% correct, but you can get the drift about how components might look within Quasar with GraphQL. The code is a mix of example code from Vue-Apollo and Quasar.

<template>
  <div class="list">
    <!-- Post list items -->
    <div class="item" v-for="post in posts" :key="post.id">
      <div class="item-content">
        {{ post.title }} by
        {{ post.author.firstName }} {{ post.author.lastName }}
      </div>
    </div>
  </div>
</template>

<script>
import { Loading } from 'quasar'
import gql from 'graphql-tag'

// GraphQL query
const postsQuery = gql`
  query allPosts {
    posts {
      id
      title
      votes
      author {
        id
        firstName
        lastName
      }
    }
  }
`

export default {

  function show (options) {
    if (loading > 0) {
      Loading.show(options)
    }
    else {
      Loading.hide()
    }
  }
  // Local state
  data: () => ({
    // You can initialize the data here
    posts: [],
    loading: 0
  }),
  // Apollo GraphQL
  apollo: {
    // Local state 'posts' data will be updated
    // by the GraphQL query result
    posts: {
      // GraphQL query
      query: postsQuery,
      // Will update the 'loading' attribute
      // +1 when a new query is loading
      // -1 when a query is completed
      loadingKey: 'loading'
    }
  }
}
</script>

The ability to actually declaratively define all the needed data in the single components and have the queries "smartly" be requested from the server and cached is a huge win for SPA on mobile. The other win for GraphQL is the server is also easier to manage.

GraphQL was created by Facebook to overcome the long term issues REST APIs have with an application growing in size with multiple clients, which is what Quasar also is trying to support. Sure, REST can be ran on all different clients too, but it isn't nearly as flexible or manageable as GraphQL.

Scott

[claustres]

Although Feathers follows this paradigm it is also more than REST, it has a service abstraction on the server-side, which allows to be database agnostic. It also provide real-time event management for the server and client side. Comparing GraphQL and REST does not completely make sense IMHO (https://philsturgeon.uk/api/2017/01/24/graphql-vs-rest-overview/) because GraphQL is basically a query langage; although there is a complete ecosystem around.

I believe that using Feathers.js won't prevent you using GraphQL (with your own client interface or the Feathers' one and https://github.com/feathersjs/feathers-waterline), while focusing on a GraphQL technology is a strong opiniated choice that does not fit well with micro-services which usually mix different approaches/technologies up.

[claustres]

@rstoenescu I propose to initiate a basic quasar-template-express then derive from it quasar-template-feathers

[smolinari]

If you look at the comments, I actually did some counter argumentation to Phil's article. 😄 IMHO, Phil tells only a partial and biased story. For instance, he never mentions the introspection capability of the GraphQL server. GraphQL introspection makes the front-end dev's life worlds better. It also makes the backend dev's life easier too, because the schema is all self-documenting. You can even add comments into the schema.

http://graphql.org/learn/introspection/

An example of how self-documenting introspection works is with Github's GraphQL API.

https://developer.github.com/early-access/graphql/explorer/

Sign in with Github then click on "Docs" top right and browse the schema. This is standard stuff from a GraphQL server. 😄

If you know about writing GraphQL queries, try it out on the left. You get autocompleted query syntax and syntax highlighting. Introspecting the schema is a standard feature of any GraphQL server. Oh, I said that already. 😊

it has a service abstraction on the server-side, which allows to be database agnostic.

GraphQL is a service abstraction itself, which is absolutely data resource agnostic. I say "data resource", because you could also have a REST API as a data resource with GraphQL too.

It also provide real-time event management for the server and client side.

So does Apollo.

https://dev-blog.apollodata.com/graphql-subscriptions-in-apollo-client-9a2457f015fb

From what I can tell, there is nothing Feathers offers that Apollo can't either, other than possibly a bit more stability and common knowledge, since both Apollo and GraphQL are relatively new technologies. Knowledge and stability are important, but I feel GraphQL overcomes those cons with it's big advantages.

focusing on a GraphQL technology is a strong opiniated choice that does not fit well with micro-services

Now that there is a decent alternative to REST with GraphQL, going with REST is just as an opinionated direction. The only difference is, GraphQL is especially built for reactive UIs and REST API solutions aren't. Sure, you can work with REST APIs and reactive UIs, but you have the issues of over and under fetching data and the much higher number of requests needed to gather data with REST. GraphQL was built to solve those problems. GraphQL is also predestined to work in a microservice environment too. This Stackoverflow answer better explains how GraphQL is a great gateway into a microservices system.

http://stackoverflow.com/questions/38071714/graphql-and-microservice-architecture

As for waterline, there is also an adapter for GraphQL too. https://github.com/strapi/waterline-graphql

I'll bet GraphQL will overtake REST as a client-server communication solution in the future, because it is that much better. If that happens, then sticking to REST will be the opinionated and legacy direction. 😄

Scott

[claustres]

Dear Scott I am pretty convinced GraphQL is interesting but by essence it is an interface definition langage to access data, maybe http://netflix.github.io/falcor/ is something more similar to it than Feathers.

You are talking about a complete technology stack around GraphQL (Apollo) and Feathers seems to me less opiniated with respect to interoperability (not architecture) because it basically supports different real-time technologies and different databases + authentication, but I might be wrong. Of course GraphQL can be used to create microservices but what I meant is that Feathers will be more usefull to do so because of its larger coverage as previously said.

Because this is a different approach from Feathers/REST what we need is probably two different templates. However I have not enough time/knowledge to implement one with GraphQL 😢 I don't know if it is possible either to have the benefit of both approaches in the same template, your help and advise is welcome, I will try to have a look to it next week.

[claustres]

@rstoenescu Initialized the first template from a fork by creating a branch if you want to have a look : https://github.com/claustres/quasar-template-default/tree/express

[smolinari]

You are right. It definitely wouldn't be beneficial to have the two technologies mixed in one template. They should be separate, since they are, in essence, two competing technologies.

Falcor is similar to GraphQL. GraphQL is a bit smarter though.

https://dev-blog.apollodata.com/graphql-vs-falcor-4f1e9cbf7504

From what I've seen on Feathers, it is highly opinionated, because IMHO the more magic a framework has, the more opinionated it is. 😄 So, with that respect, I'd venture to say, Apollo is actually less opinionated than Feathers currently. For instance, there is no pre-built authentication in Apollo or the ability to pre-build data types or resolvers via CLI like you can with Feathers and controllers, etc.

Check this out in terms of real time subscriptions: https://www.youtube.com/watch?v=aSLF9f13o2c

If I work on the GraphQL server template, would you be interested in also looking over my work? I am not the best JS programmer. 😊 Maybe we could cooperate that way and even offer two possibilities for Quasar users REST and GraphQL. What do you think?

Scott

[claustres]

I agree in the general sense, I am trying to use and write the minimal amount of code required to do stuffs. At a first glance Feathers looked to me as a big framework but reading the doc further I saw that almost everything is pluggable (https://docs.feathersjs.com/providers/, https://docs.feathersjs.com/databases/readme.html, https://docs.feathersjs.com/authentication/readme.html) and the core footprint is small (https://docs.feathersjs.com/api/readme.html). So I wanted to give it a try but I will catch up your opinion in a couple of weeks 😄

Anyway, don't make me too smart 😶 , I started JS 5 years ago with jQuery, then gained a solid background in NodeJS ecosystem, Angular 1.x ecosystem, MongoDB but I am not a reference in JS programming. However it will be interesting to collaborate because I would like to know more about GraphQL capabilities and tools. As I proposed I forked the basic Quasar template to initiate my own ones with different branches (https://github.com/claustres/quasar-template-default) I added you to the collaborator list if you want to start working on this.

[smolinari]

Ok. I've moved the conversation over to the repo. This should be fun! 😄

Edit: Oops. Nope. Issues aren't turned on. Could you do that please? 😄

Scott

[claustres]

Done but this might be a temporary move, i am waiting for @rstoenescu to know how he wants to manage the work on the different templates

[smolinari]

Yeah, I am also not to sure how best to incorporate two different server side templates (or more).

Though, it would be cool to have a CLI command, which will add the wanted server package. Something like

quasar init my-app --add-backend --express

If Razvan also likes the idea, I could work on that too, once I know how the templates should be stored. i.e. Repos or Branches (or some other idea).

Scott

[claustres]

Well in this case we should go for a more evolved templating system, probably similar to https://github.com/feathersjs/feathers-cli. But I personnaly never used Yoman before.

[smolinari]

Quasar's CLI is based on commander.js.

https://github.com/tj/commander.js/

It doesn't have interactivity like yeoman does, from what I can tell.

Scott

[rstoenescu]

@claustres @smolinari This is good constructive talk.

What would you say about making a Quasar wrapper for this, instead of a template? This means it can be added later on if one decides to create a backend api endpoint server too. A wrapper is the equivalent of the proposed quasar init my-app --add-backend --express. The wrapper should create a /api (or /backend or /server) folder containing everything related to the backend API. Let's focus on what this folder contains at first, then we'll add the necessary logic to the CLI to handle this wrapper. If we can all agree I can go ahead and change the name of the repo from quasar-template-express to express-wrapper (and later a featherjs-wrapper and/or graphql-wrapper). Push directly to this repo, no need for PR. Before we release it I'll take a look then make it official. I'd love to see this work integrated.

We should have some kind of structure based on routes.

Looking forward to hear your thoughts.

[rstoenescu]

Also, @claustres what's your Gitter id?

[claustres]

My Id is claustres, I am currently connected

[rstoenescu]

You can both push directly to this repo: https://github.com/quasarframework/quasar-wrapper-express (name of repo may change - we have to agree on the best name).

[3kynox]

Hello, any updates on this ? I am currently trying to use quasar inside a client/ folder and have a server folder/ as well on root directory for express / mongodb back-end and start from here.

Interesting project that have a good structures is here :

https://github.com/icebob/vue-express-mongo-boilerplate

BTW, i'm starting to do it.

[claustres]

For now we have started these but we need to finalize the integration:

• https://github.com/quasarframework/quasar-wrapper-express-api
• https://github.com/quasarframework/quasar-wrapper-feathersjs-api
• https://github.com/quasarframework/quasar-wrapper-graphql-api

[3kynox]

Hello there,

I react again today about server wrappers because I've made some progress and also I think it do not make sense to have a standalone graphql wrapper :

• Community globally admit standalone graphql server is a pain because lack of important features (authentication, etc...).

It make more sense to have a feathers wrapper and another one with feathers/graphql integrated.

Recently, I've integrated graphql with latest feathers auk version (using sqlite, but as @claustres says, it simple to switch to nedb for example).

I did it this here : https://github.com/GuntharDeNiro/BTCT/commits/saas-dev

it works really well and I have a lot of fun querying with graphql. feathers manage all related to database connection / authentication / etc...

I'm up if you guys wants me to PR.

[claustres]

I would be happy to welcome a PR on https://github.com/quasarframework/quasar-wrapper-feathersjs-api using a new branch just like we are doing for SSR.

[3kynox]

Will do soon. I'm doing currently gql mutation authentication from the client for the api transport and I'll manage after that few more endpoints and also websocket subscription.