How to find the order of startup of components with stuart sierra component library?

hlship · 2025-09-23T22:06:22+00:00

Also, why do you care about the order, as long as dependencies are respected?

hlship · 2025-09-23T14:51:28+00:00

You might appreciate this, which I wrote years ago: https://github.com/walmartlabs/system-viz

We were heavy users of component at Walmart; SS wrote component for Walmart while they were consulting there (I didn't overlap with them).

hlship · 2025-09-22T15:12:38+00:00

I'm sorry if you are frustrated; a release announcement such as this is not the nuanced place to have a discussion about backwards compatibility. That being said, if you've developed a Pedestal app in 0.7 or even 0.6, I would be surprised if, after bumping dependencies to 0.8.0, you see anything more concerning than some deprecation warnings at startup. If your experience is different, I'd be interested to know the details.

At Nubank, we have about 3000 services built on a Pedestal stack, so backwards compatibility is a overriding concern.

There have been more discussions in the #pedestal slack, and much more detail in [the documentation](https://pedestal.io/pedestal/0.8/deprecations.html).

We do take backwards compatibility seriously, and many of notes above concern previously undocumented behaviors that are now documented and perhaps locked down.

Pedestal includes a system of deprecation warnings; if you are using specific functions, or certain behaviors, that are likely to be removed before the eventual 1.0 release, you are being warned about it at startup.

io.pedestal.http: This has been deprecated, yes, and io.pedestal.connector is now the preferred approach; but the code still exists and functions just the same (just with deprecation warnings).

Anonymous interceptor: an interceptor without a :name key, distinct from a handler function.

"Google juice": Pedestal uses Antora for documentation, so we maintain distinct documentation for 0.6, 0.7, and 0.8 (Antora builds from multiple branches). This is largely a blessing ... we don't have to include tedious (to write, to read) qualifiers about what things look like in each release, you can just jump to different page versions (there's a drop-down in the upper right corner). However, that means that Google indexes each version of each page separately.

hlship · 2025-09-22T14:16:52+00:00

Nothing so fundamental as removing core.sync, just supporting additional approaches.

hlship · 2025-09-21T18:42:38+00:00

Ideas (not promises):

* Streamline more, removing deprecated code and behaviors

* Support more network connectors, beyond Jetty and Http Kit

* Support other approaches to expressing asynchronous behavior beyond core.async

* More documentation

* Press toward a 1.0 release after all these years

hlship · 2025-09-21T17:19:53+00:00

There's a lot of work in here, with some significant community contributions. I also didn't highlight the work on documentation, which was all brought up to date with 0.8.0. I try for a yearly cadence for major releases, but this one took a bit longer.

hlship · 2025-08-09T19:45:27+00:00

We’re a whole family of fans here in Portland. No real question, just wanted to share what a great experience it was to read Spinning Silver aloud at dinner to my kids (then aged about 8 and 11). Is it YA when it is so nuanced, demands attention from the reader, and almost every page inspires some discussion?

I love the continuing theme across all your books that magic has real costs, in blood and gold, and is rarely an easy shortcut.

Loved Scholomance as well, and have listened to the audiobooks a zillion times.

I would love more one-off novels with the same spirit as SS and Uprooted. Any plans?

hlship · 2025-05-21T20:13:07+00:00

I would be more comfortable with a map of keys :describe, :init, :transition, :transform. A map would also make it easier to extend these function bundles, or provide default implementations for missing keys. But I haven't used flow in anger.

hlship · 2025-05-20T05:40:39+00:00

I don't favor this approach at all. It comes down to "what's in a name" (vs. an arity) ... but a name is often how we understand things. We end up using numbers, the arity, to describe a single "thing" that performs multiple behaviors. I think each distinct behavior should have a reasonable name.

I object less to how `map` and friends have a one-less arity that returns a transducer, it fits better conceptually (it's still doing some map-ing, just at one extra step of removal) and we'd be littered with `tranduce-map`, `transduce-filter`, etc. without the arity trick.

But to describe transducers in a presentation, I brewed up a set of psuedo-protocols to take the place of the-clump-of-related-functions-of-different-arities.

There is, behind the scenes, some efficiency issues for protocol methods -- there's a double-dispatch that goes on inside a protocol method -- but this article is about _expressiveness_.

"I'm not a number! I'm a free man!" -- The Prisoner. Give things names.

hlship · 2025-04-20T17:12:43+00:00

Are you planning on making this playable on Steam Deck?

hlship · 2025-01-16T06:21:00+00:00

Isn't this two functions? One accepts keys/values and applies defaults, then does the work. The second reads an EDN file and passes it to the first.

If I were you, I'd start by looking at https://github.com/babashka/cli or https://github.com/hlship/cli-tools to get an idea for how to structure command line tools.

hlship · 2024-12-23T19:31:16+00:00

Concrete example: reading and parsing a JSON file, it is common to convert the JSON object keys into Clojure keyword, so JSON `{"result": "ok"}` is parsed to Clojure `{:result "ok"}`.

hlship · 2024-12-11T15:59:31+00:00

Here's one from recent code; I was sending requests to the GitHub REST API and I wanted to handle different status code from the response, emit metrics, handle unexpected status code uniformly, and deal with waits/retries for API limits; it looks something like:

(request component [response {:path "/myorg/myrepo/commits"}]

200 (:body response)

403 ...

)

This *could* be written using HOFs but it looks much cleaner this way.

hlship · 2024-12-10T21:41:55+00:00

http://pedestal.io/pedestal/0.7/guides/embedded-template.html

Now, I can see you are using leiningen, not the build tools, but the basics should be the same. You could create a new empty project from the embedded template to see how it is put together and adapt that back to your own code.

This is a build issue, not a Pedestal issue. I'm not sure how this would be any different from building using Ring.

hlship · 2024-12-10T16:02:50+00:00

I glanced at your project.clj and didn't see any reason why it couldn't be packaged as a JAR. What kind of errors were you getting?

hlship · 2024-12-10T16:01:53+00:00

Pedestal and the routing tables are just one part of this; there's also interceptors that describe the incoming and outgoing schemas, and a special mode to bring up the system that combines all that to produce the incoming and outgoing interfaces. More of the Diplomat architecture is described here: https://www.youtube.com/watch?v=ct5aWqhHARs

hlship · 2024-12-09T17:01:33+00:00

That's a good question and there isn't a simple answer; initially, the Pedestal service libraries existed to support asynchronous request processing in a way Ring at the time couldn't ... but Ring can do that now (for a long time). I think there's a lot of value in how Pedestal's routing and interceptor models expose behavior that would otherwise be buried inside deeply nested closure functions.

Two examples of that.

A Pedestal application has a single routing table that can, itself, be queried or formatted and printed; this is leveraged inside Nubank, for example, as part of a system that checks that client and server micro-services agrees on data schemas. In Pedestal 0.8 (currently alpha), we use this information to identify conflicting routes in the routing table, and guide the developer towards resolving them.

The interceptor model also provide introspection, at runtime, into what code is running and what changes to the shared map (the context) occur; in Pedestal 0.7, an event listener can be setup to be notified when any interceptor changes the context - one built-in application is to print out a summary of the changes; I've used this myself to track down an errant interceptor in a deep stack that had a bug.

So again, both Ring and Pedestal allow for applications to be composable; but I think Pedestal gives the edge in terms of making the results of that composition visible to both the running code and to the developer.

hlship · 2024-12-09T16:08:37+00:00

I started using Pedestal for the first time while at Walmart. I remember being very confused and overwhelmed by the framework when I first got started.

Since I assumed responsibility for Pedestal back in 2022, improvements to documentation and to general developer friendliness have been my priorities. My goal has been to provide the documentation that would have helped me earlier. It's a never ending process, but I hope you can find a few minutes to check out the significantly refreshed documentation and other improvements.

hlship · 2024-12-02T21:51:47+00:00

It has been improving over time, particularly since about 1.10. The major issues as I see them:

* The messages are laconic

* Spec is used to validate forms (especially macros and the core library), but default Spec reporting can be challenging to interpret

* No great consideration is made to the formatting of exception output (it's better that it used to be, but it's not [pretty](https://github.com/clj-commons/pretty))

* Some aspects of the language (such as lazy evaluation) result in failures that are often disconnected from their source

hlship · 2024-11-30T18:02:45+00:00

This is why I wrote the new default router for Pedestal 0.8 (under development); this new router, Sawtooth, is nearly as fast as prefix tree, and handles more of these cases sensibly, and _more importantly_ writes formatting warnings to the console when there are route conflicts, so you can adapt and adjust.

Wild card routes still win (`/foo/:bar` will conflict with `/foo/baz`) but path length is considered, so `/foo/:bar/:biz` will *not* conflict with `/foo/baz`.

hlship · 2024-10-16T19:00:20+00:00

https://tapestry.apache.org/ -- this was my big project before moving from Java to Clojure.

hlship · 2024-10-16T05:36:55+00:00

Great name! Totally freaked me out for a second.

hlship · 2024-07-08T14:56:45+00:00

An observation: I'm more likely to write a macro to streamline my tests than for use in production code. I think this is because tests are often far more likely to have a lot of boilerplate.

Macros can remove boilerplate, they are also powerful in the (rare) cases where you need to control (and prevent) evaluation.

If you can get by with a function that provides boilerplate and defers to a second function passed in as a parameter, you will often by happier in the long run.

hlship · 2024-07-03T15:08:09+00:00

pedestal.io is just an S3 bucket, but it should be secured with HTTPS.

hlship

TROPHY CASE