Tinkoff/tramvai

Does it support build for edge runtime?

Closed this issue · 6 comments

polRk commented
Does it support build for edge runtime?

Hello!

No, at this moment tramvai doesn't support Vercel edge runtime, or any other serverless environments.
Our framework setup fastify server, heavily integrated into the Dependency Injection system.

So, on the one hand, tramvai application lost the ability to be just a function like (request, response) => HTML.
But from the other hand, this approach has a lot benefits:

  • You don't need to care, how render React on server or client (compared to Remix, for example)
  • You have solid server metrics "out of the box", and can easily add custom metrics
  • server lifecycle are part of application lifecycle, and by using CommandLineRunner, you can for example run some other server for static assets or for requests mocking simultaneously with the application server (both of this cases already implemented in tramvai modules)
  • tramvai modules, thanks to DI, have full flexibility to work directly with the server instance, which allows us to implements modules where we have: cusom API endpoints, requests limits, http_proxy support, and many other specific and useful things.
polRk commented

Our framework setup fastify server, heavily integrated into the Dependency Injection system.

Cloudflare workers, the site is rendered and displayed to users around the world in about 50ms-65ms. At the moment, no framework provides a simple way to work in cloud functions or edge functions environments.

And another question is, if I want to use koa, what should I do in this case?

For example, Cloudflare workers, the site is rendered and displayed to users around the world in about 50ms-65ms

In our experience, two things significantly affect the response time of an SSR application:

  • server-side requests to any API's, because of that we have some timeouts, but still it can take a hundreds of milliseconds
  • server-side React rendering time for complex pages, can take from 25 to 100 ms, depends of page component complexity

Because of that, we haven't paid much attention to round-trip time.

But if we talk about cached content, no doubt RTT means a lot.
Also, we have a static HTML export feature, and these pages can be delivered to users via CDN.

And another question is, if I want to use koa, what should I do in this case?

No, we decided not to made abstractions over server framework, and use only specific framework, chosen by our team.
For now, we are in the process of completing the migration from express to fastify, for performance and some others reasons.

Supporting multiple server frameworks can be too expensive for us, at least it doubles our integration tests.

polRk commented

Supporting multiple server frameworks can be too expensive for us, at least it doubles our integration tests.

Is it possible to export an abstraction and connector functions for server frameworks ?

export handler = (req Request, res Response) {}

https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API

Don't think so, in server module internal implementation we have a lot specific framework connections.

E.g. list of internal server module tokens, any of this can be used in other core modules.