-
-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a before_send middleware feature in development mode for better tooling integration #343
Comments
This sounds interesting @samueleaton, i'm OK for this if it's all compile time and no performance penalty for production apps 👍 |
@sdogruyol Sweet. I'll make a WIP branch and will discuss with you further how to we should go about adding a |
|
Its looking like the response is a write-only IO. So is it possible to read from it? |
Hi, this could be a good feature! I created a Kemal-watcher plugin to use with Kemal in development environments, helping to reload the browser when a file change occur. This plugin is very basic, it just add a new handler and does |
As @samueleaton pointed out, the response is write-only io. It can't be read or modified because it's probably already been sent to the client. The only way to achieve this would be to buffer the output, to allow it to be modified before being added to response. This is possible when the response is a return value from a route, but if it's being piped directory into the response, I'm not sure. If the above restriction is ok, this could be added here |
I'd like to be able to make some development tooling that integrates with Kemal. One needed feature is the ability to access the HTTP context right before it is sent to the client (after the route handler) so that the tools can do extra things (e.g. inject a special websocket script into the html body).
If we add a macro that checks for
KEMAL_ENV
at compile time we can addbefore_respond_handler
checker.This could be added to the
process_request
method in theroute_handler.cr
file like so:The point is to be able to create more tools for development mode. This will have absolutely zero effect on performance in production mode because the macro won't add any code in production.
The phoenix framework (elixir), for example, does a similar check in development mode for live code reloading. This would allow for more tooling to solve problems as in #335
Thank you!
The text was updated successfully, but these errors were encountered: