Allow for the creation of FHIR Profiles + Metadata without the passing of string paths to JavaScript files

[zeevo]

Do you want to request a feature, report a bug, or improve documentation?

feature

Currently, node-fhir-server-core works by providing the server with paths to JavaScript files, in which node-fhir-server-core then requires these modules in order to create REST + Search endpoints. But there is a problem with this design: File paths may not exist (dealing with relative pathing vs absolute pathing decreases Developer Experience), and more importantly: You cannot support TypeScript or Babel-ified projects. The reason being, is that transpiling changes file names and file locations.

I order to support a multitude of Developer Experiences and environments, node-fhir-server-core should support the creation of FHIR resource endpoints programmatically in the form of a addService, addMetadata API.

Thanks @Ahryman40k and Issue #213 for highlighting this issue.

A final solution has yet to be agreed upon.

[Ahryman40k]

That's a great news ! Geoffrey BAUDIN

…

________________________________ De : zeevosec <[email protected]> Envoyé : mardi 8 septembre 2020 01:07 À : Asymmetrik/node-fhir-server-core <[email protected]> Cc : Ahryman40k <[email protected]>; Mention <[email protected]> Objet : [Asymmetrik/node-fhir-server-core] Allow for the creation of FHIR resources + services + metadata without the passing of string paths to JavaScript files (#249) Do you want to request a feature, report a bug, or improve documentation? feature Currently, node-fhir-server-core works by providing the server with paths to JavaScript files, in which node-fhir-server-core then requires these modules in order to create REST + Search endpoints. But there is a problem with this design: File paths may not exist (dealing with relative pathing vs absolute pathing decreases Developer Experience), and more importantly: You cannot support TypeScript or Babel-ified projects. The reason being, is that transpiling changes file names and file locations. I order to support a multitude of Developer Experiences and environments, node-fhir-server-core should support the creation of FHIR resource endpoints programmatically in the form of a addService, addMetadata API. Thanks @Ahryman40k<https://github.com/Ahryman40k> and Issue #213<#213> for highlighting this issue. A final solution has yet to be agreed upon. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#249>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABSIXTPQX3KEST5Q4MI5FS3SEVRUVANCNFSM4Q7AX7MQ>.

[zeevo]

Right-- so I want to get some work done on this and do a 3.0.0 release along with #256

I'm thinking of a new way to use node-fhir-server-core in a better, more programmatical way. Something along the lines of...

const { FHIRServer, VERSIONS, Profile } = require('@asymmetrik/node-fhir-server-core');

const config = require('./config');
const db = require('./db');

class Patient extends Profile {
  constructor() {
    super({ version: VERSIONS['4_0_0'] });
  }
  searchById({ id }) {
    return db.findByPk(id);
  }

  async create({ resource }) {
    const { id } = await db.create(resource);
    return id;
  }

  // and so on for searchByVersionId, update, remove, etc
}

const server = new FHIRServer(config);

server.addProfile(Patient);

server.listen();

Thoughts? Perhaps there is a better way of doing this?

[Ahryman40k]

Hi @zeevosec,

You come here with an OOP solution. But depending of what Profile exposes and what FHIR resources need ( searchById, create, custom ? ... ) you can quickly drive into hell.
There is of course another ways, no one is right or wrong but both have pro and cons.
What do you think about decorator + metadata solution ? (See angular, nestjs, etc ... ) A lot of modern frameworks use that way. Of course multiplying decoration over classes and methods is also a bit tedious, plus you need a start point to init everything ( see boostrap method in angular or nestjs). It also looks like black magic !
Finally you can also have a functional programming approach and deal with a way to push methods the object could contain provided from a client side. It makes type more abstract, difficult to maintain and you need to have a good knowledge of the framework.

Hope this helps to start a discussion
:)

[sychus]

Hi @zeevosec.
Yes! I agree with that approach. Maybe it's also a good time to migrate to typescript!. If you need help, count on me! ;-)

[Ahryman40k]

If you migrate to Typescript, I will be pleased to help ^^

[zeevo]

I really like a decorator solution @Ahryman40k. What does this look like from the library consumer's point of view?

I also would like to migrate to TypeScript! @sychus

[Ahryman40k]

With a Typescript library, you can use Javascript or Typescript client code.
Decorators make possible to annotate and modify classes and properties at design time. In javascript, it looks like:

class C {
  @enumerable(false)
  method() { }
}

function enumerable(value) {
  return function (target, key, descriptor) {
     descriptor.enumerable = value;
     return descriptor;
  }
}

I also invite you to read this article.
Decorators are just functions, it means you also need a metadata mechanism, see this article too

Even if these mechanisms are mostly used in Typescript with Angular, they are available in Javascript ! Even If I'm not 100% sure, I think it's available for ES5. It means from consumer point of view, there is no need to move to Typescript. Although I strongly encouraged them to do so for a lot of reasons :)

[zeevo]

I believe the "@" syntax is still experimental, meaning consumers would be required to be either in TypeScript or in an experimental NodeJS release. Correct me if I'm wrong.

Decorator Proposal for ES6

I want to find a way where older node versions are supported, and TypeScript is not a requirement for consumers.

[Ahryman40k]

@zeevosec
When you said

older node versions

You think above what version ?

I don't know how to use this.

[luan-dev]

Closing stale issue. Please reopen if this is a mistake