Hacker News Reader

Comment by moonchild | Hacker News Reader

They have this diagram:

  +-----------+   +--------------+   +-----------------+
  |Web Browser|   |Smartphone App|   |Client Libraries/|
  +-----+-----+   +------+-------+   |Other API code   |
        |                |           +-------+---------+
        |                v                   |
        |          +-----+------+            |
        +--------->+ Steveslist +<-----------+
                   |  Servers   |
                   +------------+

Why not this?

  +-----------+   +-----------------+   +--------------+
  |Web Browser|-->|Client Libraries/|<--|Smartphone App|
  +-----------+   |Other API code   |   +--------------+
                  +-------+---------+
                          |
                          v
                    +-----+------+
                    | Steveslist |
                    |  Servers   |
                    +------------+

View on HN

Yes, I think the second diagram that you showed is the preferred way of doing things, since using or "dogfooding" the client libraries will ensure they are always tested and correct, plus you'll get immediate feedback from the other developers who work on the apps as well.

In this day and age, your client libraries should be generated automatically. And of course used in your apps/webpage to save time.

See openapi/swagger for good examples how client generation works

I've been using openapi/swagger for generating my clients and honestly think it creates a mess of files and manually keeping clients up to date is not a huge task. I'm not sure that I buy into "your client libraries should be generated automatically" as a blanket statement.

Granted, APIs aren't updated often, but when they are, generated clients can save a lot of time. I can update a generated client in half an hour and be very confident of its correctness, whereas a manually constructed client would take hours to update and test.

Of course, the generated client is not very convenient, being a 1-to-1 mapping with the API. You build a high-level client with the more common operations on top of the generated one.

It's possible to do this in a way that gets you the best of both approaches, with some up-front planning.

Another benefit would be easier testing - you can easily auto-test the logic and separate the testing of the UI.

Nicely wrapped-up public APIs with a pleasant presentation & small learning curve require tradeoffs. Why force your own app & website to pay those costs?

You dont "force your site to pay these costs", you design your clients as consumers from day one and get consumable external APIs for free.

This is a common "holy grail" that I've never seen any company pull off successfully. Like others have said you rarely have the ability to build a simple-yet-powerful API that perfectly services both your company proprietary apps and 3rd party clients. The requirements are almost always at odds with each other.

It certainly takes a huge amount of discipline, which is wholly absent in most service companies.

Hiding the costs, minimising the costs or "integrating them well with your platform" do not erase the costs.

Do most companies need an external API?

3/4 places I've worked have an external API. It might not be "public" but often enterprise customers want to pull their data for their own mangling.

I think at the beginning you won't have a client API at the beginning.

That stuff is only done at the end unless you're chargin for that at the beginning.

If you're not B2B positioned, you probably won't have a client library for a while.

Wouldn't the issue with client libraries be tight-coupling and having to maintain n libraries instead of one generic server API endpoint?

Yes

Different ergonomics of each of those environments, at least in the ideal case for each combined with the server API being a clean enough API boundary if I had to guess.

Reply on news.ycombinator.com