GraphQL-FHIR: Does Apollo use Webpack by default?

awatson1978 · March 8, 2017, 6:21pm

Hi there,
Quick question… does the default build pipeline of Apollo use Webpack or Meteor? Or is it simply agnostic to the build pipeline?

I ask, because I just got clued into a FHIR implementation using apollo-client and webpack and babel. The usage of FHIR and apollo-client is fantastic; and I’m trying to get up to speed with how drastically different the build pipeline is.

Thanks!

sashko · March 8, 2017, 7:19pm

Yeah, it doesn’t depend on the build pipeline at all. Works just as well with webpack/meteor/rollup/typescript/babel/etc.

awatson1978 · March 8, 2017, 7:48pm

Would you mind taking a quick look at this package.json file, and let me know your opinion on it?

github.com

shalkam/gql-fhir/blob/master/package.json

{
  "name": "backend-with-webpack",
  "scripts": {
    "build": "gulp build",
    "start": "gulp run",
    "dev-server": "NODE_ENV=DEV_SERVER gulp dev-server",
    "dev-electron": "gulp watch-electron",
    "build-schema": "NODE_ENV=DEV_SERVER gulp build-schema",
    "build-server": "NODE_ENV=production gulp build-server"
  },
  "main": "server/dist/main.js",
  "devDependencies": {
    "acl": "^0.4.10",
    "apollo-client": "^0.5.24",
    "apollo-errors": "^1.2.1",
    "babel-core": "^6.21.0",
    "babel-loader": "^6.2.10",
    "babel-plugin-transform-runtime": "^6.15.0",
    "babel-preset-es2015": "^6.22.0",
    "babel-preset-es2017": "^6.22.0",

This file has been truncated. show original

My general take on it is:

happy to see apollo-client and react-apollo
babel-preset-es2017 seems like it might be a bit bleeding edge
express seems like it’s a move backwards, no?
I’d have liked to have seen apollographql/graphql-server instead of graphql-server-express
webpack requires different tooling chain
mongoose instead of node-simple-schema

Does that seem like a reasonable take on this project? I ask, because this is a serious attempt at getting the Fast Healthcare Interoperability Resource (HL7 FHIR) standard moved over to GraphQL. Epic and Cerner both support FHIR, and FHIR is quickly becoming the emerging interoperability standard in healthcare. So, this would be a move towards getting onto Apollo, and including SQL database connectivity.

I’m trying to decide whether to invest heavy in this package, and how to integrate it into the Clinical Meteor project. But will that mean moving it over to apollographql/graphql-server? Swapping out Webpack for the Meteor build pipeline? Replacing the mongoose driver?

We could use it in production as-is. But there will be a lot of value in aligning it with the rest of the Clinical Meteor stack. And I’m not sure how much to move this GraphQL-FHIR project towards Clinical Meteor; versus moving Clinical Meteor towards GraphQL-FHIR. Thoughts?

sashko · March 8, 2017, 8:07pm

That’s actually the Apollo provided one!

awatson1978 · March 8, 2017, 8:26pm

Oh, that’s fantastic news!

So, it seems like the primary considerations are:

a) using mongoose, and whether we want to reuse SimpleSchema on the server as we access Mongo from Apollo and vice versa.

b) which build pipeline we want to use; and whether we can pull GraphQL-FHIR code directly into other Meteor on FHIR apps.

Thanks for the feedback.