bluehalo / node-fhir-server-core

An Open Source secure REST implementation for the HL7 FHIR Specification. For API documentation, please see https://github.com/Asymmetrik/node-fhir-server-core/wiki.
https://asymmetrik.com/healthcare
MIT License
391 stars 120 forks source link

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

Closed zeevo closed 2 years ago

zeevo commented 4 years ago

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 commented 3 years ago

That's a great news !

Geoffrey BAUDIN


De : zeevosec notifications@github.com Envoyé : mardi 8 septembre 2020 01:07 À : Asymmetrik/node-fhir-server-core node-fhir-server-core@noreply.github.com Cc : Ahryman40k Ahryman40k@hotmail.com; Mention mention@noreply.github.com 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 @Ahryman40khttps://github.com/Ahryman40k and Issue #213https://github.com/Asymmetrik/node-fhir-server-core/pull/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 GitHubhttps://github.com/Asymmetrik/node-fhir-server-core/issues/249, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABSIXTPQX3KEST5Q4MI5FS3SEVRUVANCNFSM4Q7AX7MQ.

zeevo commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

zeevo commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@zeevosec When you said

older node versions

You think above what version ?

I don't know how to use this.

luan-dev commented 2 years ago

Closing stale issue. Please reopen if this is a mistake