question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Package structure: org.http4s.$role.$backend or org.http4s.$backend.$role

See original GitHub issue

This discussion originated in the ember PR, but we didn’t have a strong consensus. Ember is org.http4s.ember.client. Blaze (and all other backends) are org.http4s.client.blaze. There are good reasons for both, but I think consistency is better than either argument. Let’s standardize on one.

Quoting a fool:

One thing that we all got right is to have both $backend and (server | client) in the package name. The Jetty server is older than the Jetty client, but we were able to add the client without moving the server later. So it’s really a matter of which comes first. I’d like us to be consistent. I’m willing to consider deprecating and moving the other backends with a scalafix.

  1. There’s more package-private code in ember than there is in server and client, so ember benefits from this convention. The alternative is to leave ember-core in org.http4s.ember, but make everything private[http4s].
  2. There’s also quite a bit in blaze, which could benefit from backend-first. But org.http4s.blaze is the blaze project’s package, so we need to be very careful about polluting that namespace. We’ve solved that today with a blazecore for the shared code, all private[http4s]. We could maybe move non-http4s blaze out of org.http4s, but to where? That’s a lot of moving for something nobody has complained about.
  3. There’s no shared http4s-jetty code between server and client. If there were, the ember convention would be a little nicer.
  4. No other backend has both a server and client. These can all benefit slightly from the current convention, with package-private server and client helpers. But the one and only that exists right now is DefaultClient.

Points 3 and 4 are weak. 1 is a good argument for change. 2 is a good argument for the status quo.

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Comments:22 (22 by maintainers)

github_iconTop GitHub Comments

1reaction
hamniscommented, May 19, 2021

I have some naming suggestions:

@amesgen org.http4s.jdkhttpclient or org.http4s.jdk.client @vasilmkd org.http4s.asynchttpclient or org.http4s.ahc.client

1reaction
vasilmkdcommented, May 13, 2021

Feel free to work on it @krayoola 😄

Read more comments on GitHub >

github_iconTop Results From Across the Web

Unleashing the Power of HTTP Apis: The Http4s Library
As always, the http4s library gives us an easy way to code such behavior, using the orNotFound method from the package org.http4s.implicits ...
Read more >
Http4s backend — sttp 3 documentation - SoftwareMill
This backend is based on http4s (client) and is asynchronous. ... Instead, all custom timeout configuration should be done by creating a org.http4s.client....
Read more >
Changelog - http4s
BlazeServerBuilder to org.http4s.server.blaze.BlazeServerBuilder . In 0.22, the alias becomes the canonical name for consistency with the other backends. http4s ...
Read more >
Todo-Backend
The Todo-Backend project defines a simple web API spec - for managing a todo list. ... aiohttp Akka API Platform Axon Framework Azure...
Read more >
Read Pure functional HTTP APIs in Scala | Leanpub
This means in turn that our functions will be referential transparent. ... We will stick to the Cats family of libraries namely http4s...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found