Closed zeevo closed 2 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.
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?
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 :)
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! ;-)
If you migrate to Typescript, I will be pleased to help ^^
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
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 :)
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.
I want to find a way where older node versions are supported, and TypeScript is not a requirement for consumers.
@zeevosec When you said
older node versions
You think above what version ?
I don't know how to use this.
Closing stale issue. Please reopen if this is a mistake
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 whichnode-fhir-server-core
thenrequire
s 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 aaddService
,addMetadata
API.Thanks @Ahryman40k and Issue #213 for highlighting this issue.
A final solution has yet to be agreed upon.