pedestal

hlship 2025-01-29T03:32:26.739949Z

Been quiet on the Pedestal front for a bit - what I’m working on currently is turning the code that exposes classpath and file-system resources as request endpoints from special interceptors separate from routing into routing fragments that can be merged into your application’s main routes. There’s pluses and minuses to this new approach (I don’t think we’ll deprecate the old approach) but on the plus side, I should be able to adapt the fast resources to both file system and classpath. There’s also room for some caching that may make resource requests minutely faster. Pros: consistent, logged and traced with all other routes, code is better tested, easier to limit requests to specific host/port/scheme (like anything else that’s routed) Cons: have to watch out for conflicts with API routes; subject to all interceptors that routing is (so, maybe you don’t want resource URLs logged and traced, etc.)

👍 1
2
2025-01-29T10:48:22.836609Z

Resources might be cached by the JVM anyway?

souenzzo 2025-01-29T12:05:28.987259Z

I like the pros. About the cons: if I "dont want the resource to be logged", i will tweak my "cloudflare proxy" and ask to cache this resource.

hlship 2025-01-30T01:11:13.010859Z

Looking more carefully at http/default-interceptors ... the resource and/or file interceptors occur immediately before the routing interceptor, so there's actually not much of a change there, which leads me towards deprecating the other options.

hlship 2025-01-30T01:12:19.362649Z

Caching: frequently accessed files will move to the OS’ page cache, where access can be very fast. What we’re really caching is the results of lookups, resolving the path to a File, resource URL, JarFile+JarEntry, etc., depending on the case.

hlship 2025-01-30T01:12:28.662659Z

I'm past principal development now, working on the documentation.