Is resgate capable of serving a web frontend files (htmlk, css, js, fonts, …)?
No. It is purely for API calls.
NATS isn’t really good with larger messages, such as embedded files. So, serving files over NATS isn’t optimal.
While I’ve been tempted to add support for files, I still haven’t found a satisfactory way to do it yet.
Common solution is to have a reverse proxy such as Nginx or Traefik, and then have Resgate for the API, and a separate server for serving static files.
Best regards,
Samuel
I understand it’s not the role of resgate.
I’ve thought about the reverse proxy, and it would of course be the way to go for non-ressources constrained applications. In my use case, I have very little ressources available. Would it make sense to you to have the possibility of defining which routes are handled by resgate and which are forwarded to a configurable server?
This way ressources constrained applications could take advantage of resgate to serve as a front gateway for both the API and other routes. This would also be generic enough to allow resgate to forward requests for any type of request he cannot handle.
Regarding the implementation, I would suggest something disabled by default, enabled if the following two parameters are set:
- A list of routes to forward
- The destination server
This may not be too complex as go already provides a reverse proxy API : httputil - The Go Programming Language
What do you think about that?
Hmm. I understand the purpose. Fewer components. Getting rid of the fronting reverse proxy.
And yes, Go provides pretty good libraries for this. But yet, I think there will always be other projects doing a much better job at it.
Forwarding headers (X-Forward-*), WebSocket upgrades, routing based on host and subdomains, HTTPS redirection, Acme (Let’s Encrypt) challenges. The list goes on with features that you would want from a fronting reverse proxy.
I would rather have Traefik do this job, and have Resgate provide the application API.
Does it make sense?
/Samuel
1 Like
I used a project called crossbar which does both, and then some.
After fighting with that for several years i realized that I prefer platforms to do one thing really well rather than trying to do a bunch of mediocre stuff. as i understand it, crossbar still doesn’t scale, which was a feature promised like 5 years ago.
for my current project we just stick them in a docker container with the world’s simplest server and have kubernetes route traffic to the container.
I’m not sure what you mean by constrained resources but our front ends can easily run on raspberry pie’s
1 Like