Idea: Target idiomatic JS instead of NodeJS to be able to run on any environment

[tomsdev]

Hi, I was wondering how possible would it be to not depend on NodeJS specific APIs directly and instead write idiomatic JS with a small abstraction layer similar to what Remix does with their "server adapters" here: https://remix.run/docs/en/v1/other-api/adapter

That would allow to deploy to all the new cloud on the edge that don't support NodeJS (e.g. cloudflare, vercel, fly.io, ...). It would also make it possible to use other JS runtimes like Deno or Bun, and potentially even run natively on mobile or desktop with something like react native or electron.

If you think that would be useful then it would be easier to make that move earlier than later before the codebase gets much bigger.

[thejhh]

We actually use a well known architecture from enterprise Java -- Java's Spring Boot -- behind the scenes.

In this architecture the HTTP server and end points are mapped to the actual code using language annotations. We implemented almost identical annotations as in Java Spring Boot to our implementation for TypeScript. See examples in HsBackendController.ts.

Our annotatios are also designed to be separate from the implementation that implements the HTTP server side. This design allows different implementations for different platforms as well as possible complete rewriting later for better implementation and performance -- without any changes to any application code we might have already written. We could for example implement direct Nginx server plugin later to run our backends with Nginx instead of NodeJS (Nginx already has Google v8 JS engine support and we've done projects using it).

So the application code in hghs is actually already (for the most parts) not at all NodeJS specific, just pure runtime JavaScript (with compile-time TypeScript).

So far we have only one implementation of our RequestServer and it is NodeJS specific. It wouldn't be a big task to write other implementations though, but it would take time and dedication, of course.

I also like to design most of our code using common interfaces which also make it possible to write different implementations later and make it possible for our code not to be dependable of any specific adapter implementation.

Another big layer is the persistent data storage. We will use our Repository interface in hghs and extend it if need be. It's also just a simple TypeScript interface that can have multiple implementations -- and already has. It's a good example since it's just an interface -- depending of it is also not at all platform specific, and you don't even need to use NPM to use it. We don't yet have a PostgreSQL implementation for it, but it's on our roadmap as part of other projects. We also have another server under work, that simply implements the repository interface as a REST api. We have a good drawing of everything we've planned to implement for the repository in hgrs#1.

[thejhh]

So TLDR in general, we can actually quite easily compile different versions of hghs for different platforms, or even publish it as a plugable library/module.

[tomsdev]

oh ok sorry I didn't see that you already had an abstraction in place through Java, that's great!
Thanks for the detailed explanation, might be worth adding it to some documentation maybe :)

[thejhh]

There is no Java involved -- it's just implemented with the same public API specs as in Java's Spring Boot, but for TypeScript :)

We have some documentation at fi.hg.core's README but sure, it could be better.

[tomsdev]

oh ok interesting!